brian will . net

In response to a challenge by Aza Raskin to come up with a better way of tabbing in Firefox—in particular a solution that scales better the more tabs you have—I produced this mockup in Javascript. Be clear that, because of the way the tab previews are done, the performance is creaky and not representative of what a proper implementation would be like. Please, use your imagination and pretend the previews pop-up instantly. Also understand, it ONLY WORKS IN FIREFOX. (While it won’t work at all in IE, it should mostly work in other non-Firefox browsers, though I haven’t tested any).

The rationalization is given on the page, so I’ll simply discuss here why I rejected some ideas proposed by others and also consider some variants on my design which might be even better.

In the comments of Aza’s post, a number of people expressed a desire to introduce alternative ways of conceptually ordering the tabs other than the default order in which you opened them, e.g. some wished to be able to group their tabs (which you can kind of do already by reordering), some wished to see their tabs listed by chronology of the pages (as opposed to of the tabs), and some wished to see their tabs in a web displaying heritage (which page was opened from which other page). While there might be something to these ideas, I avoided them as there seemed to be easier gains to be made that didn’t involve conceptual changes for the user. I wanted to improve the tactile experience of dealing with many tabs.

Others have proposed some kind of zooming UI. Again, there may be something to this idea, but until hardware support can be implemented consistently across platforms, I don’t see this happening. Besides, it’s a tricky thing to get right, as many users are easily disoriented.

Others mention multiple tab rows. This idea is problematic for the same reasons displaying any one-dimensional information in rows is problematic: things move around in unexpected ways when the bounds gets resized and tabs are added and removed, messing with the users spatial memory of where their tabs are. (Of course, text has the same problem, but text has paragraph breaks that help a large section of text mostly retain some recognizable shape as it is edited and its bounds resized.)

As for variants on my design:

A major flaw of the current Firefox tabbing which my design doesn’t really conquer is that I find myself often confronted with having to do multiple searches to find a tab: by reflex, I first search through those tabs I can see, then I’ll mousewheel back and forth, then occasionally I’ll go into the full list on the right if I still haven’t found the tab. The problem here is that the worst-case scenario searches are very expensive and distracting, but they wouldn’t be if I simply went to the full list to begin with. As nearly good would be if I couldn’t scroll the tab bar at all, forcing me to go into the full list of tabs sooner; in this scenario, we’re actually better off keeping the number of tabs visible in the main bar rather low, say 7-9 at most.

If we embrace the idea that the full tab list should be used more often, it then makes sense to better purpose the main bar. Rather than show tabs which occur consecutively in the full tab list, the main tab bar could display the last viewed tabs in the order they were viewed. In this design, you actually wouldn’t ever see the current tab in the main tab bar as you don’t need to click on it, but you’d still find it in its proper place in the full tab list.

If this is too confusing, perhaps get rid of the main tab bar altogether and have the full tab list button sit by itself to the right of the search box.

I’ve also considered simply having a single vertical sidebar for tabs. This would be like having the full tab list always open. While you might object to the loss of screen space, I’m not sure it would be so bad, especially for wide screen users, who often have to artificially make their Firefox windows narrower for reading, anyway. The Vertigo extension already offers Firefox users vertical tabs, but it could be improved:

• The tabs bar should not be as wide as the history and bookmarks sidebars are by default, not really for functional reasons (at least on big widescreen monitors) but rather aesthetic ones.
• Each tab should be two lines high for easier clicking and so that titles can wrap onto two lines if needed.
• Hovering over a tab should display a preview (as in the demo) and any part of the title cut off should appear extending out of the tab bar into the page. (In fact, I’m thinking that hovering over the vertical tab bar should make all cut off titles appear in this manner; even with the titles extending out of the sidebar, you would still be able to see where the sidebar ends, so when you mouse out of the sidebar, the titles would all go back to normal.)

This last week I’ve been getting familiar with Vim. I’ve dabbled a few times in the past, but this time I’m finally feeling comfortable enough to stick with it. I was quite annoyed with having to hit ESC all the time, but a neat tip is to set this in your config file:

imap jkl <esc>
imap jlk <esc>
imap kjl <esc>
imap klj <esc>
imap ljk <esc>
imap lkj <esc>
set timeoutlen=500   " cuts down the pause time you'll see after typing j, k, and l

…so now you can get out of insert mode by smashing ‘j’, ‘k’, and ‘l’ simultaneously. This will, of course, conflict if you ever need to type one of these sequences, but those are surely quite rare and work-around-able. I’m even going to experiment with reducing this just to ‘j’ and ‘k’, which is itself a really rare sequence in English. (Maybe ‘s’, ‘d’, and ‘f’ or just ‘d’ and ‘f’ can be set to ESC as well.)

If you don’t like that solution, other good choices are:

imap <S-space> <esc> " shift-space to get out of insert mode

…and:

imap <S-enter> <esc>  " shift-enter to get out of insert mode

I mention Vim because I recently played with the alpha of Archy, which is a project to implement the ideas of the late interface theorist Jeff Raskin, and its text editing mode feels much like Vi stripped down to the essentials for the common user. Here’s a quick summary of Archy’s interface:

• The primary part of the interface is one big text-editing window; there’s only one sequence of text, but the text is separated into ‘documents’ by special divider lines (which are inserted by the ` key).
• Navigation up and down the big glob of text is done primarily by holding down an alt key and typing a string of text to “leap” to. Using left-alt does a back search for that string while right-alt does a forward search. Releasing alt takes you back to typing mode at the location you just leapt to. To repeat your last search, hold capslock and tap alt (right-alt for forward searches, left-alt for back searches). Having to hold down alt while typing is pretty awkward and uncomfortable after a while.
• This ‘leaping’ feature with the alt-key searching is also how you select text: the selected text portion is always the section between the place you last leapt from and leapt to.
• The user issues commands by holding down the capslock key, then typing the command. E.g. [capslock]-C-O-P-Y to copy the highlighted text. Even with auto-completion, having to hold down capslock while typing is pretty awkward, especially if the command contains an ‘a’, ‘q’, or ‘z’.
• Text can be formated (coloring, fonts, style, size, alignment, etc.) by highlighting text and issuing a command.
• And for some reason, to get a key to autorepeat, you must triple-tap it before holding it down. (This is really annoying, especially with the navigation and backspace keys.)

Text-editing is the only part of the alpha, but Archy’s other key component will be what they call the Zooming User Interface (ZUI), which I take it is where non-textual elements will reside. How these components will fit together, I’m really not sure.

What to make of this? First, I’ll say there are some things I admire about this approach—mainly, Archy bravely recognizes average users can cope with a few non-discoverable elements: as long as the set of basic concepts to learn is small and worth the pay off, it’s OK—contra Steve Jobs—to expect users to learn something. Archy strikes me as an attempt to bring the Unix philosophy to the masses: rather than relying upon packaged solutions to problems, users are encouraged to build upon a base of simple yet powerful mechanisms; Archy simply starts from a clean slate, dispensing with the accumulated detritus of 40 years of terminals and programmer conventions, keeping things tidy, sacrificing power for approachability.

This said, there are glaring faults with Archy as currently available. First, having users hold down alt and capslock while typing is clearly not going to fly, as it’s difficult for even expert users, let alone the majority of users that have trouble touch typing. Yes, the purpose is to eliminate modality, but this is clearly not a realistic solution. (Maybe we need special keys below our space bar which we can hold while typing more naturally, or maybe the spacebar itself could be used.)

Really, modality is not as bad as UI orthodoxy claims. Keep the number of modes few and try to eliminate unnecessary ones, surely, but modality is extremely powerful, and to do it right, you really just have to give unmistakable visual, auditory, and feedback cues to the user conveying what state the interface is in. (A good test is to see what happens when users step away from the computer then come back later; if they mistake the mode they’re in, you have a problem.) Archy’s cues are just too damn subtle. For instance, I found myself confused when I started typing because sometimes Archy would move my cursor to some other document; turns out I was trying to type in a ‘locked’ document, but it took me a number of tries to figure this out as the message Archy briefly flashes is black text superimposed over very similar black text at the top of the screen; it’s great they didn’t annoy me with an ‘OK’ pop-up, but there’s unobtrusive and then there’s covert. In general, Archy has far too few elements of on-screen guidance, likely because the developers are too enamored of the idea of an interface-less interface. At the very least, Archy should have a training mode in which at least some screen real-estate is devoted to guiding new users.

Also problematic is how Archy messes with the user’s expectations about character keys, giving the keys surprising behavior in certain contexts such that they don’t always produce their usual characters. Now, there are obvious cases where average users quickly adapt to character keys not producing their respective characters on screen—games, for instance, often make use of the alphanumeric keys for non-text purposes—but such programs usually clearly delineate between typing mode and non-typing modes. In contrast, Vi, Emacs, and now Archy violate this barrier, messing with character keys in the context of typing text. In Archy, you find yourself in a few annoying moments like you do when first using Vi(m) where it’s not responding like you expect and you just can’t understand why.

Fortunately for Archy, both of these faults—inadequate cues and poor key assignments—can be fixed, but I wonder if the project will be willing to do so, as it requires compromising on its ideals of a totally modality-less and interface-less interface.

Title translation: ‘Don’t tell me you find this difficult to understand purple monkey dishwasher (version 3)’.

Preston Gralla on O’Reilly Net complains that Linux package names are preventing wider Linux desktop adoption. While I find his claim that Linux will never get there extreme, I do agree this is a significant hindrance.

Such package names simply shouldn’t be presented to regular users at all, even in the context of browsing packages. Sure, people can just ignore them, but don’t underestimate the psychological toll of being confronted with a stream of information you can’t even categorize let alone understand.

More generally, I oppose the Unix/old-style-programming practice of privileging ease-of-typing and compactness in names over descriptiveness. Even for those attempting to verse themselves in the lingo, the level of contextual familiarity presumed by this preponderance of abbreviations makes the learning curve very steep.

I don’t have to be Aunt Tillie to crave a simpler desktop computing experience. Whether I’m using Windows, OS X, GNOME, or KDE, my current work flow gets tangled as I juggle several open folder windows, half a dozen instances of Firefox with 30 tabs between them, a text editor, Google Talk, Eclipse, terminal windows, a media player, and sometimes more; on top of this is the ever expanding mess that is my hard drive. This basically sums up my two main computing problems: my desktop is an unstructured mess of windows, and my hard drive is (between major cleaning jaunts) a mess of files.

The second problem, the files problem, is being partially addressed by desktop search (Google Desktop, Beagle, etc.), but that solution doesn’t really help keep my drives clean—it just let’s me cope better with the mess I create. I think the real solution will be in adding tag-based directory structure onto our current hierarchical directory structure (yes, we would have to meld the two), but that notion will have to wait for a later post.

As I argued in the previous post, the root of the first problem (window management) lies in the desktop metaphor itself and the dominant GUI conventions of the last twenty years. To deal with this problem, we should first step back and analyze what purpose the desktop serves. The GUI desktop is, at a minimum:

• An interface for starting applications, for switching between open applications, and for allotting screen space between open applications.
• A common set of interface elements for applications, often including guidelines for the use thereof to achieve a cross-application standard look-and-feel.
• A data sharing mechanism between apps (copy and paste).
• A common mechanism for application associations—what applications should be used to open such-and-such a file or send a new email, etc.
• A set of system-wide keys, e.g. ctrl-alt-delete on Windows.

And because most users don’t/can’t/won’t use a command-line, desktops include a minimum set of apps:

• File management.
• System/hardware configuration and system utilities (e.g., a GUI non-destructive partition resizer—which has been too long in coming to Linux live-CD’s, frankly).
• Program installation/removal.

So what should the desktop not do? The standard Linux distros all come with an additional assortment of basic apps (web browser, office suite, mail, etc.), which is great, but I think integrating such things into the desktop (or giving naive users the illusion of integration) is very risky and of dubious benefit. The problem with such notions is that they smell of ‘ad hoc-ist design’, i.e. design which tries to meet needs by making exceptions to the rules rather than by applying the rules. Ad hoc-ist design evinces an unfortunate fact about design: it’s easy to come up with features; the hard part is devising features which make other features unnecessary. At a minimum, ad hoc-ism fails to minimize complexity; at it’s worst, ad hoc-ism introduces complexity, and that goes for all parties— for designers, for implementers, and for users. If your design evinces ad hoc-ism, it’s likely because your core mechanisms don’t fit your needs well enough, so rather than piling on more features, it may be time to rethink those mechanisms. Any proposal to expand the desktop should heed this advice, but most such proposals I’ve seen don’t (e.g. see here).

For instance, writing two years ago on O’Reilly Net, Jono Bacon (of LugRadio fame) suggested that project management should be promoted to first-class status as part of the desktop [link]. Jono’s suggestion basically requires three things: 1) integrating features of a personal information management (he calls it ‘project’ management) application into the desktop; 2) implementing an automated personal information data sharing mechanism for applications; 3) making applications work with this mechanism.

Now, Jono may actually be on to something here: his core complaint is that some applications should be able to automatically share certain kinds of data. Problem is that automated data sharing between desktop apps in general is the proper problem to tackle—after all, what’s so special about PIM? Now, lack of a general desktop data-sharing mechanism—let alone an automated one—is actually a long standing problem. Arguably the time for a solution has come, but narrowing the problem and tying the solution to programs of a specific domain would be hurtful in the long run, both for the sake of solving the general problem and the domain-specific problem: the mechanism that would result would likely be too tightly coupled to particular apps, discouraging the formation of an ecosystem of competing experimentation and natural selection.

I can understand Jono’s frustration: the Unix people tend to see every data sharing problem in terms of the mechanisms already existing in Unix (there are quite a few of them, after all), and so they don’t exactly rush to fill in gaps that hinder certain problem domains. Who knows, maybe something already exists to meet desktop data sharing: copy and paste via web services, anyone?

Anyway, I’ll finally present my desktop UI design later this week.

Continuing a discussion of desktop UI from the previous post. Be clear that most of what follows applies equally to Windows and the Linux desktops; my point is that Apple popularized these ideas and the others—-misguidedly—-still follow Apple’s lead.

Compared to Microsoft, I don’t especially begrudge Macs for their existence, and I do recommend them over Windows to naive users who don’t have anyone to maintain and set up their boxes for them. Still, it annoys me how many people have drunk the Apple koolaid and believe that OS X has anything on the basic Windows experience beyond gloss (and an ‘it just works’ quality earned only by a controlled, minute hardware and software landscape); just about everything beyond a few features of the OS X interface is just arbitrarily different from other desktops. Macs wouldn’t annoy me so except for how their influence perpetuates through fashion stupid graphical interface design ideas which both Microsoft and Unix desktops have slavishly followed. Contrary to popular opinion, Macs are not the end-all/be-all of usability, and in fact, Macs have long perpetuated some erroneous thinking about usability. There are several things seriously wrong with the desktop/windows metaphor, and Apple is responsible for most of them.

[...]

The Linux community is often accused of being poor at catering to non-expert users, but this is a misdiagnoses. Contrary to myth, the community is not full of old Unix beards demanding the rest of us master perl before they give the rest of us the time of day. Surely, many Linux users lament that more people don’t see the virtuous ways of the command line, but very few of them still refuse to accept that most people just have better things to fill their heads with than cryptic Unix utility names, parameters, and Bash syntax. And this acceptance is not just reluctant: there are large projects (GNOME and Ubuntu first among them) whose primary mantra is to make Linux bare bones simple enough to bring naive and non-programmer users a painless Linux experience.

The real problem with the Linux community is not that they disregard non-expert users but that the Linux community fails to account for the sliding-scale of expertise in between ‘competant Linux installer/admin’ and ‘Aunt Tillie who thinks that the blue E is the Internet’. (“Aunt Tillie” is the name of the naive Linux user in Eric Raymond’s essay about Linux usability, The Luxury of Ignorance.)

[...]

Here’s the first of a series of posts I’ll write about interfaces.

The use of icons in GUI’s is usually a misapplication of the truism that, ‘simply having users point at the very thing they want is the simplest and most intuitive kind of selection’. The problems are that:

1. Pictographs do not scale as well as text because you can’t alphabetize or do searches on images.
2. As you add more icons to the user’s view, the visual distinctiveness of each icon quickly gets blurry and ambiguous, thus defeating the sole true virtue of icons.
3. Icons are generally not “the very thing” that users are looking for. A pictograph typically provides hints about the thing it represents but is not synonymous with the thing itself.
4. Worst of all, interpreting pictographs is more mentally taxing than reading a word or two, especially when the semantic content is even mildly abstract.

The crux here is that it is far easier for most people to recall the general qualities of a picture—its dominant colors and overall shape—than it is to recall its precise details. Compared to abstract images, images of recognizable objects are much easier to recall details of because we can mentally fill in the blank spots with our assumptions of what such objects look like (so this kind of recall is actually partially false, but it generally works well enough). This explains why most icons in software are so bad: most icons found in software have historically been small, indistinguishable messes that most users just come to think of as abstract shapes even though their designers tried to make them recognizable objects.

Now suppose I know what I want my software to do but don’t remember at all how the interface designers decided to label that function, either with text or an icon. If I’m looking for a label, I have to figure out what words the designers chose to describe it, which often requires consulting my mental thesaurus. In contrast, if I’m looking for an icon, I have to figure out what words the designers chose to describe it and then figure out how the designers chose to represent it as an image. While the number of synonyms for a particular concept can be frustratingly many and elusive, the number of visual representations for a concept are innumerable: even if you narrow down the concrete object(s) being depicted, there are still the variables of perspective, composition, style, and color (sure many real-life objects only come in one color, but many don’t; in fact, looking over the icons in a few applications, I notice a strong majority have basically random color assignments either because of the nature of what they depict or because of the need to make them stand in contrast to their neighbors).

So I’ll posit a few rules about when and how to use pictures/icons:

1. All but the most frequently encountered icons should be labeled by text. Many applications omit text labels because small, unlabeled icons allow for buttons that minimize space use (see Photoshop). This is a poor trade off. First of all, for the issue of image recall outlined above, but also because even the best designed icons rarely communicate their function as clearly as a word or two of text . In fact, the real utility of an icon is that its shape and color makes it noticeable to peripheral vision or visual scanning, so they help users find points of focus and do an initial culling of their possible options; at that stage, however, users have only narrowed their options and prefer the relative precision of words to help them make their final selection.
2. Icons should be simple in shape, distinct in silhouette, have contrasting interior lines, and never use more than two colors.
3. Icons should be as big as necessary to make them conform to rule 2.
4. The number of icons that it is acceptable to use is proportional to how large and distinct they are, vis-a-vis rules 2 and 3. The array of icons found in today’s typical complex apps, like word processors and Photoshop, is too many by a factor of about three.

The next post about interfaces will talk about how the World of Warcraft interface could be applied to the desktop.