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!)
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).
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:
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:
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.
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.