Usability 101: Learnability

The con­cept of learn­abil­ity is a key one to usabil­ity design. Basi­cally, it boils down to how easy a sys­tem is to learn. This, in turn, can be bro­ken down into five components:

1. famil­iar­ity
2. con­sis­tency
3. gen­er­al­iz­abil­ity
4. pre­dictabil­ity
5. sim­plic­ity

Let’s delve fur­ther into each of those in more details.

Famil­iar­ity

The con­cept of famil­iar­ity is almost self explana­tory. It talks to the way peo­ple “expect” things to hap­pen. A good exam­ple of this is the web browser. Most peo­ple expect the browser to be divided into seven areas: an appli­ca­tion menu, which mir­rors the look and feel of other appli­ca­tions on their oper­at­ing sys­tem (such as file, edit, view, book­marks (Microsoft Inter­net Explorer calls those “Favorites”), Tools, and Help); a load­ing graphic (which is ani­mated when the browser fetches a page); a nav­i­ga­tion area, which includes famil­iar but­tons such as back­ward, for­ward, stop, refresh, and home; a web address box where they can type in an address to get to a web site; a book­mark (or “Links” as Inter­net Explorer calls it) bar, which lists sites that are book­marked; a main win­dow, where the con­tent of the site they are look­ing at is dis­played; and a sta­tus bar, dis­played below the main win­dow and pro­vid­ing infor­ma­tion on whether things have down­loaded or not.

As you can see from the list of what makes a browser screen, this is already a fairly large set of com­po­nents to think of, when design­ing a browser. Mozilla, my favorite browser, suc­ceeds in mir­ror­ing most of this prop­erly. How­ever, the lack of a home but­ton in the nav­i­ga­tion bar of the default install of the soft­ware may con­fuse a lot of users (There is a patch to resolve that prob­lem but begin­ners will not know this. This cre­ates some con­cern for the user, which eas­ily unset­tles them because, if this part is unfa­mil­iar, what else can they expect?

The chal­lenge here is to start think­ing like a low-end user. Mozilla is a very pow­er­ful tool but how do you make it eas­ier? As devel­op­ers, we often for­get that the peo­ple who could use our soft­ware may not know as much as we do (or worse, some devel­op­ers believe that peo­ple *should* be expe­ri­enced enough to use their code). The best way to han­dle this when work­ing on design­ing screens as part of an OSS project is to show it to peo­ple who are not pro­gram­mers (fam­ily mem­bers, or non-geek friends are use­ful here!). If it takes a reg­u­lar user more than a few min­utes to under­stand what the pro­gram does, you may have a usabil­ity problem.

Con­sis­tency

Con­sis­tency talks to a cer­tain level of expec­ta­tion. As a gen­eral rule, users expect a pro­gram to act in a con­sis­tent fash­ion. Con­sis­tency issues arise when a piece of soft­ware looks dif­fer­ent from area to area. For exam­ple, if you let the design­ers loose on your inter­face, you may end up with dif­fer­ent fonts, font sizes, but­tons switch­ing posi­tions, etc… This hap­pens a lot when skin­ning applications.

In order to main­tain con­sis­tency, ensure that your appli­ca­tion reacts in the same way on its sub ele­ments as it does on the top ones. For exam­ple, if you use but­tons like OK and Cancel next to each other, make sure that they always show up together so that you don’t end up with an OK or Cancel but­ton stand­ing on its own or with some­thing like Go and Cancel in one screen and OK and Cancel in another.

A con­sis­tent inter­face breeds famil­iar­ity, which in turns makes your appli­ca­tion more usable.

Gen­er­al­iz­abil­ity

The con­cept of gen­er­al­iz­abil­ity expands on con­sis­tency but goes beyond your appli­ca­tion. Gen­er­al­iz­abil­ity talks to the wider world of all appli­ca­tions like yours. As a result, it’s kind of a pack men­tal­ity thing. If you are work­ing on build­ing a bet­ter mouse­trap, you have to make sure that peo­ple real­ize that it is a mouse­trap. As a result, you have to use some of the ele­ments and attrib­utes of other mousetraps.

The best advice in terms of main­tain­ing gen­er­al­iz­abil­ity is to look at what sim­i­lar appli­ca­tions do. For exam­ple, going back to the browser, the edit pref­er­ence screen is gen­er­ally orga­nized in sub­sec­tions. In the case of Netscape and Mozilla, they show up in a cat­e­gory list on the left of the pref­er­ence screen. In the case of Inter­net 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 pref­er­ence screen. As you can see from here, there is some level of con­sis­tency in terms of orga­niz­ing that content.

Another exam­ple of gen­er­al­iz­abil­ity is the tabs imple­men­ta­tion in Apple Safari. Mozilla and Opera had taken an early lead in estab­lish­ing tabs as part of their browser offer­ing. Open­ing mul­ti­ple tabs showed a tab nav­i­ga­tion bar and open­ing a new tab on the mac imple­men­ta­tion of those browsers was done by using Apple-T. When Apple imple­mented their solu­tion, they bowed to the con­sis­tency rule by imple­ment­ing tabs in the same way as its predecessors.

Pre­dictabil­ity

Pre­dictabil­ity is, as expected, build­ing a sys­tem that works in the way you expect. This is much tougher than one would think as level of expec­ta­tion are dif­fer­ent based on user levels.

For exam­ple, advanced browser options in Inter­net Explorer are under in an item called “Inter­net Options” under the “Tools” menu. The assump­tion here is that any­thing that is user con­fig­ured is optional and that, in order to con­fig­ure it, one would use a tool. On Mozilla, the browser options are in an item called “pref­er­ences” under the “Edit” menu. The assump­tion here is that the user would want to edit their pref­er­ences. Two dif­fer­ent paths to the same area, which can lead to confusion.

Because Inter­net Explorer has the lead­ing mar­ket share, we must fall back on the gen­er­al­iz­abil­ity prin­ci­ple 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: some­times bad inter­faces are what the user expects. Try­ing to change that is often dif­fi­cult and goes against the con­cept of learnability.

Sim­plic­ity

The last item in learn­abil­ity is sim­plic­ity. The sim­pler the inter­face, the eas­ier it is to use. Here’s an exam­ple: If I cre­ate a but­ton called XML in an appli­ca­tion, fel­low geeks will expect that once they click on that but­ton, they will see the XML ver­sion of the doc­u­ment I’m pre­sent­ing. How­ever, some­one who does not know what XML is will look at that but­ton and be con­fused. As a result, that but­ton should not fig­ure promi­nently as part of my default interface.

A good way to enforce sim­plic­ity is to pro­vide a reg­u­lar user and an expert user set­ting. For exam­ple, Apple Safari is a very basic browser when you look at the out of the box ver­sion. How­ever, sev­eral tools can reveal new menus that will be used by experts. If I were involved in devel­op­ment on the Mozilla inter­face, I would rec­om­mend that it ship with a default dumbed-down set of menus. In the pref­er­ence set­ting, one could turn on the super-user mode, which would then pro­vide all the remain­ing menu items. This would allow to cre­ate a simple-looking browser, while retain­ing all the great fea­tures under it for more advanced users.