Marc Edwards

Marc Edwards

Community Staff Founder at Bjango Joined over 6 years ago via an invitation from Christophe T. Marc has invited Matt Kelsh, Rene Ritchie, Dan V Peterson, Troy Mcilvena, Graham Clarke and 12 others

  • 499 stories
  • Posted to 14 designers helped us make sense of data from 6M design files, in reply to Mattan Ingram , Apr 19, 2019

    If someone’s not using the best tool due to ignorance, doesn’t that mean your original reply is correct?

    People get so sensitive when you suggest a better tool, but sometimes IT REALLY IS BETTER.

    Colour management is essential. Not understanding it is a weak excuse, and as wide gamut displays take over all devices, that excuse is going to cause more issues and seem more tenuous.

    I get that some of the older tools aren’t the flavour of the month, but there’s a lot to be learned from them. Newer tools often seem wilfully ignorant of lessons learned a long time ago.

    0 points
  • Posted to 14 designers helped us make sense of data from 6M design files, in reply to Mattan Ingram , Apr 19, 2019

    Rather than snark, I’d prefer some well researched and more objective reasons. I’m all for sensible discussion around tools, and I have no problem with discussions around which is better for certain tasks. I do my best to use a wide range of tools.

    Sure, you can do some UI work in Illustrator, but its real power lies in illustration. Anything else — from wireframing to pixel pushing is far easier in tools such as Adobe XD, Sketch or Figma.

    Adobe XD is not colour managed, doesn’t have guides, doesn’t have blending modes, and is missing 100s of absolutely essential features for wireframing and UI design. Missing colour management is grounds for instant dismissal, in my opinion — if you can’t draw a single rectangle and have it show as the correct colour, the entire tool is unacceptably broken for design work.

    Comments like the one quoted only show the author’s lack of understanding of the tool space and design in general.

    0 points
  • Posted to How to build an NDA portfolio?, in reply to Ricard Panadès Nadal , Apr 19, 2019

    For NDAed work, I think you should ask for permission, even for case study or process articles where the client is not named and the work is not shown. You really don’t want to break an NDA.

    1 point
  • Posted to 14 designers helped us make sense of data from 6M design files, Apr 19, 2019

    Crafting UIs in Illustrator is not a good idea.

    That is a really daft take on Illustrator, which is still by far the best tool for making icons and icon sets for user interfaces.

    1 point
  • Posted to How to build an NDA portfolio?, Apr 18, 2019

    I think it’s fairly simple: If you signed an agreement to not show the work, you can’t show the work. You could ask for an exemption though.

    1 point
  • Posted to Designers who are 40 plus, how are you..., in reply to Steven Cavins , Apr 11, 2019

    I look forward to being in my 60s and going on holidays.

    (I think some of the original points about wages are fair though.)

    0 points
  • Posted to Designers who are 40 plus, how are you..., in reply to Nils Trieu , Apr 11, 2019

    hahaha thank you!

    0 points
  • Posted to Designers who are 40 plus, how are you..., in reply to Tom Wood , Apr 10, 2019

    I’m 43 and faster than I have ever been. :D

    11 points
  • Posted to Where do you store your design assets?, in reply to Jennifer Nguyen , Apr 09, 2019

    I think I need to start by clearly defining how I like to structure things, and what I mean by each name.

    Assets = The final deliverable parts. These are often PNGs, SVGs and other files that are included in the production product. I believe these should always be easy to regenerate in a way that’s as automated as possible.

    Slice sheets/export docs = The documents that generate assets are typically set up so they only contain elements that need to be exported as production assets. Changes needed for production are always made here. I typically put these documents on a repo as well (that’s not essential though). These documents are kept as neat as possible and maintained as the product evolves.

    Design system library = The components used to make prototypes and mockups. If things are well set up, these can also be used in the slice sheets/export docs, so everything stays in sync.

    Mockups and prototypes = These documents are treated as exploratory and temporary. They are not for production, and I don’t mind if old mockups and prototypes get left behind and are out of sync with production.

    Say I need to mockup some screens that are using existing icons and images, so does this mean I have to go to the repo, find where it's located, download the asset onto my local machine, and then import it to my design document?

    Mockups would be created using components from the design system library. There’s no situation where I’d be reimporting production assets.

    0 points
  • Posted to Using a static site generator at scale, in reply to Tinh Nguyen , Apr 08, 2019

    Nice. Hugo + Netlify + deploying via Git sounds like such a good setup.

    1 point
Load more comments