On of the things most important in UI design is consistency. Consistency is the way we operate in this world. From a very early age, we start learning how things behave, such as "objects fall, but light objects with a large surface area fall much slower". We see things fall over and over, so we learn first, that is how this object behaves, and second, this is how all objects behave. So, when we encounter something new, we know it will fall — we don't have to take the time to learn how it works. This consistency is just as important in UI design, but can be harder to accomplish.

In UI design, you first want to make sure that something behaves the same every time. Every time you click button X, it should do action Y. Second, you want to make sure that things that look similar behave similarly. If button B has an icon that looks like the icon on button X, but it's a different color, or has a small change, then button B should do something similar to button X. Similarly across programs. If button X does action Y in program L, then button X better do action Y in program M. Finally, you want to make sure that things that behave similarly look similar. If button X does action Y in program L, and button B does action Y in program M, X and B better look the same, or at least close.

The idea is that once a user learns how something works, they can rely on it to work that way no matter what they're doing, and they can rely on that particular appearance when they want to do something. This way a user doesn't have to learn each new program they use; they can just apply what they're already learned to it. This consistency actually extends beyond icons and buttons to the entire look of the OS. One of the problems with Windows and Microsoft is that it seems every program has its own look and feel. Sure, there are standard buttons, but it seems every program arranges things how they like; use their own icons; rearrange menus; and often use non-standard buttons and dialog boxes. Microsoft is just as guilty of this as any third-party manufacturer. Look at IE, and Office 97. They seem to follow the standard Windows look fairly well. Now look at Office 2000 and Office XP. They've changed how buttons look, how toolbars and menus act. Then look at Windows XP. It has a completely different look, but all the programs still look like standard Windows programs from 2000 and earlier. This is why skinnable programs with their own interface, such as Winamp are bad — they completely destroy any consistency knowledge the user has to go off of. "Well, I guess those standard symbols for play, forward, rewind, etc are buttons; but how do I get a menu? And where's the title bar to minimize this or move it around? What, you mean I can drag anywhere on it to move it?" Of course, Linux in general is worse than Windows since there is very little in the way of UI guidelines. Gnome and KDE are doing a decent job of getting standard UIs for their applications, but Linux as a whole right now is too fractured to get all applications under a single set of UI guidelines. This is also an area where Mac OS X is very good. Almost all the applications look and behave similarly, even third-party apps. Admittedly, the whole brushed-metal vs. aqua look is a bit troublesome, but on the whole they do a good job of being consistent.

Consistency is especially important within a program. When a user wants to perform an action, they should know to look for a specific thing, which will perform in a specific way. One program that blatantly violates this is the circuit program from Xilinx. Among its many other problems, it was inconsistent. For example, in the print dialogue boxes. There are a few different parts to this program. One was an area to build circuits — place components, connect wires, set in and out gates. Another area of the program was used to simulate the circuit — set functions and such for input, and then see the output and various states of the circuit. In both of these you could print out the results. But the print dialogue boxes were completely different, including the common function of selecting a printer. This is a part of the program which should be very similar if not the same for different sections, and yet there was almost nothing in common between them beyond being able to print to a chosen printer. This was completely unncessary, since I would think first off, they could have shared the code for the print dialogue boxes and shared some work; and secondly, it confuses the user.

But you must not be overly enamored with consistency. Remember that things should only look alike if they behave alike. Sometimes developers seem to think that because they have a particular icon, or because of something is kind of like some other behavior, they ought to make them look the same. This is a problem earlier versions of the Mac OS had, where to eject a disk you would drag it to the trash. The developers probably figured, "Well, ejecting a disk is kind of like getting rid of it; and we already have the trash icon — so let's just make the user drag the disk to the trash to eject it". It was generally un-intuitive and sometimes a bit frightening to users, "But won't my disk be deleted if I drag it to the trash? I don't want that!" This has somewhat been fixed in Mac OS X, in that the trash icon changes to an eject icon when the user starts dragging a disk. Still, there is nothing immediately obvious to eject the disk, before they start dragging it.

So use consistency in the right amount. Make things that perform similarly look similar, and those things that behave differently look different.

In the last article, I talked about visual pattern recognition, and how it is a good tool to use in UI design. Its main application is in icons, especially in menus. Current menus usually use just words to describe what the menu item does. The problem with this is that words take more processing power and are harder to recognize at a glance. The problem is that words first have to be visually processed, then has to be interpreted to a word, which is then linked with the idea of the program. An icon, on the other hand, can be connected to a program directly after being visually processed. Icons can also be recognized by shape and color, and vary more than words do. So I know the icon for iChat is blue and roundish, with a yellow person on the right; whereas Mail.app is blue with a white, jagged border and a dark bird in the center — it also has a red circle with a white number in it when there is new mail. These visual clues are much easier to differentiate between than the words "iChat" and "Mail.app".

Most programs now do a decent job of using icons to represent things. The Dock in Mac OS X is a nice example, because it uses icons for programs, and has a text pop-up when you mouse over it, to get the exact name of the program. But most programs I've seen, though, almost never use icons in menus. Instead, they're just a list of words. This makes it much harder to remember a particular menu item, both where it is and what it does. Instead, we want icons for each menu item. Then also provide text labels on the side, probably always present (since users may often need to skim through all the items, and having to mouse over each item just to get the name is inefficient).

But current linear menus don't accomodate icons very well. Since text doesn't need to be very tall, but can be fairly wide, to fit icons in, they end up being the size of a single character. This isn't very useful, since the icon is so small. Increasing the height of each menu item is probably worse, since now each menu item is taller, and since the user always has to start at the top, making each menu item twice as high results in the user having to move the mouse twice as far. Instead, we need a new, more efficient menu design that is based around using squarish icons instead of text.

The answer is radial menus. When you click to open a menu, the items appear in a circle (radially) around the cursor. Then the user only has to move a constant amount to get to any of the items at this level on the menu. It also makes it easy to use an icon for each menu item, since a squarish object fits on the edge of a circle much better than a short, wide rectangle of text. The other advantage is that this limits the number of menu items available at a given level (with submenus we can still have many, many menu options; but only a limited number can be displayed at once). This may seem bad, since afterall, maybe sometimes you'll want a very big menu, such as a list of every font available on the system. But having lots of menu items makes it very hard to grasp all the options. So limiting it to maybe 10 or so items should make it easier to look at all the options and choose the appropriate one quickly.

If we want more menu items at a given level, there are a few options. The best is to just create submenus; so maybe divide fonts into categories (plain fonts suitable for typesetting, fancy fonts for graphical design, fixed-width fonts, international fonts, symbol fonts, etc) or just categorize them by letter (all fonts with names starting with A, then B, etc). Sometimes, though, we'll need to handle menus that aren't designed this well, so we need an automatic way of handling these. Assuming the menus are fixed size and such, then the way to handle it is to reserve the top and bottom menu items on the circle for up and down arrows, then start filling in menu items until the set of circles is full, and then continue on the next page, to get to which the user has to click the down arrow, and the up arrow goes a page back in the menu. This is similar to automatically creating submenus, though there are a few differences. Another way is to increase the radius of the circle, lor decrease the size of the circles, which allows more menu items to fit on a menu at once. The best solution is probably to allow user settings which specify a maximum radius and minimum icon size, which is used first; and when the limits are hit, start making pages of menus.

Radial menus have quite a few advantages. They give constant access time to a given item, and allow for positional memory (similar to mouse gestures). They support icons for visual recognition, and limit the number of items present at one time, giving the user an easier time in grasping all the choices.

I've heard Mozilla has an add-on for pie menus, which (I assume) is essentially the same idea. Neverwinter Nights also had a nice implementation of radial menus, complete with icons for menu items and submenus. Other than those, I haven't heard of any major implementations of radial menus, possibly because current interfaces are so set in the standard linear menus.

Recently ArsTechnica posted an interesting article on how to redesign the Mac OS X Finder. A lot of the article, though, discusses ideas that are in general applicable to UI design. (As an interesting side note, he discusses something called "live searches" which sound remarkably similar to something I proposed before. While I can't say I'm the first to have thought of it (the article mentions this was a feature of Apple's Copland), my proposal to convert the entire file system over to this type of access method and various other enchancements to make this inteface more useful is beyond what live searches are, and I haven't heard the idea anywhere else yet)

A quick summary of spatial orientation, as described in the article. The basic idea is that we are used to working with objects in the real, spatial world. Interfaces such as doorknobs, light switches, pens and paper; anything we interact with in the real world. The advantage to these is that they are simple, coherent and stative. They obey the physical laws which have become ingrained to us, and they do not randomly change shape, size, appearance, etc. Since we are so used to these kinds of objects, copying the ideas for a virtual interface in a computer makes sense to allow the user to apply previous knowledge to a new system — instead of attempting to learn an entirely new world.

The article then applies this to the Finder by having consistent, real-world objects present to represent the more virtual concepts of files (not that files are an abstract concept, but to users they are fairly virtual, especially when you have things like hard links — there just aren't real-world corollaries for that). So a spatial Finder would always have consistent views of files and folders, including only having one view of a folder open at a time, or having icons for files. He also says icons and other visual cues should correspond to real-world objects so that users have a familiar visual cue to associate with. Part of this is having objects obey real-world behaviors, such as staying in the place they were left, maintaining size and shape, etc.

I think the main idea, though, is visual pattern recognition. Files are recognized by icons because of the visual pattern of the icon. The article seems to imply that these visual patterns should correspond to real objects, but I don't think that's necessary. Sure, we can't recognize any given pattern, especially if there is lots of detail — but humans are very good at picking out and recognizing patterns. For example, letters of the alphabet have no physical manifestation, but any English speaker will almost instantly recongize the letter 'A', even out of context. So having visual patterns correspond to real objects isn't necessary for easy recognition; it just has to be a relatively simple visual pattern that the user knows.

This is where problems can arise — everyone does not know the same patterns, and learning new patterns takes time and frequent use. Not everyone using the system will necessarily know English, so using letters as icons may not be a good idea, since not everyone will instantly recognize those (using full words has other problems). So the obvious thing to use is real world objects which people do have familiarity with — hence use a file folder icon for filesystem folders, since almost everyone who is likely to use a computer is familiar with a file folder (or at least, that's the way it probably was when the GUI first came into practice. I suppose it's also because file folders are a fairly good correspondence to the virtual folder).

So does this mean we have to stick completely to real objects? No, I don't think so. There are plenty of visual symbols that don't necessarily have real object correspondences, such as many signs and notices use (arrows, radiation symbol, and many other iconographic images). Any visual patterns used on the computer just need to be simple enough to fairly easily to memorize, distinct enough to quickly recognize, and hopefully has some relation to what the icon is for, so it is easier for the user to make a connection between the icon and what it does. This connection almost necessitates using something from outside the computer, because this connection requires the icon to represent something; and since a computer only contains numbers, everything else is an abstraction invented by designers and users, so there is nothing that can come from the computer.

So: the idea of spatial orientation isn't completely necessary; rather it is the consistent visual patterns that are needed. If the user connects the idea that a particular visual pattern corresponds to a particular idea in the computer, then all that is needed is for the objects to behave how the user expects them to — which in many cases is based on physical laws, but they don't have to, especially as users become more familiar and comfortable with the nature of digital information.

It's all well and good to say a user should be able to sit down at a well-designed UI and be able to use it, as long as they have knowledge about the task they are performing. But at some point we have to make some more expectations about the abilities of the user. Assuming we are talking about computers (which is true for now; later I'll talk a little about UI in the real world), we will have to assume some basic knowledge of the computer. At a minimum, we will assume the user knows how to use the devices attached to the computer for interacting with it — I suppose UI design can also apply to computer interface devices, but for now we're talking about software, so whatever hardware the user has is what they'll have to use. In general, we will also likely assume that the user is proficient in the language that the UI is currently in. For some things, literacy is not a requirement, since text-to-speech is possible; so whatever text there is can be spoken by the computer. In a realistic interface, though, at some point we will need to communicate via some kind of language. Pictographs, animation and sound can go a ways, but it cannot communicate everything. And with a well-written UI, localization should be relatively easy (the programming part that is; not necessarily doing the actual translations), so the language requirement probably isn't so major.

The question then is, "Are these the minimum requirements? Is this really all the user needs to know to use a well-designed UI?" While the requirements of understanding the language of the UI (which hopefully is the user's native language), and knowing how to use the devices attached to the computer for interacting with it may not seem like something major in the way of requirements, remember that there is also the implicit requirement that a large number of people can use the same UI. This is starting to get a ways from our perfect UI which is linked directly to the user's mind and is customized to them — now it is much more difficult to turn the user's ideas into fact.

So what exactly does all this mean for UI design? What can we derive from this? And is it really true that the user needs to know (almost) nothing about a computer to use it?

The point of a user interface is to allow the user to accomplish some task — and in this manner transform their ideas into fact. That is, a user interface is a way of helping the user to do or create something that they wish to do or create. This could be something simple, like "View this picture", or something much more complicated like "Create this program to allow people to create 3D models". In both cases, the user has an idea or thought of something they wish to accomplish, and the user interface is the means by which they accomplish this (not to say that the underlying code that does a lot of the work isn't important, but it is via the user interface that the user does the task — without that, the algorithms are useless).

There are many, many kinds of user interfaces, from old, low-level UIs (such as flipping switches on the front of the computer to input a program) to the GUIs common to most operating systems today (Mac OS X, Microsoft Windows, KDE). Not all of these are good UIs; in fact, I'd say it is impossible to create the perfect UI. The perfect UI would be something that can most directly and quickly translate the user's ideas into fact. This would mean doing exactly what the user was thinking of in the best way possible. The perfect UI would not have to be learned, nor would a user every be confused by it. Since this would require (at a minimum) a direct connection to the user's brain and an interface customized to each user, we have to settle for something more realistic. The main idea to focus on, though, is that the user should not have to learn a UI to accomplish the task — in a good UI, the user should only need knowledge related to what they want to do, not how they need to do it. As an example, we can't expect that someone who knows nothing about drafting should be able to sit down at a CAD (computer-aided drafting) program and design a building, no matter how good the UI is — there are other skills and knowledge necessary to perform this task irrespective of the computer. However, an experienced drafter who has worked on paper before should be able to sit down at a CAD program with a well-designed UI and be able to design anything that they could with paper. That is the ideal, at least.

I'll try to stick to principles of user interface design for a bit, and as much as possible stay away from the details of hardware (mouse, keyboard, monitor, etc.) and software (buttons, windows, GUI, text, etc.).