our blogthe world needs more fonts, honestly
24 June 2017, 18:30
It appeared in a thread that started off with some saucy quotes: ‘the problems have already been solved’ and ‘the function of new typefaces is largely aesthetic.’
It piqued my interest because I have worked on the interaction design of a couple of font design applications. Besides that I have spent a lot of time investigating the general nature of design.
making a splash
So I jumped in and joined the twitter discussion. After a false start (oh, the joys of social media) the heart of the matter came to light: ‘It is about problems that typefaces solve, not about the problems of typeface design practice, i.e. the categories of reasons why to draw.’ So I addressed it there, have been thinking about it quite a bit more since then, and now I am going to address it better.
Let’s start with a smooth aikido move to get this discussion positioned where it belongs. When a font is to be used by many (i.e. more than 100) people, then it is a product. The type designer is the product designer; the design process is the act of product realisation. The process starts with a product definition; methodical research and design follows. Eventually a set of design drawings is created, to be engineered into shippable fonts.
This insight rebases the discussion. It is a product issue, not a design issue. Asking what problems type design can solve today, is asking: are there any product definitions left that aim to bring useful, valuable font solutions to users?
Well, allow me to make some suggestions.
think big, really big
If you write using Latin script, then it seems that you have 100.000 fonts to choose from. If you write in another script, you are suddenly scraping the barrel; 100 usable fonts is then super luxurious. Does this impact just some tiny minorities? Well, here is a handy list: writing scripts sorted by usage. If I skip Latin and add up the populations that actively use the next ten scripts, then I end up with 3.41 billion people.
The ten scripts are: Chinese, Arabic, Devanagari, Bengali‐Assamese, Cyrillic, Kana, Javanese, Hangul, Telugu and Tamil. Right after these on the list there is a group of six modestly used scripts (Gujarati, Kannada, Burmese, Malayalam, Thai and Sundanese) that nonetheless serve another 205 million people.
Here is my suggestion: Want to do something useful? Pick a popular Latin font (family), say from the top‐1000 in use, and pick one of the big‑10/modest‑6 scripts listed above. Your product definition is to design a font in that script that goes together seamlessly with the Latin font. That does not mean that your new font has to play second fiddle to the Latin one; just that they get along famously.
I can tell you from experience that it is very rewarding to design something this relevant; with the knowledge that tens, if not hundreds, of million of people are waiting out there for the results. Of the 3.615 billion people mentioned above, a good chunk owns a smartphone or will own one soon—you cannot stop commodity Android. It’s their access to the internet. They inform and express themselves using text. They need fonts.
fit for purpose
Read a book on typography and one discovers that non‐philistine typesetting starts with using proper numbers (oldstyle vs. lining, &c.), small caps, and so on. Now check 10 random fonts on the device you use to read this post. Do they contain a full set of numbers and small caps? It is going to be hit and miss. Personally, I am still waiting for oldstyle numbers for my favourite Swiss sans.
While typesetting got more efficient (hot lead, to photo, to digital), typography support got thrown overboard. Today, typography is banned to the graveyard called OpenType features. Yes I know, OT features UI is a world of hurt, but someday someone is going to do something about it (if that is you, ping me). Meanwhile, it is 2017 and fonts that just support the skimpiest of Latin glyph set feel very ‘ms‑dos’ to me; primitive, with a touch of nostalgia, but surely past due date.
So my second suggestion is to start doubling down on OpenType features. Go through the top‐1000 list of fonts and start extending them to make them useful, and valuable, for typographers. I realise there are some barriers of entry, like intellectual property and access to source files (so that they can be extended). Maybe you can pitch the company that owns them and get the gig. A straightforward case is open source fonts, you can get started right now.
fit for authors
Bold and italic are not just a good idea, they are (by default) the way to express certain conventions in text, e.g. emphasis, or denote publication titles. The defaults of html & css are an example of how enshrined this is. A week ago I was trying to select some typefaces for a new website, and it was an uphill struggle, littered with missing italic and/or bold font variants.
My third suggestion: there are plenty of holes in the top‐1000 fonts where it comes to bold and italics. Your product definition is to fill some of these, where you think it matters most. Designing a bold for someone else’s regular can be a drag. But italics can be worthwhile design work, because they start with a clean sheet and a different skeleton than the regulars. I suspect the amount of true‐design work involved is the reason italics got skipped in the first place.
Speaking of, here is a bonus product definition: real italics to be used seamlessly with that famous Swiss sans—to replace them obliques. Again a clean‐sheet project which solves a typographer’s problem. And an ambitious, high‐profile one too. You can call it Helvetalics, if you like.
fit for a new medium
Last year I was involved in an internet‐of‐things project. After a methodical start, it became immediately clear that for our combination of display (size, resolution), use (viewing distance, information density) and goals (not end up being cheap junk slapped together by engineers) we needed a font to make it work. Yes work; life or death.
New media to display text, with new properties—and new contexts for old ones—pop up regularly. These events naturally trigger product definitions for fonts to make new media work.
aesthetics, schm’sthetics
In this blog post I have not gone into aesthetics, because I didn’t need to. All I have done is look beyond the glyph shapes and spot ocean‐sized holes in the font product landscape. Just following up on my first suggestion will keep the global type designing community busy for decades with work that is 100% non‐frivolous. Suddenly today’s ‘glut’ of type designers looks like it could use some serious reinforcement troops.
A business coach once told me: ‘this design work you do is political, isn’t it?’ She meant that my design clearly impacts society and that my design decision make the world better, or worse. That starts with the decision ‘what project do I work on?’
If you get to decide the product definitions at your font shack, then your work is political.
- Your choice of scripts is political; how many of 3.615+ billion people are you gonna throw under the bus?
- Your choice of OT features is political; a font for typographers, or only for simple business administration?
- Your choice of including a bold and italic is political; is your font going to be a drop‐in solution for those who just want to communicate?
- Your choice of targeting new display media is political; are you going to leave their new users out in the cold?
If you scour the font landscape, looking for pockets of user‐felt hurt (‘what, XYZ simply doesn’t exist?’) and then do something about it by creating, or updating, a font product, then your work is political, useful and valuable. And I salute you.
Labels: openType, practical, product phase, product vision, top story
designing openType‐features UI /intro
23 June 2015, 09:24
a bit of a situation
First things first. It is quite likely that when you are reading this, you know what openType features in fonts are. But just in case you don’t, here is a friendly, illustrated explanation of some of the features, without putting you straight into corporate specification hell. The reason I said ‘some’ will become clear below.
What is interesting is that there is a riot going on. The 800‑pound gorillas of (typo‐)graphical software—the adobe creative suite applications—have such bad and disparate UI for handling openType features that a grass‐roots protest movement started among typographers and font designers to do something about it. What followed was a a petition and a hasty promise by adobe to do better—in the future.
meanwhile in Toronto…
These events prodded Nathan Willis into action, because ‘open‐source applications aren’t any better in this regard.’ He organised a openType workshop at this year’s LGM to get a process started to change that. I went there because this is smack in the middle of one of my fields of specialisation: interaction for creatives. As you can read in Nathan’s report, I got immediately drawn into the UI discussion and now we have a loose‐knit project.
The contents and vibe of the questions, and my answers, in the UI discussion all pointed in a certain direction, that I was only able to name a day later: harmonised openType features for all F/LOSS (typo‐)graphical applications definitely has an infrastructure component.
the untouchables
Pure infrastructure—e.g. tap water, electricity, telecoms—offers its designers some unique challenges:
- everybody uses it
- and everybody’s needs are equally important; there is no opportunity to optimise the design for the specific needs of user groups.
- nobody cares
- usage is ubiquitous, i.e. we all do not even register that we are using this stuff all the time—until it stops working, then we miss it a hundred times a day. This makes it very hard to research; no recollection, feelings or values are connected to infrastructure, just entitlement.
- anyplace, anywhere, anytime
- there is no specific contextual information to work with: why is it used; what is the goal; what does it mean in the overall scheme of things; how much is a little, and a lot; it is used sparsely, all the time, at regular intervals, in bursts? It all depends and it all happens. Just deal with it, all of it.
- millions of use cases
- (not that I consider use cases a method that contributes positively to any software project, but‐) in the case of infrastructure something funny and instructive happens: after a week or two of exploration and mapping, the number of use cases grows exponentially towards a million and… keeps on growing. I have seen this happen, it is like peeling an onion and for every layer you peel off, the number goes up by an order of magnitude. These millions of use cases are an expression of everybody using it anyplace, anywhere, anytime.
- heterogeneous capabilities
- this is not always the case, but what is available can vary, a lot. For instance public transport: how many connections (incl. zero) are available for a given trip—and how fast, frequent and comfortable these are—is set by the network routes and timetables. An asked‑for capability is on offer, or not. It all depends and it all happens. Just deal with it, all of it.
I have worked as design lead on two infrastructure projects. One was Nokia dual‑SIM, the other openPrinting, where we designed printing dialogs for all linux users (everyone), as used in 10.000 applications (anyplace, anywhere, anytime), connected to 10.000 different printer models (heterogeneous capabilities). I dubbed it the project with five million use cases.
Ah, and since both application and printer configure the available options of the print dialog, there are potentially 100 million configurations. Even if in reality the variability is far less (say, just 1% on both application and printer side; i.e. 100 significantly different printer models and 100 apps that add serious, vital printing options), then it is still an overwhelming 10.000 configurations.
drowning, not waving
In my experience, designing infrastructure is very demanding. All the time one switches between making the big, abstract plan for everything, and designing, minutely, one of many details in complete isolation. Mid‑level interaction design, the journeyman, run‑of‐the‑mill, lay‑out‐a‑screen level, is completely missing.
It is like landscaping a featureless dessert, where every grain of sand is a detail that has to be dealt with. With no focus on particular users, no basis for research, no context, no just‑design‐the‐example, millions of use cases and highly variable capabilities, I have seen very capable design colleagues lose their bearings and give up.
back at the ranch
Enough war stories. How large is this infrastructure component of openType features in (typo‐)graphical software? Let’s check the list:
- everybody uses it—nope. Whether the user groups turn out to be defined real narrow or quite wide—a matter of vision—they will have in common that all of them know their typesetting. That is a craft, not common knowledge.
- nobody cares—well, soon they won’t. Right now there is upheaval because nothing is working. As soon as users get a working solution in the programs they use, it will become as interesting as the streetlights in your street.
- anyplace, anywhere, anytime—right on! This has to work in (typo‐)graphical software; all of it—even the kind I have never heard of, or that will be invented in five years from now. All we know, is that serious typesetting is performed there by users, on any length of text selection.
- millions of use cases—not quite. The limited user group provides the breaks here. But there is no such limit from the application side; on the contrary: most of these are (open‐ended) tools for creatives. Just thinking about how flexible a medium text is, for information or shapes, gives me the confidence to say that 10.000 use cases could be compiled, if someone would sit down and do it.
- heterogeneous capabilities—hell yeah! OpenType‐features support in fonts is all over the place and not just because of negligence. First there is the kaleidoscopic diversity of scripts used around the world, most of which you and I have never heard of. Latin script is just the tip of the iceberg. Furthermore, what is supported, and how each supported feature is actually realised, is completely up to the font designer. The openType‐features standard is open‐ended and creates opportunities for adding sophistication. This is only limited by the combined imagination of the font design community.
Adding that up, we get a score of 3½ out of 5. By doing this exercise I have just found out that openType features in (typo‐)graphical software is 70% infrastructural. This is what I meant with that it is a special, complicated project.
structure—the future
In projects like these structuring the design work is make‑or‐break; either we set off in the right direction, or never get to any destination—not even a wrong one. The structure I use is no secret. Here is my adaptation for this project:
A product vision is not that easy to formulate for pure infrastructure; it tends to shrink towards ‘because it’s there.’ For instance at openPrinting the vision was ‘printing that just works.’ I still regret not having twisted some arms to get a value statement added to that. There were times that this value void was keeping us from creating true next‐generation solutions.
Apart from ‘what’s the value?’ also ‘who is this for?’ needs to be clarified; as we saw earlier, openType features is not for everyone. The identity question, ‘what is it we are making?’ may be a lot less spectacular, but it needs to be agreed. I will take this to the Create mailing list first, mainly to find out who are the ‘fish that swim upfront’, i.e. the people with vision and drive. Step two is an online vision session, resulting in a defined vision.
The deliverable is a to‑the‐point vision statement. If you want to get a good picture of what that entails, then I recommend you read this super‐informative blog post. Bonus: it is completely font‐related.
we want the funk, the whole funk, nothing but the funk
A deep understanding of the functionality is the key to success in this project. I already got burned once with openType features in the Metapolator project. Several font designers told me: ‘it is only a bunch of substitution rules.’ Until it turned out it isn’t. Then at the LGM meeting another surprise complication surfaced. Later I briefly check the specification and there is yet another.
This is what I meant before with that friendly page explaining some of the features. I do not trust it to be complete (and it is only Latin‐centric, anyway). As interaction architect I will have to be completely on top of the functionality, never having to rely on someone else to explain me what ‘is in the box.’ This means knowing the openType standards.
Central to it is the feature tags specification and the feature definition syntax. This contains both the material for understanding of how complicated it all can get and the structures that I can use to formulate UI solutions. It is one of the few aspects that are firm and finite in this project.
The deliverable is a functionality overview, written up in the project wiki.
talking heads
I will do user research, say interview half a dozen users, to gain insight into the act of typesetting, the other aspect that is firm and finite in this project. Which users to recruit depends on what is defined in the product vision. Note that the focus is on the essence of typesetting, while ignoring its specific role in the different (typo‐)graphical applications, and not get swamped by the latter’s diversity.
The deliverable is notes of interest from the interviews, written up in the wiki.
I look forward to an exchange with F/LOSS (typo‐)graphical applications via the Create list. This is not intended to get some kind of inventory of all the apps and how different they are. In this project that is taken as abstract and infinite—the good old infrastructural way.
What I want to find out is in how many different ways openType features must, or can, be integrated in the UIs of (typo‐)graphical applications. In blunt terms: how much space is there available for this stuff, what shape does it have and what is the duty cycle (permanently displayed, or a pop‑up, or…)? These diverse application needs are clustered into just enough UI models (say, six) and used below.
The deliverable is the UI models, written up in the wiki.
getting an eyeful
Then it is time to do an expert evaluation of existing openType‐features UI and all these UI ideas offered by users when the petition did its rounds. All of these get evaluated against—
- the product vision: does it realise the goals? Is it appropriate for the defined user groups?
- the functionality: can it cope with the heterogeneous capabilities?
- the user research: how tuned is it for the essence of typesetting?
- the UI models: how well does it fit with each model?
All of it gets analysed, then sorted into the good, the bad and the ugly. There will be a tiny amount of gold, mostly in the form ideas and intentions—not really what one would call a design—and a large catalog of what exactly not to do.
The deliverable is notes of interest from the evaluation, written up in the wiki.
warp drive
Then comes the moment to stop looking backwards and start working forwards; to start creating the future. First a solutions model is made. This is a combination of a broad‐strokes solution that cuts the project down to manageable proportions and a defined approach how to deal with the rest, the more detailed design work.
The next stage is to design a generic solution, one that already deals with all of it, all the hairy stuff: text selections of any length, all the heterogeneous capabilities, the typesetting workflow, clear representation of all openType features available and their current state. This will be specified in a wiki, in the form of UI patterns.
With the generic solution in place it will be real clear for the central software library in this small universe, HarfBuzz, which new capabilities it will need to offer to F/LOSS (typo‐)graphical software.
home straight
The final design phase is to work out the generic solution for each UI model. These will still be toolkit agnostic (not specific for KDE or gnome) and, btw, for desktop UI‐only (touch is a whole ’nother kettle of fish). This will also be specified in the wiki.
With this, every (typo‐)graphical software project can go to the wiki, pick a UI model that most matches their own UI structure and see a concrete UI design that, with a minimum of adaptations, they can implement in their own application. They will find that HarfBuzz fully supports their implementation.
While working on Metapolator in the last year I had good experience with sharing what I was doing almost every day I was working on it, through its community. There were encouragement, ideas, discussions, petitions and corrections—all useful. I think this can be replicated on the Create list.
Labels: design stage, fundamental, infrastructure, openType, practical, process, product phase, product vision, top story
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
Peter Sikking is an
experienced
interaction architect. He unabashedly puts
shipping great products at the centre of his design practice. He is known for
his work for Google, Nokia, the
Metapolator &
GIMP
open source projects,
and startups.
What is Peter up to? See his /now page.
- info@mmiworks.net
- +49 (0)30 345 06 197
- imprint
