I was responsible for most of the programming beneath the navigation bar on the home page, and every time when I book a ticket there’s a small feature I enjoy so much I want to tell you about it: the buttons on the date selector are really, really tiny (16 × 8px). As you know thanks to Fitt‘s Law, there are even formulas to calculate how much better big buttons can be hit.

So I just added some padding. And that makes a huge difference: try to click on the same buttons later on in the booking process where the padding is missing.

If I could make one improvement I would add keyboard functionality to those buttons. Alas as the datepicker itself came from a third party, the assembled code was beyond my control. But I know that the Deutsche Bahn is listening to the needs of people with disabilities and their disability advisory board members are highly competent, so I trust these and other issues will be fixed soon …

Now there’s light at the end of the tunnel: a few days ago Apple filed a patent for multi-touch in combination with features such as voice commands and speech recognition, facial recognition, gestures, fingerprint input, body temperature, heart rate, skin impedance, and pupil size.

With that range of input possibilities, accessibility on the iPhone (and on other devices) could be significantly improved. Also other visionary devices come into range, like the Charmr for diabetes management.

The Charmr was a great design study by Adaptive Path, although a touch screen is a problem for people with diabetes who are more likely to develop vision impairments and lose tactile sensitivity. Speech recognition is an obvious solution.

1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?

Note: when your flickr account is fresh, your photos will not be search indexed unless flickr staff has approved them as “safe.” Also you need to approve your photos for public search: “hide your photos from searches on 3rd party sites that use the API?” must be unchecked.

Your photos

• Minimize the number of text fields in your interfaces down to the absolute minimum necessary.
• Minimize the number of clicks / keystrokes / gestures necessary to accomplish actions in your interface.
• Make your interface as responsive as possible — minimize the latency of each and every action a user might take in your interface.

In short: keep it simple. Don’t make me think. Don’t make me wait.

Brilliant! Then a couple of days later I found the time to finally read Jef Raskin’s book The Humane Interface (2000) where he demonstrates four methods of quantifying the efficiency of a software interface: Fitt’s Law (1954), Hick’s Law (1952), Raskin’s own measures of efficiency, and the GOMS method, in particular the Keystroke-Level Model (1980).

I hadn’t heard of at least half of them before, and so did my colleagues. Apparently those methods are well established in software UI design, but less known among web developers. Which is a good reason to blog about them.

Fitt’s Law

You most probably have heard of that law. Given the size S of a target (like a button) and the distance D to move a cursor, you get the average time it takes to hit the button:

time (in msec) = a + b log2 (D / S + 1)

a and b are empirical constants, like the reaction time or time to click a button. You can use an approximation of a = 50 and b = 150. Also the smaller horizontal or vertical value for the size is good enough, and an average distance on a screen. The binary logarithm log₂ is the equivalent of the binary chance to hit or miss the button. That said, a large button is easier to hit.

For some practical examples see Kevin Hale’s excellent article, or Microsoft’s application of Fitt’s Law in Office 2007.

Hick’s Law

Hick’s Law is about the time it takes to make a choice from a number of elements. Be careful when applying this law to menus, because there are other factors like the size, design, sort order, or readability of menu items.

time (in msec) = a + b log2 (n + 1)

For example, ignoring the constants, we can boldly claim that choosing from a menu of eight items takes longer than from one of four items because log2 8 = 3 and log2 4 = 2. In theory, opening a submenu of four items in another menu of four items takes longer than the choice between eight, because 2(log2 4) = 4 and log2 8 = 3. Because human performance sinks on cognitive tasks involving more than 7 ± 2 items, choosing one of eight items could actually take longer.

Interface efficiency

The information-theoretic efficiency of an application is the minimum amount of necessary information divided by the actual amount of information. Sounds difficult, but is easy. Making a choice means one bit of information. “Push OK or Cancel.” One bit of information, requiring one click or keystroke. One keystroke is approximately 5 bits, so the efficiency is 1 / 5 = 0.2, or 20%. Thus you know there is room for improvement.

In the following example you got no choice at all, so the information efficiency is zero:

Of course it is necessary to inform a user that the search is over or that certain fields in a web form are required, but that can be done in an unobtrusive way without alert boxes. A yellow-fade does not require pushing a button and has 100% efficiency. If the user can only do one thing next, have the computer do it. Besides hitting “OK” soon becomes habitual and therefore pointless.

Goals, objects, methods, and selection rules (GOMS)

These rules were further described by Stuart Card, Thomas P. Moran & artificial intelligence pioneer Allen Newell in their influential book The Psychology of Human-Computer Interaction (1983). GOMS, and in particular the simplified Keystroke-Level Model (KLM), offers a simple approach to estimate the duration of tasks on a computer.

• K = 0.28 sec. — key press and release (keyboard)
• P = 1.1 sec. — pointing the mouse to something
• B = 0.1 sec. — button press or release (mouse)
• H = 0.4 sec. — homing, hands movement from mouse to keyboard or reverse
• M = 1.2 sec. — mentally preparing
• W(t) = t msec. — wait or response time (system)

Inserting mentals is probably the most difficult part of this, but there are six simple rules how to apply them. So in another infamous MS Word example when the user wants to change a radio button we get the sequence HMPBPB with a total of 4.0 sec., or HMPBHK with a total of 3.48 sec. when the user hits Return instead of clicking on “OK.”

3.48 seconds is pretty fast, but since there is only one bit of information but two keystrokes we know it could be faster:

The sequence required for this selection is HMPB or HMKK with a duration of 2.8 sec. or 2.16 sec., respectively.

Simpler interfaces increase usability and are faster. Because they are simpler, I don’t have to think so hard. Wait, that sounds familiar … it sounds like … cognitive load!

Let’s take Tantek’s examples where he describes the steps for instant messaging and writing an email. That would be something like:

• HMPMBBM(K × n)MK
• HMPMKKKKMKKM(K × n)MKM(K × n)MPB

Even without knowing and thus ignoring the amount of characters in the message and subject (K × n), the estimated time for writing an IM (5.58 sec.) is significantly smaller than writing an email (13.06 sec.).

I’m really sorry, it was a brilliant idea, but I’m afraid KLM-GOMS describes pretty well what Tantek calls Three Hypotheses of Human Interface Design. Unfortunately somebody came up independently with that established method for Human Computer Interaction, 27 years ago.