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.