In my last entry, I linked to a music video of Every OS Sucks by Three Dead Trolls in a Baggie.
It’s really true, every OS does suck – both under the hood and at the user interface level.
I don’t feel qualified enough to comment extensively on the internals of various OSes, as I’m no programmer, but as a user, I (and any other computer user) work with UIs every single day, and I feel qualified to comment on that. I’ve used various graphical UIs in day-to-day use, primarily Windows (almost every version from 3.1 to 7, and I even used 1.01 daily for fun at one time,) but also Mac OS System 7.1 and X 10.5, IIGS System 6.0.1, KDE 3, GNOME 2, RISC OS 4 and 6, and CDE 1.5. I’ve also supported users of varying skill levels on Windows XP. I, however, am not a UI researcher.
This will likely be a multi-part series, hence “part 1.” I’ll be commenting on my opinions of what’s bad and good in a wide range of UIs. I might be able to tie this all together in something resembling a description of a good UI, I might not. If none of this makes sense, or if I’m flat-out wrong about something, please let me know in the comments.
So, let’s get the first thing out of the way: what is a good UI? A good UI is one that makes it as easy as possible to complete your computing tasks. Nothing more, nothing less.
Why is it so hard to make a good UI, then? Several reasons.
First off, there’s different hardware devices. A given UI may be running on something as small as a 1024×600 netbook display (or smaller, I’m not even getting into smartphones and the like, that’s a whole ‘nother can of worms,) or something as large as a 3840×2400 monster of a display. (Yes, I own both extremes.) A UI that feels comfortable on the T221 may feel extremely cramped on the netbook, and a UI that feels comfortable on the netbook may feel sparse on the T221. A good UI will either be well-suited to both displays, or will adapt to what’s available.
Second, and just as important, users work in different ways, and have different skill sets. A UI may be great for one user, and terrible for the next. For example, quite a few people go on about the virtues of the command line as a UI. (For the record, I’m going to be focusing on GUIs, but the command line was the best example I could come up with for this comparison.) It’s what works best for them. However, command lines tend to be hideously unintuitive, and an uninitiated user may find it impossible to complete a task on such a UI. Conversely, an “easy to use” dumbed down UI may be the best for the uninitiated user, yet the power user may find it incredibly arduous to use, due to options being hidden, or a lack of a convenient way to perform advanced tasks. A good UI will be naturally intuitive for new users, while still being able to efficiently support power users. More on “intuitive” later.
Finally, developers may not know how to make a good UI, or may not have time to do so due to rushed schedules. Developers typically aren’t UI researchers, and UI research takes time and (normally) money, so many developers just make a UI that they’d use, especially for open source development – certainly a good UI for the developer, but not necessarily a good UI for general use. One thing that can help with this issue is clearly defined UI guidelines.
One thing that is often a goal of a UI is that it be “intuitive.” What does this mean, and what is normally meant by it?
If something is intuitive, a user can use their intuition to figure out what to do when performing a task – the user does not need to refer to a manual, help files, or the like, and can easily find the correct option. There have been many, many attempts at doing this, some failing miserably, some working passably.
What’s often meant by it? There’s usually two characteristics that are referred to, when referring to an “intuitive UI.”
The first is consistency in the UI. That is, when doing a task somewhere in the UI, the same task should be expected to work similarly elsewhere in the UI. An example is copy and paste – on Windows, the user can reasonably expect that they can copy selected text from any given text field, that the Copy item in the Edit menu, the Copy button on the toolbar (if present,) the Copy item in the context menu, and the Ctrl-C keyboard shortcut will copy the selected text, and that the text can be pasted at the insertion point in any given text field (including the same one) by using Paste item in the Edit menu, the Paste button in the toolbar (if present,) the Paste item in the context menu, or the Ctrl-V keyboard shortcut.
The second is attempting to predict the user’s next action. Some ways of doing this are by providing commands relating to what’s being done at the time, or hiding options that the software has determined are irrelevant at the time. Microsoft Office is well known for this. Such behavior is controversial, however, due to the inconsistency this behavior introduces. For example, Microsoft Office versions prior to 2007 (on Windows) hid menu options and toolbar buttons that haven’t recently been used. While this does reduce clutter, and makes it easier for users to find features that are commonly used, the user may decide that they need to make use of one of the hidden features. In this case, it is not immediately apparent that the options are hidden, unless the user looks at the bottom of the menu or the end of the toolbar. This is arguably unintuitive behavior.
Now, why did I say that these are things that are meant by “intuitive UI” behaviors, and not that they are intuitive UI behaviors? Simple. While the former (consistency in the UI) is a critical part of an intuitive UI, it means nothing if the behaviors that are being consistently performed are themselves unintuitive. I’ll go back to my command line example. Many command line tools are extremely consistent – they accept standard input, output standard output, and offer a reasonably consistent set of command line switches. However, nobody would argue that they’re truly intuitive, as a new user cannot walk up to a machine using such a UI, and with no prior knowledge other than keyboard and mouse skills, complete a task without referring to a reference of some sort. (That reference may be as simple as typing a “help” command, but even that technically requires some knowledge of computers in general. “help” is probably the most intuitive way for a command line to provide help, though. “man” is not, just for the record.)
There have been many attempts at creating a truly intuitive UI, of course. Every present-day GUI is the descendant of such an attempt – Xerox PARC’s Alto workstation. The graphical user interface was developed as an attempt to make a system that inexperienced users could walk up to and use, with little or no prior training – an intuitive UI. Of course, every UI has issues that keep it from being truly intuitive. For that matter, people don’t even necessarily agree on what is truly intuitive, and intuitive is different for different groups of users – a Windows user will find a UI that follows the Windows UI conventions more intuitive, whereas a Mac user will find a UI that follows the Mac OS conventions more intuitive. Meanwhile, a new user may find both unintuitive, and a third set of conventions would be necessary for that user.
One way to make the UI more intuitive that I mentioned before, is hiding features. While that’s usually used in the context of predicting the user’s next action, PC-GEOS and its successors (currently Breadbox Ensemble) used this to assist users with learning the UI.
PC-GEOS applications do not use a fixed window layout. Instead, applications in this OS list their features, the functions of those features, and desired positions for window elements. (This feature also made GEOS a popular option for mobile devices such as smartphones and PDAs in the 1990s.) In addition, as I understand, the features are listed by skill level. The user can set a desired skill level for most (all?) applications, and only the features deemed appropriate for the given skill level are shown, and the UI is laid out the most efficiently for that feature set. Earlier versions of PC-GEOS were extremely aggressive about the level of “dumbing down,” to the point that many applications only allowed one file to be used in beginner mode, but current versions of the OS offer more features in lower skill level modes.
This approach has the advantage of allowing the same code to be used for a UI for an advanced user and a new user, albeit with the weakness of inconsistency between those user interfaces, and hiding potentially important features from a new user. However, if a user determined that they needed to make use of a “more advanced” feature, that feature could manually be added to the feature set currently in use. Careful research would be needed to determine the best set of defaults for each level, however, and invariably, it would still be wrong for a certain subset of users. A better decision, IMO, is to prioritize features, group them in an intuitive manner, and make the most used features the most easily accessible.
One last thing I’d like to discuss for tonight… the Ribbon.
Ribbon is Microsoft’s attempt to replace the menu bar and toolbars of their various programs with a central “ribbon” of functions. Supposedly, this is more intuitive than menu and toolbars. This may well be the case, and from what I’ve seen, the groupings of functions have been reasonably good, although there is still a vestigal menu of sorts left over for some functions.
There are two major problems with Ribbon, though.
The first problem is, quite simply, Ribbon is inconsistent with what Windows and Office users are used to. Therefore, at least for this set of users (the primary set of users that Ribbon-based software is aimed at, even,) Ribbon is unintuitive. Also, arguably, Ribbon is inconsistent with itself, one of the greatest UI “sins” – a UI that is inconsistent with itself is far worse than a UI that is inconsistent with other UIs, simply because you have to learn two UIs to use one, in a self-inconsistent UI – Ribbon claims to move all functions from menus to task-based ribbons, yet a menu still exists.
The second problem is that Ribbon uses a lot of vertical space, and unlike toolbars, cannot be reoriented vertically, so as to use horizontal space more than vertical space. Remember that 1024×600 netbook screen I mentioned earlier? Ribbon is painful to use on such a display. Ribbon may have made sense back when 5:4 and 4:3 displays were common, but widescreens have become common, and UIs for personal computers need to adapt to this change, IMO. (Of course, UIs running on displays in portrait orientation have to be able to adapt to large amounts of vertical space, but very little horizontal space. And, when it’s a device such as a tablet PC, the same UI must be able to switch between the two effectively.)
I think that’s all for tonight. Feel free to flame me in the comments, or provide your own opinions on UIs. I’ll probably post more tomorrow, and it might even be a little more organized. 😉