Let’s delve further into each of those in more details.
The concept of familiarity is almost self explanatory. It talks to the way people “expect” things to happen. A good example of this is the web browser. Most people expect the browser to be divided into seven areas: an application menu, which mirrors the look and feel of other applications on their operating system (such as file, edit, view, bookmarks (Microsoft Internet Explorer calls those “Favorites”), Tools, and Help); a loading graphic (which is animated when the browser fetches a page); a navigation area, which includes familiar buttons such as backward, forward, stop, refresh, and home; a web address box where they can type in an address to get to a web site; a bookmark (or “Links” as Internet Explorer calls it) bar, which lists sites that are bookmarked; a main window, where the content of the site they are looking at is displayed; and a status bar, displayed below the main window and providing information on whether things have downloaded or not.
As you can see from the list of what makes a browser screen, this is already a fairly large set of components to think of, when designing a browser. Mozilla, my favorite browser, succeeds in mirroring most of this properly. However, the lack of a home button in the navigation bar of the default install of the software may confuse a lot of users (There is a patch to resolve that problem but beginners will not know this. This creates some concern for the user, which easily unsettles them because, if this part is unfamiliar, what else can they expect?
The challenge here is to start thinking like a low-end user. Mozilla is a very powerful tool but how do you make it easier? As developers, we often forget that the people who could use our software may not know as much as we do (or worse, some developers believe that people should be experienced enough to use their code). The best way to handle this when working on designing screens as part of an OSS project is to show it to people who are not programmers (family members, or non-geek friends are useful here!). If it takes a regular user more than a few minutes to understand what the program does, you may have a usability problem.
Consistency talks to a certain level of expectation. As a general rule, users expect a program to act in a consistent fashion. Consistency issues arise when a piece of software looks different from area to area. For example, if you let the designers loose on your interface, you may end up with different fonts, font sizes, buttons switching positions, etc… This happens a lot when skinning applications.
In order to maintain consistency, ensure that your application reacts in the same way on its sub elements as it does on the top ones. For example, if you use buttons like
Cancel next to each other, make sure that they always show up together so that you don’t end up with an
Cancel button standing on its own or with something like
Cancel in one screen and
Cancel in another.
A consistent interface breeds familiarity, which in turns makes your application more usable.
The concept of generalizability expands on consistency but goes beyond your application. Generalizability talks to the wider world of all applications like yours. As a result, it’s kind of a pack mentality thing. If you are working on building a better mousetrap, you have to make sure that people realize that it is a mousetrap. As a result, you have to use some of the elements and attributes of other mousetraps.
The best advice in terms of maintaining generalizability is to look at what similar applications do. For example, going back to the browser, the edit preference screen is generally organized in subsections. In the case of Netscape and Mozilla, they show up in a category list on the left of the preference screen. In the case of Internet Explorer, they show up on the top as tabs. In the case of Apple Safari, they show up as big icons on the top of the preference screen. As you can see from here, there is some level of consistency in terms of organizing that content.
Another example of generalizability is the tabs implementation in Apple Safari. Mozilla and Opera had taken an early lead in establishing tabs as part of their browser offering. Opening multiple tabs showed a tab navigation bar and opening a new tab on the mac implementation of those browsers was done by using
Apple-T. When Apple implemented their solution, they bowed to the consistency rule by implementing tabs in the same way as its predecessors.
Predictability is, as expected, building a system that works in the way you expect. This is much tougher than one would think as level of expectation are different based on user levels.
For example, advanced browser options in Internet Explorer are under in an item called “Internet Options” under the “Tools” menu. The assumption here is that anything that is user configured is optional and that, in order to configure it, one would use a tool. On Mozilla, the browser options are in an item called “preferences” under the “Edit” menu. The assumption here is that the user would want to edit their preferences. Two different paths to the same area, which can lead to confusion.
Because Internet Explorer has the leading market share, we must fall back on the generalizability principle here as to where a user should expect those options to be. This points to one of the issues related to all the points brought up so far: sometimes bad interfaces are what the user expects. Trying to change that is often difficult and goes against the concept of learnability.
The last item in learnability is simplicity. The simpler the interface, the easier it is to use. Here’s an example: If I create a button called XML in an application, fellow geeks will expect that once they click on that button, they will see the XML version of the document I’m presenting. However, someone who does not know what XML is will look at that button and be confused. As a result, that button should not figure prominently as part of my default interface.
A good way to enforce simplicity is to provide a regular user and an expert user setting. For example, Apple Safari is a very basic browser when you look at the out of the box version. However, several tools can reveal new menus that will be used by experts. If I were involved in development on the Mozilla interface, I would recommend that it ship with a default dumbed-down set of menus. In the preference setting, one could turn on the super-user mode, which would then provide all the remaining menu items. This would allow to create a simple-looking browser, while retaining all the great features under it for more advanced users.