Do you design digital products (or websites) and hand design files off to developers for implementation? If you answered yes, settle in! While the should-designers-code debate rages on, we're going to look at how adding a methodology to your design workflow can make you faster, more consistent, and loved by all developers... even if you don't code.
Mark Dalgleish details how his team at seek tried to build a library of React components that could then be translated into Sketch documents. Why is that important though? Well, Mark describes the problems that his team faced like this:
...most design systems still have a fundamental flaw. Designers and developers continue to work in entirely different mediums. As a result, without constant, manual effort to keep them in sync, our code and design assets are constantly drifting further and further apart.
For companies working with design systems, it seems our industry is stuck with design tools that are essentially built for the wrong medium—completely unable to feed our development work back into the next round of design.
Mark then describes how his team went ahead and open-sourced html-sketchapp-cli, a command line tool for converting HTML documents into Sketch components. The idea is that this will ultimately save everyone from having to effectively copy and paste styles from the React components back to Sketch and vice-versa.
Looks like this is the second major stab at the React to Sketch. The last one that went around was AirBnB's React Sketch.app. We normally think of the end result of design tooling being the code, so it's fascinating to see people finding newfound value in moving the other direction.
I’ve been obsessed with design tools the past two years, with apps like as Sketch, Figma and Photoshop perhaps being the most prolific of the bunch. We use these tools to make high fidelity mockups and ensure high quality user experiences. These tools (and others) are awesome and are generally upping our game as designers and developers, but I believe that the way they’ve changed the way we produce work and define UX will soon produce yet another new wave of tools.
In the future, I predict two separate categories of design applications: tools for thinking and tools for systems.
Let me explain.
The "normal" workflow I'm sure we've all lived is that design happens, then coding happens. A healthy workflow has back-and-forth between everyone involved in a project, including designers and developers, but still: The code is the final product. You design your way to code, you don't code your way to designs.
It was only a little over a month ago when it was news that Sketch 43 was moving to a .JSON file format. The final release notes drop the news quite blasé:
Revised file format
But Jasim A Basheer rightly made a big deal of it:
... it will fundamentally change how the design tools game will be played out in the coming years.
"enables more powerful integrations for third-party developers" is stating it lightly. This is what the fine folks at Bohemian Coding has done — they opened up Sketch's file format into a neat JSON making it possible for anyone to create and modify Sketch compatible files.
I was just bemoaning strokes the other week:
And that's the trouble with
text-strokein CSS: you have no choice. It's center-aligned stroke only. Either of the other options [outside-aligned or inside-aligned], arguably, would have been more useful.
There still is no solution for
text-stroke, but SVG has the exact same problem. It's not quite as design-ruining with SVG, since you can (and designers have been) design with center aligned strokes in mind with their vector art. Still, I'd say if we had
stroke-align: [center, outside, inside]; we'd be better off.
Peter Nowell documents how Sketch now repositions the points of your shapes to replicate the different stroke alignments, if you explicitly chose those options in Sketch. Pretty useful! Since native SVG still only does center alignment, that would mean changing the stroke width after exporting would still be weird, but I suppose that's fairly rare.
The article notes how SVG 2 accommodates for aligned strokes, but that still feels a bit up in the air.
Bobby Grace, on the Dropbox Paper team:
On the engineering side, we use inline SVGs. These have many advantages. One advantage is that SVG is a well-structured format that we can manipulate with code. Paper is also using React and has a component for inserting icons.
- Use a single Sketch file, checked into the repo, as the place to design and house all the icons.
- Use gulp-sketch to extract them all individually.
- The build script continues by optimizing them all and building a source of data with all the icons and their properties.
- That data fuels the their
<SvgIcon />React component. (Also see our article).
They call it Papercons.
Now, whenever someone asks for an icon, we can just share a link to all the latest production icons. No more hunting, context switching, and long conversation threads.
There is an interesting gotcha about the
fill-rule attribute of SVG, detailed here by Anthony Collurafici.
Fill-Rule is an SVG property that basically defines how to determine what shapes are filled or subtracted from the shape. The default SVG value is "nonzero", and this is what Android requires. Unfortunately, Sketch uses "evenodd". Luckily Sketch provides all the features we need to convert our shapes from "evenodd" to "nonzero". And its now even easier in Sketch 42.
The direction you draw the points in nested shapes affects the fill.
No surprise to any of y'all: screens come in a whole lot of different sizes and pixel densities these days. The technology behind dealing with that is catching up. For example, responsive images. So, we need software to help us generate those many versions of images we need.
Thankfully, all the most popular design software is starting to accommodate that need. Adobe Photoshop, Adobe Illustrator, Sketch, and Affinity Design all have pretty solid workflows for doing just that. I cover all those in this post over on the Media Temple blog.