Explaining typeface design

This morning Fiona, Peter Bil’ak and I visited the UBA to see some of the work of the postgraduates on the UBA course (see the Typography at Reading blog). One of Henrique Nardi’s images captured me sketching an aide memoire for the session, which is worth linking to here to have handy for the sessions next week.

The axes describe a simple framework for talking about typeface design projects. At the top of the diagram is the Designer, and at the bottom the brief (and the client, who represent the requirements of the users). The left of the horizontal axis represents the Functional requirements in the project, and to the right the expression of individuality and Identity through the design of the typeface.

Palettes are evil

In a recent piece for #Eye80 I lamented the loss of insight in document design that the vertical flat screen and zoom brought. I also dropped an aside that “palettes are evil”. I wasn’t clear enough, and confused @mmBubbleTea who thought I meant colour palettes. I meant the interface ones, and I apologise for the confusion. I might as well explain briefly why I don’t like palettes.

When the basic conventions for interfacing with apps got established, apps couldn’t perform the amount of operations we see in pro apps today. Even on smaller screens, there was enough space to fit a range of commands. But as features increase, there is an increasing competition for screen real estate: the document (your constant focus) versus the chrome of the app (and the OS, of course – not so much on Windows, but very much so until recently on the Mac). The problem is not only that the vital area of the screen decreases, as more selections and commands need to be accommodated; it is that only a few of those are you likely to need to select.

As apps often compete on features, and propagate those from one category of app to another (e.g. vector commands to a page layout application) the number of possible choices balloon. Palettes then become an exercise in squeezing options in. This happens on two levels: one, grouping related options and fitting them on a single object on screen; and second, the management of all the possible groupings. Adobe apps are particularly problematic in this respect: there simply are too many things to add, leading to problems at both levels: what to put in each group (palette) and how to manage the various palettes themselves.

Look at this screenshot, for example: I am designing at the level of a paragraph, but cannot see the options for both paragraph styles (the basis for my design choices) and the “local” paragraph palette. I cannot see both paragraph and character styles at the same time, without “unhooking” the palette from the column. This is problematic, as I then have the absurd situation in the second image, where the “heading” of the palette floats over the document, and the palette hangs to its left. (Bad luck if your focus was the text underneath!)

InDesign screen shot

The first image also shows a big problem with the secondary options, which are enabled by a really small button, next to the “retract palette” one. A big secondary surface (actually, tertiary, if you count the column of palettes)  opens up, covering yet more of your screen, in a visual style that departs completely from the language established by the column and the hanging palettes. And I can’t keep the damn thing open, even though things like “Keep options” might be pretty useful to have hanging around (pun unintended).

Indesign screenshot
And why  do I need three palettes to design a table? In my typographer’s mind the table is a single object, with a cascade of attributes. Can I please see all in one go? Of course, the explanation is obvious: the design interface follows the engineering, rather than the other way round. The app applies attributes in discreet levels (document, object, paragraph, word, and so on) and the palettes follow this structure.

In recent years we have seen app developers trying to second-guess what the designer is working on, and what they might want to do. They then try to provide only the pertinent options. (Cue Office’s ribbon, or indeed InDesign’s “workspace”.) Apps that are unencumbered by legacy features have tried smarter interfaces (Pixelmator and Acorn come to mind), although their developers are having to say clearly that feature parity with Photoshop, for example, is not their objective. This may be a good thing, and presage the current approach of tablet apps, where one-app-for-all models are eschewed for the “does a few things really well” approach.

The wider problem of interface design for command-heavy apps is whether the developer thinks about the design process in ways parallel to the designer (cough, Fontlab, cough!). Designers usually think about a cluster of attributes at the same time, and work in their mind with relative terms. They have to translate these to specific (and often meaningless) measurements, which detract from the real: the pattern of form and counterform, foreground and background.

Here’s a simplistic example. Let’s say I need to make some decisions about these two lines:

apples and oranges

Should I really be thinking separately about type size and linespacing? Column width and depth? In what units? Actually, I tend to think in fruit:

apples and oranges

It doesn’t matter what the units are, and indeed the tendency of apps to snap to “neat” round numbers is a big problem. I think only of relative relationships, how much is this in relation to that, and them to the other? And, if I’m more careful, I’m really thinking of the white space surrounding the column as an integral part of the paragraph, rather than as an attribute of the containing frame. So, what I want is a design environment that reflect my thinking – not an app that requires me to translate design decisions based on relative proportions into a set of discreet, unrelated measurements.

fruit in a box

Finally, the elephant in the room: the screen size on which we are working. Whereas large screens are becoming ever more affordable, we are seeing more complex tasks performed on tablets (okay, on iPads). We won’t see page layout apps rushing to migrate to the iPad, although the argument for some editing on-the-go cannot be avoided. But we are already seeing many good image editing apps on the iPad, and it is not a huge leap of the imagination to think of a web-based layout environment with a client on the app.

Well, that was a rant and a half.

What, how, why

I recently saw Simon Sinek’s How great leaders inspire action TED talk (linked to in the Open letter to BlackBerry bosses, via @daringfireball ). It is slightly evangelical in tone, but the core message survives scrutiny. The idea that sustainable actions flow from a vision, rather than objectives, is worthy, as are the implied messages of clarity, simplicity, and direct accountability. This approach applies particularly well when seen in a context where the outcomes are not gizmos (physical products of any kind) but new conditions for people.

I wondered how it applied to my direct environment, and scribbled the concentric Why / How / What above. Deciphered, it reads:

• Why: change the way people think about design

• How: build understanding of context | critical thinking | reflection

• What: run a course in TD [typeface design]

One of my ways to test the model was to put different things in the last line (our actions) and still the cascade makes sense. It works for the TDi summer course, and it works when the model for our new course, soon to be outlined in New Orleans.

It also explains, for me, why so many people connected to the MATD go out there and do stuff. Conferences, meetings, jam sessions, things that are driven by a deeper desire to change the way people think about design and typography.

I’m okay with that.