Another category, searchable interfaces, may fit into one of these or may be it’s own separate category. But tools like MacOS Spotlight or the command palette in some editors are very useful for power users. Having every command available through a minimal set of fuzzy keyboard strokes is a significant productivity boost, while also allowing some degree of discoverability.
As an aside, if anyone at Adobe is reading this, this sort of tool would be an excellent addition to Illustrator, Photoshop, etc. InDesign already has something like it, although that implementation leaves a little to be desired.
As a metric user, this is an interesting point that I haven’t heard before, and I think the other responses don’t really engage with it. Yes, familiarity means this isn’t much of a daily problem – you just use divisions of the unit that are most appropriate. But the size of the base units for volume, mass and length don’t really match up well from a human day-to-day perspective.
Wouldn’t it be nicer if a litre, a gram and a cubic metre of water were equal, rather than 1 cubic metre, 1000 litres, 1,000,000 grams?
Side note that in Europe drinking products are often labelled in centilitres whereas Australians use millilitres. I wonder whether this indicates some difference in the way the two groups think about volume, or maybe it is just the fallout of some other constraint, like translations limiting the space available.
Still, the ergonomics seem to be on the side of Metric, taking into account the ease of conversion between units when all are base ten.
I suppose there is no hard requirement for consistent saturation between hues, but that seems a bit inconsistent to my tastes. Darker yellow and orange colours seem a little too washed out.
Overall I like the total palette though. Especially the avoidance of “red” red, which is a colour I think many designers dislike. I would love to see a study on colour preferences in relation to eye colour.
I’ve been using a similar technique to display our poll data[1] for several years, although without using grid. If you can measure the text because you know which font will be used, and store the widths of various characters, you can take a little more control over layout too, even while rendering server-side.
I also started writing a simple responsive SVG charting library[2], but the author is right in that there are some fluid layouts that are just impossible to realise with SVG at the moment.
> If you can measure the text because you know which font will be used
If you are using text, you can’t know which font will be used. There are no universally-available fonts, so web fonts are the closest you get, but they could fail to load for various reasons, and it’s honestly more common than people allow for. You can also block web fonts (e.g. uBlock Origin has an entire button for it), or just turn off font selection altogether, in Firefox via Settings → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above. I did this four years ago as an experiment and have never gone back because it made the web so much better (I did switch back for one week a couple of years ago to convince myself the web really was that awful without it). Not many people will do this deliberately, but it is a thing.
Your page loading times will obviously take a hit, but that'll give you pretty close to 100% certainty that the font will be used, should you want that.
That resolves one of the main causes of failure, and I generally speak very highly of inlining everything—it has very noticeable performance benefits up to surprisingly large sizes (generally well over 100KB).
Aside, pairing application/font-woff2 with charset=utf-8 makes no sense. It’s a binary encoding.
But I think you’d still be surprised how many browser configurations don’t load web fonts, though I’m sure it’s becoming less common.
Knowing which font is used with a hundred percent certainty, maybe not. This probably is something more people should be aware of. But the failure mode might be some slightly awkward line breaks, assuming you allow for the edge case of alternative fonts. And even when the calculation isn’t a perfect representation of the rendered reality, the approximate width is still more useful for layout purposes than going in blind.
Combined with em-based sizing I’ve found this to be pretty robust. Just because you can’t make it perfect for all users doesn't mean you can’t do the work to improve it for many.
I made a little platform to house some of my simple tools. It is part REPL, part form-builder. All tools run on the client, which constrains what is possible, but still proves useful for many basic applications.
It is limited and depends on the browser used to print the document. The most glaring missing feature is CMYK colour.
I’ve just set up our publications to use PagedJS, and with a fair amount of hacking I was able to set up a baseline grid. Hyphenation depends on the browser implementation, which is OK for English in recent Chromium. The new text-wrap property has also been helpful. Hanging punctuation is only supported in Safari if I remember correctly.
But being able to produce nice looking PDFs from a markdown document, with automated endnotes and table of contents, is a much nicer process than going through InDesign, and I also say this as someone equally comfortable with both. And the result is good enough for our purposes.
I agree that InDesign generally is clunky (the same reason it has a lot of typesetting black magic: business model where you make money by satisfying requests of perfectionist designers and their managers). However, in the past, while I was still doing relevant work, I had mild success abstracting some of it out by defining a template and populating it with data imported from JSON.
Now I’m not using ID much, and struggling with generating PDFs from HTML, so I really appreciated the example you gave. Great work!
Reddit has been using these fonts internally for a few years in their marketing. They were not available to the public. They have been made available this week, hence the announcement. (The Github repo was made public a few weeks ago in preparation for adding them to the Google Fonts service.)
