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 …

You can see and download the slides at Slideshare (German). As I promised to write a detailed post about ARIA enhanced tab navigation for the Webkrauts web standards advent calendar (think of a German version of 24 ways) you will be able to enjoy an English tutorial soon. Never mind the references to Chris in the slides — I had to choose an example from my flickr pictures, and I believe there are too many presentations already with kittens.

The conference was surprisingly innovative: I half expected a crowd of suits as the event was co-organized by the Austrian Ministry of Health, Family and Youth, instead there were many young faces and a fair percentage of women. Things I have learned (and tweeted about) include:

• As of January 2009, websites sponsored by the Austrian Ministry of Health will only receive funding when they are accessible. That doesn’t come as a surprise as a European Ministerial Declaration in 2006 announced that accessibility and best practices could become mandatory in public procurement in 2010.
• Artur Ortega showed examples of Dirk Ginader’s accessibility features for Yahoo! Finance, including two input fields where the labels were dynamically updated after a currency was chosen. So a screenreader read “convert pound sterling to euros” instead of “convert currency to currency.”
• One reason for JavaScript enhanced HTML controls for Flash objects like Yahoo! video is that the Flash object cannot get tab focus when the wmode param is set to opaque or transparent. Still without that param it is impossible to tab into a Flash object in Firefox 3. Or did I overlook something?
• Designer Maria Putzhuber quoted an interesting delusion: 70% of designers believe that visitors are almost always able to maintain orientation while in fact just 10% of the visitors are able to achieve this. What do you think is the reason?

Deutsche Fassung

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.

I started my conference program with a case study by the BBC. They did a redesign and managed to squeeze formerly 60 images into 3 sliding doors and sprites. Their home page is now under 300K and 30 HTTP requests. Nice to see Yahoo’s Exceptional Performance guidelines go mainstream. About 5% of their users access the site without JavaScript. They don’t get identical features, but they get identical care. For them accessibility isn’t a buzzword, it’s become a natural part of their daily work. So they were able to find out that blur() is not a friend with JAWS. Also the BBC plays well with the other kids: they joined the OpenID foundation, and with BBC backstage they open their content through an API. Another charming idea is their public beta where people can testdrive new features. About 60% have personalized their home page, although one of the speakers described the personalization features with “my mom’s head exploded.” They used agile development with 2 week sprints, run the website in 12 languages, but don’t have a CDN yet because of the license fees.

Another case study about the LOHAS community Edenbee wasn’t that exiting, mostly because I knew the platform since beta and didn’t get quite why I should speak with other people about changing their lightbulbs. But it’s nice to keep track of your carbon footprint, a feature that uses the AMEE open API.

I was curious about HTML 5, so I went to the presentation of Lachlan Hunt and James Graham. Still I don’t see any advantage of having a bunch of new elements that are incompatible with older browsers when I can achieve the same with ARIA attributes. But I understand the rationale behind some of their decisions, although that doesn’t mean I come to the same conclusions.

For example people use a lot of “nav” and “menu” classes. To make their live easier, the WHATWG came up with the idea to create a nav element. A block level element, so you wouldn’t have to use those <div class="nav"> any more. But every time I use something like class="navigation" it will be an unordered list! I don’t need another div, I’m perfectly happy with my ul and role="navigation". It’s truly backward compatible, it’s semantic, I can use it today, and there isn’t a steep learning curve.

Then I went to two design talks by Andy Clarke and Dan Rubin, and though their designs were beautiful, the code examples were not. Imagine the flexibility of a newspaper article and compare that with the inflexibility of absolutely positioned paragraphs with fixed heights. Exactly. Apart from that Andy’s main inspiration came from comic books. It never hurts to throw in some colorful images.

Like in comic books, usability is not about getting from A to B, it’s about the experience of getting from A to B. In comic books the size of a panel and the amount of text strongly influences the reading speed. So you can emphasize content and add dynamics in your web design. That doesn’t mean necessarily that everything has to be in boxes. Emphasis can also be added by removing the boxes.

Dan Rubin used a lot of effects on his designs, like a noise filter to add texture on monochrome surfaces. Nice idea, though that implies the designer explaining the rationale of such a feature to the front-end engineers. They would either ignore it because they overlooked the subtle texture or because they assumed it would be just noise. Some less intrusive hint I will readily adopt was using a letter-spacing of −1 on headlines to prevent tiny rivers between letters.

What slightly worries me is that Dan talked about re-using patterns for some effects in Photoshop. Re-using patterns is the same in CSS, but re-usable effects in Photoshop can mean an unusable amount of work in CSS and lots of pictures making the website slow. What I miss so far is a common understanding of effects and patterns that are both easy to work with in Photoshop and in frontend programming.

The next day started with Nate Koechley’s keynote about professional frontend engineering. He chose the topic because he thinks this is critical to the advancement of the Internet, and I couldn’t agree more. As Frontend Engineers we write software with XHTML, CSS, JavaScript, and quite some amount of PHP. Douglas Crockford calls this “the most hostile software development environment imaginable,” and if you take a look at this graphic from Nate’s slides you will understand why. There are a number of knowledge areas that can be applied in a number of ways on three operating systems and half a dozen browsers in two rendering modes. If you ever wondered why you sometimes see little clouds of smoke coming out of your frontend engineering heads, that’s why.

There are four guiding principles:

1. Availability and accessibility for all users worldwide
2. Openness: share, learn, support, advocate
3. Richness: provide, but not too much
4. Stability

Then there are three core techniques: Graded Browser Support, Progressive Enhancement, and Unobtrusive JavaScript.If you haven’t heard about those concepts, please read about them now.

At that point the presentation turned into giving advice for quite a number of best practices and tips, like using JSLint, YUI Unit Testing, or YUI Profiler to enhance the quality of your code. Or serving cacheable assets from cookie-free domains. Or anticipated preloads: sneak in your new JavaScript and CSS files a week before the relaunch. Or did you know that the iPhone 2G can keep only 19 assets in cache, and that it doesn’t cache anything larger than 25K? Uncompressed 25K? Needless to say, Nate’s presentation was one of the conference highlights.

Later I heard a few things about building applications with existing frameworks and APIs, a timely comparison between JavaScript libraries held by no other than jQuery’s John Resig, some tips on internationalization by Richard Ishida, and a panel about accessibility. The one sentence that stuck most in that panel was: “Don’t be the guy with the problems, be the guy with the solutions.” In fact it’s very hard to be passionate about your job while being pragmatic and providing solutions instead of just saying “no.” Something Richard Schwerdtfeger wrote about in a different context:

Working in the accessibility field is extremely difficult. It requires very specialized skills — including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up.

Combining passion and diplomacy is a goal many web evangelists still have to work on… In the meantime remember that accessibility is most likely to have a sustainable impact when it is supported by senior management, when there is an accessibility policy for a company, and when smart companies realize that there is money to be made by maximizing the target audience.

In contrast, color contrast analyzers use algorithms from the Web Content Accessibility Guidelines (WCAG) to obtain verifiable, objective results for luminosity, brightness and contrast. Those results give us an impression how fore- and background colors are perceivable by other people.

An example

Visiting the iTunes store we can say subjectively that the light gray text on a dark gray background is somehow hard to read. It’s straining, and possibly that’s not only due to the small font size:

If we check it with a color contrast analyzer, we get results like these:

The luminosity contrast ratio is sufficient with 5.37, the difference in brightness only just fails with 116 (125 being the lower limit), and the difference in color is insufficient with a result of 348 (the lower limit is 500).

So it’s not us getting old — the color values are indeed poorly chosen!

Downloads and links

There are various tools to test color contrast:

• Firefox Add-Ons: Colour Contrast Analyser and Juicy Studio Accessibility Toolbar
• Internet Explorer: Web Accessibility Toolbar 2.0 (WAT)
• Opera: Web Accessibility Toolbar 1.1
• Colour Contrast Analyser 2.2 as standalone software for Windows or Mac OS

As web application:

• Juicystudio Colour Contrast Analyser
• More resources listed by the W3C

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

Most rollovers have become obsolete because they can be performed on background images with CSS sprites. If there are hover effects today, they usually come as text on a button background image, or as a text link with an icon next to it.

However, there are those rare cases when there is just an icon without text, like a “play” or “pause” button, or a magnification glass on an image to signal it can be enlarged. If you want to swap images when the element receives focus or on mouseover, traditionally you are stuck with two options:

1. JavaScript to change the image source, or
2. CSS sprites to change the position of a background image behind a transparent gif image.

I like neither. Using JavaScript and two images with pre-loading seems like a waste of resources when it can be done with CSS and one image only. Transparent gifs are so 1998, besides the background usually doesn’t get printed. So what we need on these occasions are CSS sprites for foreground images.

Until recently I thought that can’t be done, but then I stumbled upon some code for checkbox widgets in Dojo. Naturally they use a lot of JavaScript for the task. Anyway I like my default checkboxes and don’t have any urge to make them prettier (I have no doubt our design overlords would enforce aqua icons everywhere), but that made me think. Here’s a suggestion:

First a simple sprite which is 50px wide:

The HTML code uses the dimensions of a single icon for width and height to allow fast page rendering without reflow:

1. <a href="/big/" class="icon">
2. <img src="/img/icon-enlarge.gif" id="magnifier" width="19" height="15" alt="enlarge image" />
3. </a>

The corresponding CSS sets the link to display: block, uses the single icon dimensions for the container, prevents overflow, and resets the image dimensions to auto to prevent distortion. The actual image swapping is achieved by a negative left margin on hover.

1. a.icon {
2. display: block;
3. width: 19px;
4. height: 15px;
5. overflow: hidden;
6. }
7. a.icon img {
8. width: auto;
9. height: auto;
10. border: none;
11. }
12. a.icon:hover img, a.icon:focus img, a.icon img.hover {
13. margin-left: −31px;
14. }

For the sake of simplicity I ignored how the link would be floated or positioned. Also borders, a background color, or padding to increase the clickable area can be added to the parent element.

For simplicity I chose a link in the example, but the same can be done with a div surrounding an <input type="image" />. Then of course you need to define cursor: pointer, and for anything below IE7 bind the DOM event to the hovering element (get the source):

1. <!--[if lt IE 7]>
2. <script type="text/javascript">
3. oIcon = {
4. setHoverClass : function() {
5. this.className = 'hover';
6. },
7. resetHoverClass : function() {
8. this.className = '';
9. }
10. };
11. var elm = document.getElementById('magnifier');
12. if (elm) {
13. elm.onmouseover = elm.onfocus = oIcon.setHoverClass;
14. elm.onmouseout = elm.onblur = oIcon.resetHoverClass;
15. }
16. </script>
17. <![endif]-->

Here is a working example. You know how to adjust the code if you need more than one class on the image.

That was nice and easy. It’s tested in Firefox 2, Opera 9, Internet Explorer 5+, and Safari 2. Screen readers should be okay with the alt text.

Discussion

The trouble begins when people start turning off browser features.

People with disabled images won’t be able to read the alternative text because the visible area is limited by the parent container. That can be detected by comparing the known sprite size with the alt text size. Then the class is set to anything but icon so that the parent container expands.

More severe is when people disable style sheets because then they will see a squeezed image with multiple icons. If you are hyper-correct, you could replace the crushed multi-icon image with the correct single icon (you could use the class or rel attribute to define the icon type), but nobody wants to slice images. As a compromise I would suggest to replace the icon with its alt text.

See the script to detect disabled images or CSS. (Note: it isn’t implemented here because I couldn’t test it properly on IE6 with stuff turned off.)

If JavaScript is unavailable, the user is stranded with what we gave him. Also icons without text are inherently evil because they can’t be enlarged by zoom readers. Did I forget any politically correct disclaimer for obscure use scenarios?

So we ended up with a CSS only version, but still some JavaScript is needed for the extra effort to provide the same experience to users of IE 5-6, and some more for certain user scenarios. Wouldn’t it be easier to slice and swap foreground images the old way? But then again slicing is a pain, and people already start using background images. Do people actually turn off CSS and images? Or is that another remnant of WCAG 1.0 from 1999?

In this post

• Jesse James Garrett
• Molly Holzschlag
• Mark Boulton
• Jon Hicks
• Hannah Donovan
• Shawn Lawton Henry
• Richard Ishida
• Andy Clarke

First off was Jesse James Garrett, the creator of the term AJAX, who held a keynote presentation with all the usual quotes, big stock photos, historical references to technical pioneers (this time the inventor of the Kodak film roll) and such (podcast). I’m afraid I can’t bear victorian black and white photos of technical pioneers in the context of web development any longer. OK, so this guy changed the way photos were made in 1885. Also web applications are a little more convenient now than server roundtrips. But where’s the common element? One made photography easier for the mainstream, the other is a much hyped technique with the potential to make things easier, but quite often people just blow it.

Don’t believe the hype. Most web applications still don’t innovate, they just copy desktop behavior. And who is really comfortable with the restrictions of desktop software anyway? If it’s only a matter of response rates, learn from Yahoo! how to minimize the amount of data being sent on server requests. If I can update a whole page in 1-2 seconds using smart caching and other techniques, there’s no need for an AJAX request except for immediate form feedback helping users to avoid errors. Film rolls have faded from the face of Earth, it really would be more interesting what’s next, after AJAX. Jesse talked about user-centered design, cited Tim O’Reilly with the paradigm to “design from the outside in.” But that only means: after having taken one usability step back, eventually we will move forward. Where to? Jesse failed to deliver that.

A key factor to understand why browsers are such a pain is to remind yourself that they are just a piece of software, said Molly Holzschlag, now working for Microsoft (podcast). In fact very complex software. She compared the pros and cons of different browsers and what we can learn from them: short iteration circles and automated updates from Firefox, a strong brand and user identification from Opera. Otherwise she recommended that if you really need a feature in IE, make yourself heard. Put pressure on Microsoft to get priority. Just telling them you “want” something like multiple background images or WAI ARIA support won’t be enough. Your voice and your friends’ might weight more than that of the W3C, because you are their customers, their userbase.

Mark Boulton’s presentation about typography gained more momentum after a while (podcast). He explained why Verdana is lighter than Arial, and that you should blur your design to identify the optical gray gradient of a page. Then he continued to talk on grids and how to design to a vertical rhythm, a topic well known from print but rather unrecognized in web design until last year. Quite fashionable are headlines in a serif font for a better structure, and paying attention to small details like using the correct quotation marks or dashes can make a difference.

Jon Hicks showed us how to be a creative leech sponge (podcast). Get your inspiration everywhere — with two exceptions. Do sketches, keep those you draw during phone calls, take photos of typefaces, keep photos gone bad just for the color effects, collect labels from clothes, get leaflets (the “all you can eat buffet for designers”; get even the bad as you might need to mimic bad design some day). Get inspiration from book covers, graphic novels, books for children, magazines, patterns, prints, or packaging design. Blogs and flickr groups also help you to get inspiration, delivered right to your desktop through their RSS feed. The two exceptions? Other websites and logos, because there’s a high risk you will come up with a copy instead of an original idea. They are too close to the desired product so there’s no room for creative transformation.

Once you have collected inspirational material, it needs to be cataloged. That can be done in a sketchbook, but iPhoto, Yojimbo, or flickr will do the job.

Catalysts against a creative block (the dreaded blank page) can be deadlines, changing your environment and going for a walk or drive, going to bed, some peace and quietness (in the bathroom, where you keep the magazines for inspiration), taking a shower, or traditional techniques like brainstorming, mindmapping, criticizing and learning from bad examples, or moodboards. If your clients are adventurous enough, they can even do their own.

Some people are angry about Last FM’s sell-out to CBS, but Hannah Donovan didn’t make the impression that a petty-minded corporate spirit has taken over (yet). She talked about lessons you learn in a startup, like getting started, getting out the product very quickly (before others do it), taking small iteration steps with the rapid development technique Scrum, and using broad brushstrokes as a designer. Perfectionism is no priority for startups. Also she recommended that designers and developers work on a team (really) and hold 5 minute stand-up meetings every morning, “that makes a world of difference.” That actually means sharing a room, you know.

Shawn Lawton Henry works for the W3C WAI and the MIT, naturally she talked about accessibility (podcast). That’s something most people take as “what you can get away with,” but it’s really about people. So it’s important to understand how people with disabilities use the web. Technical standards like the Web Content Accessibility Guidelines 2.0 (WCAG) only supply a shared definition of requirements. Because they are not going to change for a while you better take the time to review the current version. However, the WCAG Techniques document will be adaptable and more flexible. There will be subversions, and although there’s no issue tracker at the moment, you will be able to submit additional techniques to meet the WCAG requirements as they are intended to grow with time.

I didn’t take notes on Richard Ishida’s presentation about I18N because I was familiar with the slides already, but I was deeply impressed by this man (podcast). Richard lives and breathes internationalization. He speaks about a dozen languages and doesn’t let a chance pass to practice them. He is the perfect personification as head of W3C I18N activity. I only wish he had said a few things about the I18N tag set because it’s a mighty tool for translations and fairly new.

On a related subject Andy Clarke asked designers worldwide if they thought their country or region got a distinctive design style, and he compared international websites of global players (podcast). While most of them just work, they could do better by adapting to the local customs and style. Culturalization is the key, anything else is modern imperialism. Check his presentation (PDF, 18 MB).

Somehow it was different than last year. Of course I came home full of inspiration, but this time it was more like deepening knowledge, while last year for example the concepts of microformats or browser performance were totally new for me. I met more people than in 2006, and I feel some of them can become my friends. That’s a new experience at a conference. I even found some parallels with Joe Clark. No, I’m not a “sarcastic gay vegan,” but we both don’t drink, prefer tea, and can be quite pedantic… I even linked to his website without rel=nofollow now, what an improvement! Anyway, I’m looking forward to meet some of my new friends in Brighton at d.construct.

• Andy Clarke: Royale With Cheese (PDF, 18 MB); Podcast
• Dan Cederholm: Interface Design Juggling (PDF, 22 MB); Podcast
• Dan Webb: The Mysteries Of JavaScript-Fu; Podcast
• Drew McLellan and Simon Collison: High-Noon Shoot-Out: Design vs. Implementation
• Håkon Wium Lie: One Web, Acid2 and CSS3 (PDF, 3.7 MB); Podcast
• Hannah Donovan and Simon Willison: For Example… Last FM (PDF, 1.8 MB) and Doing Local Right
• Hot Topics Panel: Podcast
• Jason Santa Maria: Diabolical Design: The Devil is in the Details (PDF, 22 MB); Podcast
• Jeremy Keith: Bulletproof Ajax (PDF, 2.1 MB); Podcast
• Jesse James Garrett: Beyond Ajax; Podcast
• Joe Clark: When Web Accessibility Is Not Your Problem; Podcast
• Jon Hicks: How to be a Creative Sponge; Podcast
• Mark Boulton: Five Simple Steps to Better Typography; Podcast
• Molly Holzschlag: The Broken World: Solving the Browser Problem Once and For All; Podcast
• Nate Koechley: High Performance Web Pages; Podcast
• Richard Ishida: Designing for International Users: Practical Tips; Podcast
• Shawn Lawton Henry: Advancing Web Accessibility; Podcast
• Tantek Çelik: Microformats, Building Blocks, and You; Podcast

Update

Thanks for the reminder, of course Joe Clark wrote detailed protocols about some sessions. Also I would like to point you to Chantal Slagmolen’s original notes — I wish all designers were so creative!

• 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.