Usability Institue Logo- A bolt that can be fastened with any of 4 tools
PicoSearch
Reducing Training to Its Sensible Minimum: Zero...
Inexpensive, Independent Usability Consulting by Jack Bellis
Home Page- List of All Content Home Page- All content, in date order Resources: page describing tools you can use Morsels: just our short articles and blurbs Just our Before&After Articles Just our Site Reviews & Criteria About: details on who I am and what I do Address, phone, number,  and so on
 
 

Morsels... A Running Log of Usability Anecdotes and Antidotes

2009-May-26: Hall of Fame-Worthy Videos

  1. "Human Interface" http://vimeo.com/4697849 ... 6-minute video of a person in a glass-top-box, acting out interactions from an unseen fingertip.
  2. First TechSupport Call http://www.youtube.com/watch?v=F1x9MKsZ4-g 2-minute video of monk providing techsupport to user stymied by this devilishly difficult new 'book' thingy.

2009-May-7: Everyday Usability

Look at this nice 'task-oriented' sign in the Philly subway system:

2008-Oct-11: Potpourri... or However You Spell It

I've saved up a lot of recent examples, so here goes.

A) Read the Help File... Nohhhhht!

A recent thread at work brought up the usual plaint, "Didn't you read the body of the email... it explained what you were supposed to do." It inspired me to add this photo, a "help file" for firefighters.

It's related to two issues: 1) Help files, despite the fact that I loved writing them for about 15 years, are no longer the solution to any but the most expert systems. Can you imagine the firemen reading the instructions in a smoke filled elevator. Which gets to the second point, which I'll make a separate item...

B) Context Is King!

If the buttons don't do what you think they should do, no amount of help file, or even embedded help, is likely to solve the problem. I realized this when using a system that I myself write the help file for. It had a complex function that just wasn't as automated as needed. I had written embedded help right into the closest spot possible, about 8 months prior; but when time came for me to use that tricky function, I didn't recall the secret revealed by the embedded help that was right in front of my eyes... I expected the buttons to do the most logical thing and they didn't. If the context tells the user---based on 16 years of the WinMac model doing things a certain way---that a certain thing is simply natural, then explanations just don't matter. End of story. I see there's 24,300 googles for the exact phrase "context is king," so that's good news.

C) Nicknames

It's 2008 and systems are still using nicknames instead of descriptive function names... something I've been diligently ranting about since '97, such as in this online shovelware of my book, Computers Stink. Here's a great example from a new tool I'm using. It happens to be a great tool, VIA3 video room, but I couldn't figure out how to share an image... because it's called "Live View." It should be "Share Application" or something like that. Sheesh.

D) Long Live Menus... Again

I'm in a combined state of misery, shock, and occasional enlightenment now that I'm using Office 2007 with the Vista ribbon at my new job. It's such a mishmash of influences. Good: it adds the benefits of "docked controls," good. Bad: it destroys 10 years of expertise among millions of users; I was a Word guru having published 3 books with it; now I'm an absolute incompetent idiot. Bad: it puts the more general labels of each docked section BELOW instead of above its panel; I'm convince it does this because the managers were embarrased to make the appearance of tabs below menus, which would admit that the functionality is still rich/complex/sophisticated. (That's a longer story.) Bad: the docking is not entirely context-automated... the real failure of the design. I don't have enough space to complete all the "Bad" entries because the Internet might get full. So I'll stop and get to the last "Good." The new design has some of the fanciest dropdown menus know to man. Consider this table dropdown:

Gone are the days when dropdown menus had just text (with icon and hotkey legend). This one has a dynamic grid-size selector, and a whole preview set of selectable table formats. Wow. It validates my long-held insistence that menus are NOT GOING AWAY folks. They are as solid as the printed page, newspapers, magazines, and so on... all of which are simply finding new levels, not disappearing.

E) When is $0 Not Free?

Just passing along an interesting morsel from a Nielsen report on ecommerce: users who see "$0.00" in a text box are worried when they are expecting an item to be free... probably because they worry it is a changeable value. Good point. Make it say "Free." Whether it's in a text box or on the face of the page is another issue, but probably doesn't matter in this particular case so users would feel better not seeing it in a box.

2008-Sep-27: Everyday Usability

Some day I'll post these on the Everyday Usability Flikr page. First an interesting sign at a traffic light near my home. Imagine you're driving up to this intersection and intend to make a left turn. You see a green light so you can go, right?

Wrong! You have to read the qualifier sign... "Left Turn on Left Arrow Only"! It's not often you have a green light with text conditions on it, is it. Can you imagine if more intersections had detailed instructions for the various colors?

Then there's this legend I found outside an elevator at Philadelphia International Airport, with the higher floors listed below(!) the lower floors. At least it was just a legend/key, not the actual buttons:

2008-Jul-19: Taxonomy of New "Object" Types... "Collaboration Types?"

In the olden days there were just document types... text, spreadsheet, database, graphic, calendar. Sure, a few more like CAD appeared here and there, but the basic types defined the value and limits of software value. Now with web 2.0 (whether you like the term or not), there's a new set of types that have radically changed the value proposition to such an extent that the world is a different place. I'll actually have to move the puzzle pieces around a bit to figure out what the picture looks like.

Let's start with pure chronological...

  1. Newsgroups
  2. Distribution lists
  3. Forum
  4. Blog
  5. Chat
  6. Tag
  7. Wiki
  8. Friend (probably not a type, just an option)
  9. Notify (RSS, feeds, formerly distribution lists?)
  10. Community (formerly newsgroups?)
  11. Rating
  12. Voting
  13. Mashup (probably not a type either... just a publishing paradigm)

There seems like a common logic underlying this list. I'll keep working on it.

2008-Apr-3: Rules for Organizing Shared Folders

I've often recommended the following rules on office networks, so I thought I'd finally publish them.

  1. The root folder of any shared network drive should have approximately 20 or fewer items in it. The goal is to view the root in Windows Explorer without scrolling.
  2. The only items in the root should be folders.
  3. Folders that have names with repeating phrases or have only minor differences should usually become a group of subfolders.
  4. Personal items and items that are unlikely to be formal or persistent business items should generally not be top-level folders. For instance make folders for Personal>JoanSmith and Experiments.

2008-Mar-10: How Far We've Come

I fell in love recently... with a simple graphical effect, the formatting of a code snippet in one of SitePoint.com's articles. Oh, come on that happens to you all the time, right?! Ok, maybe not. (Be forewarned SitePoint—a book publisher—seems impossible to unsubscribe from.) I started looking "under the hood" to learn the technique and was a little surprised. To accomplish this seemingly simple effect, but—and here's the key—to do so in an architectural way that automates the formatting requires no less than a few hundred lines of Javascript and three style sheets. I guess the "takeaway" of this lesson could be one extreme or the other depending on your perspective. How far we've come, that I can now have a system automatically format and functionalize text to this extent, merely by importing someone else's canned/patterned code. Conversely, picture a student at any level becoming a writer, and how hard it is to find and implement this technique. Granted, I'm not a coder, but it took me a good bit of time just to figure out how this thing was working. Anyway, I added it to my Function Tree.

2008-Mar-2: Dropdown Panel Menus

In the never-ending challenge to present users with functional options, the two-row tab menu has now blossomed into what you might call a hybrid tab/dropdown panel. Witness TheScripts.com's design, below. Of course this is by no means entirely new—just look at Amazon's fly-out navigation panels. But the example below shows it in a tab scheme, which might start to be a new standard for robust systems. Picture 10 tabs, with perhaps 20 items each... the "fork in the road" metaphor now gives us intersections with 200 roads meeting at once.

2008-Feb-20: Polaroid Is Dead. Long Live Polaroid

Just after reading the news that Polaroid will stop producing its instant film—I thought they stopped years ago—I noticed the following dialog in MS Outlook. Behold the little image in the white frame. Although the instant film is on its deathbed, its iconic white, offset frame with the space for a label at the bottom will apparently live on for all eternity as the visual cue that says, "Look at me. I am a photograph!"

2007-Nov-29: Tree of Cognition?

Updated February, 2008.

The little exercise below, attempting to figure out the broader-narrower relationships between the highest levels of thought, was originally presented without context or explanation. Now, I'll add some: it's part of a fun project that I've wanted to do for years, but the tools didn't exist... a hierarchical dictionary (and more importantly, dictionary builder). I've got the project 80% complete. Check out Lexonomy.

  • Imagination
    • Synthesis
      • Conception
        • Abstraction
        ?
      ?
    ?

2007-Nov-14: Speech at Temple University's World Usability Day

I was honored to present the keynote address at Temple University's World Usability Day last week, and put together a very graphical 38-slide PPT presentation (2MB) to accompany my speech. I hadn't gotten around to writing anything about that whole experience, but got a good reminder about usability just a few minutes ago, using YouTube, which in turn prompted me to post this morsel with the link to the presentation. Here's what happened: I wrote a lengthy comment on an unrelated video and clicked the Post Comment button...

...only to be told after the fact, that my message was too long. Well, the name of my presentation was "Limiting Factors in Usability... To Users It's Still the Basics That Count!" The YouTube "Comment" feature could apply that logic very simply, by putting the limitations right on the page. Or else find some Javascript somewhere (like my old favorite DynamicDrive.com) to prevent the problem.

If you take a look at the presentation, a lot of my comments are in the notes. I'll try to update them over time. If you want to use it for your own purposes, just ask and I'll try to complete the notes sooner.

2007-Oct-21: The Revolution Accelerates... Earth-Shaking Usability Advances by Zoho

Every few years in the software industry, you hear the tired old song, "It will be so easy we won't need programmers any more." (I haven't found the sheet music for it anywhere. If you have a copy please send it to me.) And every time I hear it I laugh, as much for its pointlessness as its elusive, mirage-like qualities. Well, the pointlessness hasn't changed... with each quantum step forward the value of the geniuses doing the coding becomes greater, not smaller. (The number of folks who really have to work at that level might get smaller, but that's another matter.) But the mirage is turning into a real (virtual? I'm all confused) oasis and you can sip at the edge of the pool by going to Zoho.com and looking in particular at Zoho Creator. But I'm getting ahead of myself.

Two years ago or thereabouts, I wanted to make a job-swapping online database, OfficeSwap, to reduce gasoline use. I found an online solution that helped me make a web database application without being a full-fledged developer: Eli Robillard's GenericDB, a wonderful boilerplate of code to make a Microsoft ASP web app. I had to have significant, albeit beginner skill, with ASP and be the extensive web techie that I am. I also needed to find a freeware site that let me post an app that connected to an MS Access database... thank you, Domain DLX (I haven't linked to them because of their popunders). And I don't mind adding that tweaking an ASP app to apply a nice look-and-feel takes superhuman effort without the right instruction or support or tools. Suffice it to say that my 24 years on the fringes of serious development didn't get me past the lack of an WYSIWYG editor.

Fast forward to 2007. I knew that online web tools were advancing rapidly, having seen an Excel clone in a web page (and that its creators were snapped up by Google). And Wufoo.com's instant forms looked promising for OfficeSwap, but no interactive search/report that I could see. Recently an article in Webware showed Coghead's progress but had a few other links. I clicked on Zoho and never looked back at the other links. Ho ho ho... in 10 minutes my school-age daughter had a database in her home page without my fingers touching the keyboard. Zoho has all sorts of served, office-style tools, and I can't figure out what their cost basis is other than free, but who cares.

I've labeled this a "usability" advance, but that's a provocative point. The usability of Zoho's App Creator isn't the items in its interface, but the premise of the tool itself. (Mind you, it is full of spectacular usability... its scripting tool is in fact a huge usability model, a very strongly menu-supported command syntax, as are many other items in the interface.) I suppose my point is that the usability of the web has increased. I continue to maintain that online database apps are on a par with the technology advance of the Xerox machine and publishing in general, with the ability to facilitate mass movements of popular action... social upheaval... change... revolutions. Just wait. If you think China hates the web now...

One significance of this is that a leapfrog situation has occurred... it's time for schools to scale back the hard-core techie training (such as of HTML) just a little, in favor of tool usage. Coding is still every bit as important as it ever was, but when prioritizing introductory classes for highschoolers, spending several months on HTML is now analgous to teaching car mechanics how to manufacture a crankshaft.

2007-Jul-30: Precipitous Drop in Price of... <Guess What?>

A local Philadelphia radio show today argued about the power struggle between traditional print media (newspapers, books, etc.) and the web. All the usual platitudes and hyperboles were exchanged and everyone left the conversation with their insecurities secured and misconceptions substantiated. And life was good. But it made me realize an important follow-up morsel to my previous rant about web 2.0 and it's "ask the audience" theme.

The follow-up is this: in a great TV lecture, I remember a brilliant scientist noting that every age of technological revolution is characterized by the precipitous drop in price of a commodity. In the industrial revolution it was horsepower. In the computer revolution it was MIPS. In web 1.0 it was publishing. So what is web 2.0 in this model? Agregating information.

Web 3.0 will be characterized by the precipitous drop in price of agregating action... behavior.

2007-May-28: The "Mantle Is Passed..." Google Is Now the Defacto Defacto-er

One of Microsoft's mixed blessings has been that when they did something in most of their products' UI's, it was often a good justification for using the same technique in one's own products. Their use of a technique in their far-reaching UI's made it somewhat pre-trained and they had the inherent power to "annoint" UI methods with validity. Conversely they lead, irrespective of their leadership. Yesterday, however, I saw a small but profoundly symbolic indicator of the leadership role being taken over by Google... at least on the UI front. In Blogger, a tooltip now announces that you don't really have to click Save anymore:

Now before you go saying, "Oh, Word's done auto-recovery saves for 10 years..." this is a more significant wave moving in. Word's autorecovery is very technical but Blogger puts your posts right in the equivalent of the file list. It's long been expected by many UI folks, that requiring explicit "save" actions from computer users will sooner or later flipflop from the norm to the exception. Google's Blogger save is essentially an auto save with a one minute interval. Sooner or later, they'll tighten the interval and add automatic saves when navigating away, and the dots will be completely connected. But instead of the world looking to Big Bill for UI leadership, the norm setting is now done by Mssrs. Page & Brin.

It's over, Bill... thanks for using all the memory.

2007-May-16: Internet Ended by Oregon Realtors... ("Stop the web, I want to get off"?)

A small story buried on page 3 of the Wall Street Journal approx May 15th, tells of a dispute in Oregon where a realtor's web site provides detailed reviews of open houses that were visited by freelancers. The mulitple listing service from which the realtor obtains its home listings is furious and fining them; the realtor is suing. Never mind the legal wrangling, that's just fun stuff where everyone gives their money to lawyers to oil their beemers. Who cares.

The real story is the notion that the listing service thinks it can stop the web. Ha, ha, ha... that's a good one. Stop the web, I want to get off. Oregon company decrees, "There will be no bad things said about houses we list. These are all cozy, comfortable, charming houses. Any rumors to the contrary will be dealt with in the harshest terms. We are realtors. The internet does not extend into our cozy business." How charming. They might as well tell Al Qeada to stop posting all those beheading videos... or the Oregon MLS will come after them with lawyers ablazing.

Don't worry, the web won't be stopped. In fact, I could sooner see Amazon putting the word "Houses" right up there beside used books, than the realtors stopping the trend of detailed open house reviews. After all, Amazon is the progenitor of publicly posted reviews, eh? And if you look at the Amazon Turk, I could see such reviews being the poetic culmination---is that what apotheosis means?---of the term "cottage industry."

2007-May-5: Interaction Is a Bad Thing???

If you like to read about UI design you'll love "Magic Ink, Information Software and the Graphical Interface" by Bret Victor http://worrydream.com/MagicInk/ (March 2006). This provocative, gorgeously written, 70-page article is a treatise that makes the following case:
  1. Whereas... most software is informational (research-oriented) moreso than manipulative (such as tools that create data)...
  2. And... graphical representations of data, though they've come a long way, are still far from fulfilling their destiny...
  3. The software world's fixation on providing interactions is misapplied at best, and at worst an impediment to reaching our goals.

Well, it is 70 pages. And it could easily justify being a book. I've just completed a detailed Before & After story about it.

2007-Mar-1: One-Click Interface

A classic debate arose recently on IXDA.org's discussion group, on the question of providing functions in the fewest possible clicks. Great counter arguments were provided in your choice of words or pictures, of which I'll simply provide both. (If you claim a copyright on this image, just say so and I'll remove it.) The words were ...

"Anyone who asks to reduce clicks usually is asking for something else but doesn't know how to articulate it. Other words/phrases I tend to ignore are, 'make it easy' and 'make it intuitive.' These are not useful descriptions of solutions, but rather descrptions of the feelings that users have using it. It is important to listen to these statements, but they are not directions." —David Malouf

More usability quotes

2007-Jan-21: What the Heck is Web 2.0... and 3.0? Answer: Ask the Audience

If you're still wondering what Web 2.0 really boils down to, I can now provide the the definitive, one-phrase answer. But first, credit to the giants upon whose shoulders I'll have to stand to point you to the Emerald City:

In Tim O'Reilly's article, "What Is Web 2.0?" he enumerates the following phenomena as comprising Web 2.0:
  1. The Web As Platform
  2. Harnessing Collective Intelligence
  3. Data is the Next Intel Inside
  4. End of the Software Release Cycle
  5. Lightweight Programming Models
  6. Software Above the Level of a Single Device
  7. Rich User Experiences
The O'Reilly article even cites a similar list from Christopher Alexander, who offers this breakdown:
  1. The Long Tail
  2. Data is the Next Intel Inside
  3. Users Add Value
  4. Network Effects by Default
  5. Some Rights Reserved.
  6. The Perpetual Beta
  7. Cooperate, Don't Control
  8. Software Above the Level of a Single Device

Great lists, both, but perhaps like me, you say to yourself, "It must boil down to a more concise theme... how could something so big be a smattering?" Surely there's a "unified force!" The answer is yes, and the unified force is right out of the TV show, Who Wants to Be a Millionaire. It's "Ask the Audience." It's right there in those lists, but it's surrounded—and muddled—by some techy advances, power struggles, and feel-good fluff. Now that some time has passed it's easier to distinguish the muddle from the one genuine theme, and it is (drum roll, please)... value coming from users rather than businesses.

In the TV show, "Who Wants to Be a Millionairre?" when you ask the audience, you're almost never a loser. That's the power of O'Reilly's "collective intelligence," above. Perhaps you've felt this power if you've ever shared a crossword puzzle back and forth with someone. Together, even with just two people, you're the Albert Einstein of crossword puzzles. Add a billion people and you can solve almost problem... maybe even global warming. (That will probably not happen until we move to web 3.0, where collective intelligence changes to collective will.)

So that's my message. It boils down to those few items on the lists that imply data going up from users, not down from publishers. All that stuff about platform, releases, models, rich experiences, defaults, rights, and control is important discussion and has enabled the phenomenon, but it's not the theme, not the engine but the support systems. Whether you like your analogies of the iceberg variety (90% under water) or kite-flying (the long tail), the companies now provide the vehicle, but the engine is all of us. Our collective horsepower is like nothing that's ever come before it.

Book Cover of the Author's Repetitive Strain Jack Bellis is UsabilityInstitute.com and currently the User Experience Manager for Octagon Research Solutions, in suburban Philadelphia, PA. He is also author of the Amazon 5-star book, "It's Not Carpal Tunnel Syndrome, RSI Theory & Therapy for Computer Professionals."

Addendum, March 2007: I've recently realized that the earliest great success story of "ask the audience" is Amazon book reviews... a web 1.0 accomplishment, and possibly the biggest web success story after Google? Can anyone tell me of a bigger/earlier ask the audience web winner?

2006-Oct-20: Usability Hurts, But Learnability Kills

In preparing for a usability presentation, I was trying to prioritize usability vs. learnability. First let me define my terms. I've always postulated that usability is the sum of facility and learnability:

But in conversational use of the terms, I'll grant that usability is interchangeable with facility (speed of use, robustness, fault tolerance, etc.), implying that learnability is separate. So in the context of today's discussion usability refers to just facility. (After all, no one has bought onto my equation yet, anyway.)

So the question is, how screwed are you if you have bad usability... versus what if the learnability is bad? My answer is that learnability is the new king. All hail the king.

Bad usability, at least in the context of custom business software where I toil away the day, can be tolerated. You learn the quirks; you suffer some inefficient design; you put up with an occasional crash. Eventually you might even sing the praises of that mangy ol' mutt because you are dear, acquainted friends. You know each other and barely notice each other's faults. You avoid behaviors that make him mad. Put another way, as I've heard quoted, "You can get used to anything. You can get used to hanging if you hang long enough!"

But not so, learnability. If a product can't be learned, or learned fast enough or cheap enough, you might succeed in initially selling a product but you won't get referrals. In the new software world of free trials, the "referral" is from oneself (the free try-er) to oneself (the buyer). You either provide state-of-the-art learnability or you expire. Thus the bleeding edge of learnability is being beautifully honed by a lot of new techniques used in online apps. This is the case for a recent review I did of FreshBooks.com, but it's just one of many. See more examples of learnability in my Learnability Gallery.

Usability, of course, is hardly a "done deal." There's still a lot of unusable stuff out there. But I can see that we're moving in quickly on a state where learnability, not facility, is the limiting factor in software acceptance. So learnability might be the new usability.

Usability hurts, but learnability kills.

2006-Sep-10: See the Information Come to You

What do TiddlyWiki.com and Google Earth have in common? They both demonstrate a new trend that's part aesthetics, part usability. Both of them have animation that gives you the sense of seeing the information come to you. I realized there might be a phenomenon when I heard the same types of gushing adjectives used for both: dazzling, seductive... something like that. TW uses a fairly simple but cool looking frame that appears to expand to fill the screen. Google Earth shows the globe zero-ing in on your destination while the new data loads.

Neither is tremendously useful... but then again, maybe they are. Rather than the instant change of appearance that we're accustomed to with RAM speed of a desktop app, seeing some motion to the data might help, even if its filling wasted time. It's orienting, it's attention-placing. On my page for User In Your Face, I use an animated scroll for long in-page linking. It's all the same theme. Time will tell if it's just a flashy trend. I think it's a valuable addition to UI that will persist... seeing the information come to you.

2006-Sep-10: The Six, Seven, Eight(?) Orders of Information

A recent post to the IXDA.org's discussion group, gave appropriate praise to an improved map of the London tube (subway) system. It can be found at: http://www.oskarlin.com/2005/11/29/time-travel/ Here's a snippet of it:

It adds one significant feature to the traditional map: time zone lines, indicating 5-minute travel distances. They appear similarly to lines of elevation on a topographical map. Great idea by Oskar Karlin. All he did was to add one of the key orders of information, and in so doing added tremendous value. My point isn't to belittle the accomplishment, but to highlight how these same orders are desirable and applicable in almost every information challenge, and therefore in almost every software system... to some extent.

In the following help system for Macromedia Fireworks, six of the classic orders are present.

They are:

  1. Categorical (the traditional table of contents, which web sites have temporarily kidnapped and renamed to "site map"; please don't bore me enumerating the technical differences)
  2. Alphabetical (the traditional index of true "keywords"... intelligently organized and structured hierarchically).
  3. Alphabetical by every word (full-text search; sometimes mislabeled "index" by organizations that don't want to spend time on an index).
  4. Hierarchical (functionally identical to TOC; also known as breadcrumbs; recently under assault by people who don't want you to find things by the most powerful means possible).
  5. The Learning Order (pagewise links between successive topics in the order that they would logically be presented for conceptual understanding).
  6. Relevance (see also links).

The help system does not have information in order of time, but many do. It's usually the revision history.Other common, but less frequent orders include geographical, frequency (which translates to "most popular," "What's Hot," or favorites. It might be a long list, but not endless. For practical purposes, the same handful of orders show up over and over again.

The best solutions don't try to decide which orders a user wants; they provide all of them that could be useful. The need to add all of the useful sort orders is often treated as a magic revelation, painstaking uncovered over the life of a product, but it shouldn't be. These orders were useful and known long before your system was here and should be considered from day one.

(Added 2009) In current software development, they are not in all systems because of software's Big Crime: software is built backwards, from the ground up instead of from a completed system down. Projects have to allocate scarce resources to add time to build such functionality. Even the interface design gets involved in the resource trap: good features are considered distracting clutter because they must be thought through anew on every project instead of using well-conceived progressive-disclosure designs that have previously solved the problem.

2006-Sep-8: The Primary Interface?

I've got three examples of a phenomenon, so I figure that counts as a concept. (Two would just be a coincidence, right?) They get progressively less computerish, but all constitute the expertise of interaction design, if you ask me.

First, robot checkout clerks. At Home Depot, I test the cyberclerks by trying to do what I want, instead of what they are prompting me for. I want the simplest possible interaction, stripped of every extra action, input, and attention. I walk up to the thing...

  1. ... scan my 84-cent, 1/4" brass compression fittings (ignoring the habla espanol prompt),
  2. put in $1.00 and
  3. expect to walk away with $0.16 and my package.

On a good day—most of the time actually—it works that simply. I award one "Use Me" award to Home Depot for succeeding in delivering the "minimal interface." Congratulations.

Now consider my frustration when I went to my local food market. I had to click Start, choose between barcoded and no barcode (salad bar, produce, you know); click Finish; click No Coupons; click Cash. Sheesh, I'm getting old just going to the market. Home Depot had some of those prompts but I proved I didn't have to pay attention to them. I'll try again at the market, but I think they're all "Required Fields."

The second example is the telephone. Despite the addition of features, whether on cell phones or landlines, you should be able to use the interface as simply as on the historically simplest device: either dial a number or have to press one button before or after dialing the number, depending on whether it's a cell phone or landline. I first noticed this phenomenon of the "primary interface" because of a phone that required more decisions from me; who knows, maybe I had to choose a line, or press power, whatever... The point is, I couldn't use it like a stripped down phone.

The third example is even less computerish. The street where I work has buildings with indistinguishable street address numbers. Across the street, as you drive on the street at 50 miles per hour, the building numbers pop out at you (picture soon, I promise)... big, 20" tall white letters on red brick backgrounds, 90-degrees to the driving direction, at eye height. Can't miss 'em.

For our buildings, however, no such luck. The buidlings themselves, have 4-foot tall numbers, but they're dark brown on bricks, 100 feet from the road, and mingled among by trees. Our landlord bowed to pressure and put up numbers at the street... but made them 8" tall, put a hyphen between two numbers, they're blue on silver, and are 45-degrees to the driver. They don't respect the minimal demands of the interface... driving fast staring straight in front of you to pay attention to traffic.

The minimal or "historical" interface is there in many systems. Deliver it, no matter what other layers you need to add on top.

2006-Sep-03: On Simplicity

A recent post to the IXDA.org's discussion group, John Maeda's laws of simplicity, tells of yet another usability pundit trying to stake success on waving the Simplicity flag. There's nothing incorrect about his laws, but usability folks ranting for simplicity is like politicians promising us lower taxes as the solution to all the world's problems. I'm tired of both.

None of us, myself included, would argue that between two interface solutions to the same design challenge, the simpler one is better. The same holds for writing, engineering, maps, you name it. But that is not the issue. Every single technology benefit that we enjoy is the product of increasing sophistication, whether you like the word "complexity" or not. This includes the blog on which Prof. Maeda posts his adoration of simplicity. Or consider cars. Many—not all—of us love the complex features that even the simplest dashboard affords relative to cars of the past. Finally, cell phones. Complain all you want if you feel the interface to your phone is flawed... to me, I have incredible power in my hand. And to do this, my phone has not the 12 push buttons that sufficed for phones of the 80's but 28 buttons, some of which can be pressed multiple ways.

I keep the following excerpt from Science Digest, December, 1982 as an antidote for this :

"It is my belief that simplicty has won it's false supremacy because of the restrictions in time and money that are so often placed on engineers by politicians. The groundwork is cheaper and quicker for simple projects than for complicated ones. Nothing is more certain to cause failure than the lack of proper research, development, and testing. If time and money are fixed too low, the simpler designs have an unfair advantage. The most complicated of them that can just be properly researched within the constraints will win. We can all think of cases where an ambitious project is given too little time or money, and fails through a trivial cause. The failure is wrongly attributed to its complexity.

Simplicty gains an undeserved victory. But time and money can be restricted only locally. If an idea is good there will be another place and another time when engineers who are properly supported will make the idea succeed."

Maeda almost makes my point in his fifth law, which to me relegates his theme to mere marketing.

Simplicity is not a path to solving usability problems. Completing the code is. Automating multi-step processes is. Fault tolerance is. Explicitness, accuracy, and precision are. And increasing learnability at the same rate as complexity is.

2006-Sep-2: Does It Ever Work This Cleanly?

A post on a Ux board recently spelled out the following methodology for some unspecified design work. I've wordsmithed it to draw out the pattern:

  1. Study the problem.
  2. Collect requirements in a workshop.
  3. Confirm the requirements back to the client for them to study.
  4. Discuss the requirements in a 2nd workshop.
  5. Draft a high-level design.
  6. Send draft to the client for them to study.
  7. Discuss the design with the client in a 3rd workshop.
  8. Optionally send a list of proposed changes, collected in the workshop.
  9. Send an improved design, with changes enumerated, for them to study.
  10. Discuss the improved design with the client in a 4th workshop.
  11. Optionally send a list of proposed changes, collected in the workshop.
  12. Send an improved design, with changes enumerated, for them to study.
  13. Invite any remaining remarks.
  14. Incorporate remarks into version 1.0 and send for approval.

Study, followed by four rounds of workshop-feedback-modification. Voila!

Does it ever work that way? Is that all there is? Is it always four rounds? Is that just right for content-centric work? There's no particular 'moral' to this story, this morsel, but I do wonder if there's a hidden logic as we keep boiling it down. One thing it suggests is a question for clients, "How many cycles of feedback should we target?" (Assuming there's no "right" answer, only a best choice.) Maybe it's just a good framework... the notion of study-synthesize-learn, repeated four times. In my mind, when I keep abstracting this loop, it looks even simpler: collect information, synthesize, repeat. I propose that all projects, stripped to the barest logic, are just an infinite loop of learn>experiment>[repeat]. An old boss of mine, when I made exhibits at the Franklin Institute, was fond of saying "When they build a plane, no matter how much they design, someone has to step into the cockpit for the first time and test fly it." In other words, even with the most expensive project, barely resembling software work, the rollout is still an experiment.

2006-Aug-21: Summary of Heuristics, and My Principles

I just came across this nice page that summarizes the top level heuristics of Nielsen and Tognazzi, along with a few links to similar info. It's a great starting point for a lecture to aspiring designers and developers: http://www.stanford.edu/group/web-creators/heuristics.htm. I used it in formulating this list of my "founding principles," several of which consist merely of "standing on the shoulders of giants":

  1. My interest in usability arose from the pain and tears of patching the wounds of suffering interface designs with the inadequate bandages of help files and user guides." —Daniel Cohen, in a forum comment.
  2. "There is always a tradeoff between the convenience of the programmer and the convenience of the user. " —I've always believed that this was from Peter Norton, but I've never been able to substantiate it.
  3. Bellis's Law: For every computer problem, even hardware problems, there is a corresponding improvement waiting to be done to the design of the software or user interface. It is not your fault... the problem is not user error!
  4. "Usability and learnability are not mutually exclusive. Decide which is the most important; then attack both with vigor." — Tognazzini
  5. "Most users are good at reacting to product designs and notoriously bad at identifying the sources of their reactions."
    — Paul Smith, Human-computer interaction professional, IBM, "Debunking the Myths of UI Design"
  6. "Design is a process - an intimate collaboration between engineers, designers, and clients." — Henry Dreyfuss, Industrial Designer

2006-Aug-3: "Design Is..."


"Design is a process - an intimate collaboration between engineers, designers, and clients." - Henry Dreyfuss, Industrial Designer. This quote is courtesy of a contributor to the IXDA.org's discussion group for user experience. It really struck a nerve with me because I'm often involved in project work where the expectation is that, instead of an "intimate collaboration," the expectation seems to be that software design can be a straight road with distinct landmarks that you pass: analyze, design, build. Well, those steps might be in it, but it's a constant give and take all along the road.

2006-Jul-6: Web 2.0

I've been frequently referencing Tim O'Reilly's article, "What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software, so it's overdue that I provide a link.

2006-Apr-15: SecondSite.biz... A Model of Just-in-Time/Just-in-Place Learning

I've put together a detailed article about a site I found recently, an online invoice application (with a growing suite of other tools)... SecondSite.biz. I think I learned about it on AListApart.com. It's an absolute model of all the techniques for eliminating advance training in a software application, as enumerated pretty nicely by Constantine & Lockwood on page 6 of their article, Instructive Interaction: Making Innovative Interfaces Self-Teaching (The Download Page, Direct link to PDF). The following image shows the technique that probably hooked me almost from the start: on their initial setup page, the help flies in as you anchor the cursor in a section. Now ordinarily, we all know that animation is generally frowned upon... but here it's pure state-of-the art... it works for the teacher. I've been recomending fixed-in-place, embedded help for years now but it's still easily ignored. Their site has a completely free trial mode.

2006-Feb-6: Tog Says...

In http://www.asktog.com/basics/firstPrinciples.html, are great words for one of usability's constant negotiation challenges:

"...Usability and learnability are not mutually exclusive. First, decide which is the most important; then attack both with vigor.

Ease of learning automatically coming at the expense of ease of use is a MYTH."

Accessibility and Web Development Tools

I don't write too often about tools because the focus of my site is on results, not methods, but I came across one I have to rave about. It's called "Favelets" from www.Accessify.com. It lets developers see various aspects of what's under the hood of a web page, in direct visuals, rather than reading the code. For instance, the following figure shows two of its tools:

Another one to look into is the AIS Web Accessibility Toolbar, http://www.webaim.org/techniques/articles/aistoolbar. I haven't spent any time with this one yet. [Update: I've added these and perhaps the best, the MS IE Developers Toolbar to the Resources Page.]

2006-Jan-28: Word

I've had this image around for years and thought I'd finally publish it. Have you ever seen a Word DOC without its clothes on? The image below shows the internal code in a Word document. It's happened twice to me over the years. The first time it even showed a running log of past authors of the document, including a co-worker who hadn't been at my office in years.

Full Image

2006-Jan-21: Usability Functional Spec?

Avoiding "We can't change THAT!"

An interesting paper entitled "Avoiding 'We can't change THAT!': Software Architecture & Usability," by Bonnie E. John, et al, has a fascinating list in its Section 2: General Usability Scenarios. Here's a sampling:
1. Aggregating Data
2. Aggregating Commands
3. Canceling Commands
4. Using Applications Concurrently
5. Checking for Correctness...

...and so on. The point of the paper is to highlight software architecture items that can't be simply added on if they are not built into a system. To the technically minded out there, these items will require "refactoring" a design. It's a great paper, although the body is a little curious and the appendix veers off into general nice-to-have-land. But its core items are definitely a key to building usability in. Look for them soon in my Software Function Tree.

The paper is at http://www.sei.cmu.edu/publications/documents/01.reports/01tr005/01tr005chap02.html

2005-Nov-27: You Can't Test in Usability

It's been my feeling that in the same way that you can't test in quality (a popular platitude), you can't test in usability either. A fascinating story about usability testing was highlighted recently by the Human Factors International newsletter. It tells of a study that pitted multiple usabilty teams unknowingly against one another to test Hotmail.com. To summarize the findings: there was almost no commonality among the methods or results. Although it didn't exactly prove my point with syllogistic precision, it certainly substantiates that usability testing has a long, long way to go.

As for syllogisms... of course the invalidity of Method A (usabilty testing) does not imply the validity of Method B (skillful design in the first place), but if I can't solve a problem single-handedly, I can at least wallow in my opponents' misery, can't I?

2005-Nov-19: What's Your Googafinder?

Just on a whim one day—actually it was July 12, 2004 in a morsel below, I thought up the idea of putting a nonsense word into a page to see if Google indexed it, and if it awarded me with the mythic First Hit. My word was fratostat, an imaginary machine part that my co-workers at the Franklin Institute always asked for when they needed a part to fix an impossible problem.

Well, apparently fratostats are solving problems at at least two other places in webdom, but I was instantly above the fold on the only page of listings. And thus was born the concept of the "googafinder," (alternate spelling, googifinder). Since I finally went to the trouble to add the entry to www.pseudodictionary.com, I thought I should announce its birth here.

Now don't all be putting the word "fratostat" or "googafinder" on your sites! Make up a few hundred million other unique words. Of course you could just search for your email address (if you put that on your pages) but that's no fun.

Hmmm, is this the beginning of an entirely new course of human naming... like Madonna, we'll all seek out unique names that will double as electronic fingerprints, tags by which search engines uniquely know us? Oh, shit. I just became Googafinder. I can hear my grandchildren: This is my grandfather, Googafinder... and my grandmother "Getoffthecomputer." Gotta go.

The Worst Dialog Ever

Any guesses what's wrong with this? I'll tell you if you want. See also Best Dialog Ever.

2005-Nov-16.. Writing for the Web

On Writing:

As I printed out the article for my occasional lunchtime walk around Valley Forge park, I half wondered if yet another tree limb had donated itself to paper pulp as one more article telling us that people don't read on the web, they only scan (well, duh). Nope, this one is quite something else again. If you want to learn how to write and who to be when you create editorial content on the web, read Mark Bernstein's "10 Tips on Writing the Living Web."

Of Writing:

And for a world-class demonstration of Mark's principles, read Adam Greenfield's "All watched over by machines of loving grace..." While the message—a hopeful manifesto spelling out a bill of rights for the day when computers are broadcasting your habits from even your toaster oven—took me a while to start absorbing, the wordcraft had me mesmerized and entertained in quick order.

2005-Oct-29: The Worst Link Ever

A few times recently, the subject has arisen about using the conventional colors and cues (as in underlining) for web links. As a demonstrtation of the horrors that are unleashed when one fiddles with these standards, I present one of the most deliberately unethical uses of doing so. In the following image you can see the two options for renewing a Hotmail account:

I opened several such accounts, for myself and my kids. One of them I wanted keep as a free account; the others I pay for. The only way to renew as a free account is the "Click here" link. Notice it is embedded inline in a paragraph and its only cue is color. Folks who know only one anecdotal fact about usability are likely to know, "never use color as a sole indicator." Pretty "lowlife," for the world's biggest whatever they are, eh?

2005-Oct-8: Is Prescriptive Design Actually the Problem?

Is it possible that for projects less than CMM Level "SS" (as in space shuttle) we should stop chasing the mirage of "great requirements," even when we optimistically try to call it adaptive design?

Here's just one option... focus instead on an honest relabeling of V1.0 as "beta," and getting better buy-in, from the outset, for serious usability patches at V2? I'm open to other options. This is not meant to be cynical. I've just worked on too many projects where the notion of articulating a perfect picture on paper (prescriptive design) is so beyond the corporate dynamic, maybe our message—the usability community—is better directed elsewhere.

There are several reasons that prescriptive design doesn't work. Many stakeholders don't have the patience or sufficiently accurate hair-splitting skills to get to the bottom of design issues. Asking to improve the techwriting of reqs is traditionally problematic. And ultimately, isn't there a fundamental conflict between genuinely creative apps and prescriptive design? We're not making shoes, we're making shoe-making machines. And to complete the analogy, the shoes themselves haven't ever existed yet. Yes, no, maybe?

2005-Aug-8: Great Work by KonicaMinolta!

I just wanted to give credit where it is due, to the Konica Minolta folks, for leadership in usability. I sprung for their new, lowest price-point color printer, and never mind that it's an absolute miracle what it does for US$300... here's what amazed me: I had to try their "booklet duplexing" feature to see if it could possibly equal the trick that my office's US$3000-color-HP 5500DN does. The big honkin' HP will take a 20-pg letter/A4 doc and scale and arrange (a tricky step if you've ever done it) the text, then duplex the pages into a 5-leaf booklet that you can fold down the middle. OK, so I'm easily impressed(?).

No, the $300 KM doesn't do the duplexing (a little too much to expect, I knew) but here's the usability miracle: by default it prints a diagrammed instruction page at the beginning of your otherwise duplex print job, showing you which way to re-insert the stack of paper into the printer. How many trees have given their lives to this nuisance? That even some hardware guys(!) were talked into explict, just-in-time, just-in-place instructions of a rather novel, forceful nature, shows how far we've come.

Postscript (no, not that kind):
My office printer stirred some controversy when someone said my fancy system posters cost $5 each to print on the 5500DN. I researched it and found out it was quite an exaggeration. They only cost about $0.08 each. But the rumor might have had its roots in the ink price: it costs about $1000 to replace the set of 4 color cartridges! My KM will cost a mere 1.3 times the printer cost to refill.

2005-Apr-30: Ideal Website... And a .GOV No Less. Impossible?

I just renewed my motorcycle registration at http://www.state.pa.us/ and thought I should share the feedback I gave them on their end-of-visit survey:

"Very nearly an ideal site. On repeated visits the vehicle registration worked flawlessly. Conforms to my guideline that such sites' home pages should be a list of news (surrounded of course by categorical links). Appropriately unembellished site map. Some might criticize the over-abundance of links on the home page but it's hard to avoid on the site for a US state. On a quick review, only a few accessibility nice-to-haves leave any noticeable room for improvement. Great job by the UI and usability folks!"

2005-Apr-17: One Big Print Button... Structure Pages or One Big PDF?

... moved to One Big Print Button.

2004-July-12: No Story, Just Documenting a Word Bug

Dontcha hate it when you get error messages that you know are not exactly right, like "Not Enough Memory or Disk Space to Complete the Operation." Actually this morsel is not a usability blurb at all. Instead, I simply wanted to document the fix for this problem that I had in MS Word because I didn't see the answer elsewhere. Now my box had 40GB of disk space and 1 gig of memory (after rebooting to make sure it was mostly free), so I knew the message was misleading at best.

I tracked the problem down to nasty little images in my Word document that apparently were pasted in with some godforsaken OLE option, like Paste Special/Bitmap Image Object. They subsequently result in codes that read EMBED Pbrush when you reveal codes. Whatever the technique, they were clearly different from regular PrintScreen-and-Paste or similar techniques. When you right click them, you get options for Bitmap Image Object, one of which is Convert. I converted them to Object Type/Pbrush and they re-appeared and the dumb message went away too. I suspect that my machine really was out of memory or some resource because these near-virus objects probably caused a memory leak in Word. Oh, Google, please stop by soon. Fratostat!

2004-Jun--1: On Interpreting User Feedback...

Jakob Neilsen is fond of emphasizing that you should watch users moreso than listen to them. The point nicely is elaborated upon by an IBM expert as follows:

      "...most users are good at reacting to product designs and notoriously bad at identifying the sources of their reactions."
—Paul Smith, Human-computer interaction professional, IBM, "Debunking the Myths of UI Design"

2004-May-1: "Cup-and-Strings" Grows Up, Sort Of

Recommendations for Verizon to Improve Their DSL Install Process

Having succeeded (sic or sick?) last night in installing a wireless router I wonder once again about the state-of-usability. The installation process was typical computer torture, but is it even in the scope of usability commentary? I'm curious how easy or difficult it is for others.

Here's my experience. Despite 22 years of software and hardware experience (including having installed and configured 100 PC point-of-sale networks and coded in 17 syntaxes) I didn't have a fighting chance of installing the #1 name brand Linksys from the docs and setup progs alone. Only after 1 hour on the phone to India did I get the router talking to my browser; and then 30 minutes on the phone to the Phillipines to get the remote computer happy. Problem 1: Verizon/Westell DSL modems use the same hard-coded IP address as Linksys so they had to talk me through altering it, but not until I did a Windows System Restore to get my browser back to a clean state, possibly unrelated. I'm not by any means suggesting the whole thing is Linksys' fault. Problem 2: The remote system needed to be manually configured to regard the router as a DNS server, to get fixed IP addresses, something I was told was not likely to have been documented. And if it was---I looked in the 80-pg PDF before realizing it was unlikely to help me---remember you're usually offline when you're doing this whole thing---it's just about impossible to find.

I'm sure many folks just plug-and-play. So, should I be frustrated of the Industry That Wouldn't Learn, or appreciative that from the perspective of 30 years ago, the notion of a homeowner getting two computers to talk wirelessly would be the equivalent of saying, "I'm bored. I think I'll fly to the Moon today"?

Is there a usability problem here, or do we just 'muddle through' [Steve Krug]? The one thing on which I give no slack is the fact that the Getting Started literature uses circular references for every option described: "Choose the DHCP option if you have a DHCP system." Here are my recommendations to Linksys:

  1. Get a writer to turn the circular references on your Getting Started into real information. I know this is hard... it's called authentic value. Give them a fightin' chance instead of asking for fluffy drivel that's ready at Release 1.0 time.
  2. Put a sticker on the boxes saying: "While you're still wired, go to our website and check our 'Top 10 Problem History." Notice I didn't say FAQ, nor is the solution their interactive online troubleshooting flowchart. If your router power supply is in your hands, like a heart being transplanted, what good is an online tool? I'm guessing that the Westell modem conflict would have floated to the top. And make it a REAL, STATISTICAL HISTORY, not a lame summary of what an interviewer supposes are the problems.
  3. Include a hardcopy conceptual diagram of how the system works, with key Windows (options) dependencies, so that the competent user can quickly map from the issues to the 5 or 10 items on which the install depends... it's not an infinitude but without a simple map, it might as well be.

2004-Apr-03: Vistited any Good Functions Lately?

The question recently arose on the STCs usability SIG as to whether web applications should use the standard web link feature that tracks whether pages were visited... you know, when a link turns purple. I looked in a book I'm reading recently Baxley's Making the Web Work... Designing Effective Web Apps, almost sure he would take a stand on this one but I didn't see the answer anywhere. Yet it's got to be one of about 10 or 15 primary design issues that confront web app designers.

I call the feature visitation tracking, but maybe someone can tell me if there's a formal W3C name. The question isn't concerning the choice of the visitation tracking color---whether deviating from standard purple is wise---but on whether to use the feature at all. (On the mere matter of color, experts easily agree that when you are using VT, you shouldn't fiddle with the purple... the standard color is where the value comes from.) Another option, by the way is to put checkmarks to the left of visited pages. I did this on one of my sites. See http://www.rsiprogram.com/links.htm and experiment by visiting some links and returning to that page.

The VT feature can be defeated by declaring an "A:visited" style that matches the unvisited blue color, or simply using buttons instead of links. I'm on my fourth major web app now, and only on one, a document management system, was VT used at all, and there only for document links. On the others, the presumption was carried over from client-server dialog-based systems that it's inapplicable to track which functions a user uses. Moreover, on web apps, virtually everything will be a link some day. We're 70% of the way there.

Keeping the baby, discarding the bathwater... Nonetheless, I do want to suggest that maybe we shouldn't entirely discard this neat feature that the Web has bequeathed to the programming world. Years ago, I suggested curing the 'toolbox' syndrome of complex software. This is when you have a toolbox with 100 tools in it but after 5 years, you've only used 10 of them. Wouldn't it be nice to turn the toolbox upside down and dump out all the tools to see what's hiding in there that you might need? By tracking functions(!) used, and allowing the user to uncover the unused ones, he or she might have a means to become more proficient. Maybe the right solution is to add a function to our web apps, entitled, "Highlight Unused Functions" or something like that. This would toggle the state of the "A:" (unvisited links) style to a prominent color. Just a thought.

P.S., speaking of links, does anyone notice anything unusual about the macromedia.com site? The future is here. E-mail me with your observation, or for the answer.

2004-Jan-10: Which Is Better, Departmental or Task-Based Structure?

The question comes up frequently of whether a task-oriented structure is better than a departmental structure. It recently arose in regard to a a college library site (see a screen capture). The concern was that the site was organized by departments (internally), not by user tasks (externally). My answer: Why does a site have to offer one browsing scheme at the expense of another?

After all, we're not talking about re-arranging the network folders in which the content resides. I spent 10 minutes (yes, 10 whole minutes, 360 seconds) examining the site (http://www.lib.gla.ac.uk/). The problem wasn't its organizational orientation; it seems to offer all the necessary functionality and resources. The problem is that it simply breaks long-established but simple tenets of design, most notably this: it should put the search box on the home page; eliminate the nickname Merlin; and get the technologists to search all indexes/indicies without requiring the user to choose Keyword/Author etc., exactly as Steve Krug has suggested, Amazon has executed, and as I tried talking people into 10 years ago. No site need honor this rule moreso than a document repository... a library.

I don't discount the frustration at facing the "immovable object" of organizational inertia, but the problem here is not site design but "basics." And this is despite the fact that the site struggles with the central dogma of web design: the browsing scheme. Serious research users are sick of site designers forcing them to one browsing scheme and if you hide---or worse, discard---the departmental scheme you will simply alienate another important group of visitors.

Instead of thinking redesign, this site should apply Neilsen's or Krug's or my list of recommendations and its users won't have to care who won the fight over the "right" scheme.

2004-Jan-07: "Frameworks": Limiting Factors in Reuse & Methodology
Perspectives on Transitioning a Software Company from Service to Product

Here's a situation that maybe you've seen before. You have a software product line that is in great demand by the market, and currently requires lots of custom implementation work. As the market matures, the price point is being driven down, the commonalities among installations are being uncovered, and what was once a custom implementation will soon be a shrink-wrapped, off-the-shelf product. Or will it? This is one of the oldest stories in the World 'O Code, right?

In short order, you decide that the vison of the shrink-wrapped product is just an illusion and you should be targeting a framework instead. Now all you need to do is round up all the code your folks have written and massage it into a set of reusable tools and document the steps that define a successful engagement. Those are the two halves of a framework: 1) the tangible, physical, code-able portion... the stuff you can throw over a wall, and 2) the soft-skill stuff, rules, project plan, questions, flowcharts and so on. Part one I've heard called "reuse" or "background technology." Part 2 is called methodology.

But talk is cheap. How do you make it happen? In my experience there are two limiting factors, which equate to two roles that you need to regiment: librarianship and training. How ironic that the software world, despite all its futurism, boils down to such mundane tasks. Or is it?

No it isn't ironic at all. Every single morsel of the work that can be automated will be automated; no other opinions will be honored. And what's left when you strip away all the redundancy and find algorithms for every last little thing, are the classic chores that still require "hands-on-thinking."

2003-Dec-25: A Classic Microsoft Flaw Story

My IS guy noticed that I included in my e-mail signature a network path (\\server\myUIwork) so that all of my coworkers could learn to find my deliverables. The signature was on all my emails, even external, but I didn't care... to me it's behind our firewall and that's the job of a secured system. But apparently it represents a security risk because every morsel of hard navigation that one gives away enables the hackers to get their random-password generators (or whatever) closer to the final code in the "combination lock."

Being a good employee, I removed the server path from my signature months ago. Then a few days ago, an Outlook email bounced back apparently because it couldn't get to our Minsk outpost as Rich Text not HTML. I selected Format/Text and then Format/HTML (that's how you have to do things in incomplete software---is that a 'kickstart' or an 'Office hokey-pokey'?---but that's not the punchline) and lo-and-behold, there was my old server path, risen from the dead! In a classic of almost all editor programs as they mature over the years, the underlying code was not deleted when I deleted the visible text. Do I hear some of you saying I want my WordPerfect 'reveal codes' back? The difference with Microsoft is that they'll never fix the code, because they don't have to.

2003-Dec-15: Top 10 User Shocks of Converting to a Web Application

  1. Browsing off a page and losing your work.
  2. Incomprehensible feedback during processing delays.
  3. Meaningless messages from a level of software other than the application.
  4. The realization that the blazing speed of RAM has been replaced by a cup-and-string conversation with a server, transmitting pages for every little request as if using Morse-code on a telegraph.
  5. Techniques that you used to take for granted, such as right-clicking to access common functions, or using hotkeys, such as F9, are not there.
  6. Methods you've memorized, such as double-clicking, cause unintended consequences.
  7. Every page and function puts things in a different place, and sometimes with a different name or look.
  8. Techniques that previously required a few memorized keystrokes, such as entering a date, now require a mix of browsing and clicking and keying.
  9. You can't tell "where you are."
  10. Not knowing where your work is saved.

2003-Nov-1: Requirements Definition for a Corporate Intranet

You've got a small company that's just getting large enough to need an intranet. (How do you know? When you start having to e-mail the new phone list out every week or so, it's time.) What should you try to accomplish with your intranet? Funny you should ask because I'm going to tell you how to avoid making the same mistakes as countless others.

By the way, it's very hard to make accurate "requirements." Usually they get intermingled with design. Let's try.

  1. Requirement 1 (Overall Goal), No more email attachments:
    The goal is that all future internal correspondence should take the form, "Such and such information/policy has been updated. See arentWeEfficient.OurCompany.com for details."
  2. Requirement 2: One document instance:
    Continuing the phone list example, when someone edits the phone list, they must be editing the copy on the web server, one way or another. Even if you use some sort of escalation process, document management system, or content management system in which an offline copy is edited, you must not have a situation where "Fred" edits his own "master" and begs for the IS department to post the file to the web server. The document that is edited must essentially be the source instance of the information.
  3. Requirement 3: Visitors can find what they want:
    Well, duh, gee... the last 8 years (12 if you include "Help" navigation) have been all about this and there's still no answer. Let's try to drill down a little. There are actually several items and they cross over from 'requirement' to 'design':
    1. Users can find documents by searching for any word within them.
    2. Users can find documents by browsing through a structure that mimics the corporate org chart. This means department-based navigation is available.
    3. Users can find documents based on intelligent, professionally authored, alphabetical index keywords (something that we've become accustomed to over the last 1500 years of the printed word.) Hmm. This is a tough one, someone has to either go to college and be taught about words, or they have to have otherwise grown a talent for tasks such as indexing. Jack you ask too much.
    4. The body of the home page should be fundamentally an ordered list of changes to the site... a log with the most recent additions or changes at the top. Look at my home page or Jakob Neilsen's. As soon as you stray too much from this basic idea, you will start creating a maze not an information system. Another word for this type of page is "News," but I'm recommending an objective, methodical, exhaustive list of news, not a "pet" topic that is marketing driven or neglected.
    5. There's one departure that you can tolerate on the home page: a "Most Popular Items" listing. Ideally this should be automatically generated by software, showing the most requested pages. It will often parallel your most recent changes but will also include perennial and periodic favorites that might not be new or changed.

    That's it. Everything else is design, not requirements.

Off-Topic-But-Fun: "I Spy" in a Software Splash Screen

In my user interface work I often get called upon to make splash screen artwork for software applications. This usually entails either pure abstract art, or some anachronistic reference such as a telephone or typewriter. And it often ends up being a collage, since no single element quite conveys the message. So I got quite a laugh when I saw the splash art for the newest version of McAfee VirusScan, below. It has every classic collage element, almost as if every department called the artist and said, "Can't you add a...?" My favorite is that it even has the 1's and 0's of some mythical binary stream. And I love how there are bugs (which are not viruses). Does the product detect those too?

How many can you spot?

The Ultimate Simplicity... from Microspam no less?

I was pleasantly amused to see the following page when accessing MS Hotmail (aka Spam Server to the World):

No graphics, no legalese, no marketing, just a barebones message that some engineer had to put on the system amidst Microspam's millions of otherwise highly styled pages. In fact, even under the hood as shown in the Notepad window, this page is the epitome of simplicity, 5 lines, no headers, includes, styles. Jakob Neilsen, are you listening? It's not hopeless; someone's been paying attention after all!

It looks like you can even enjoy this page without logging in. Feel the breeze of old-time web simplicity waft over your body for yourself at http://lw9fd.law9.hotmail.msn.com/toobusy.html.

The Future of User Interfaces? When Will the Past Finally Get Here?!

Rummaging through the discarded magazines at my local library (I'm not cheap, I'm thrifty) I came across an article from the April, 2002 Scientific American, preparing us for the wonderful future of user interface technology. It was extolling the virtues of "augmented reality," wherein computer data is superimposed on your live view of the world.

For instance, a surgeon might see a view of a patient's internal structures superimposed on the body while operating. The data would be captured by various imaging technology. Or a soldier might see an otherwise hidden opponent right "through" a wall as he looks down an alley. The data would be relayed by a satellite camera. I won't waste your time with any more dreamy examples, just this closing line from the article: "When computer user interfaces are potentially everywhere we look, this may become the primary medium for a new generation of artists, designers, ..." blah, blah, blah.

Against this blathering futurmania, we have the reality of current-day user interface design in which even the rudiments from the previous 1000 years of the written word are completely beyond the grasp of many designers-by-default. I'm the last person to naysay wild-eyed dreams for the future; in fact I predict that aging will be "cured" within the next 25 years. But even discounting cost and feasibility issues, this sort of talk just seems to miss the point and blow things way out of proportion. Yes, exotic tools may become reality. But compared to routine computredom, they'll be artificial reality at most. It's common to say and think that things change really fast in technology, but it's not as fast as you might think:

  • Millions of people still use Windows 95, eight years later.
  • Every computer still uses an ASCII character technology as its underpinning, and there's no reason in the world that you should expect this to go away, any more than electronics means that electric circuits are obsolete.
  • And plain ol' text will still be the most valuable everyday tool long after augmented reality becomes the next forgotten "killer app," right there with PDAs and my favorite, E-books.

Users don't need their reality augmented, they need it made more usable. This will only be done the old-fashioned way, whatever the technology: by being explicit, fault-tolerant, and flexible.

If Manufacturing Had to Play by Software Rules...

I think I've got a good analogy for the outrageous practice of coding applications in a browser. Imagine if all the products of daily living had to be manufactured by the same factory that makes washing machines, with the same materials, processes, and machinery:

  • Cars wouldn't roll to their destination, they'd spin and vibrate until they got there.
  • Houses would be big metal boxes, really big, and only come in white or eggshell. Of course there would be only one window/door, but drafts wouldn't be a problem any more with that water-tight seal.
  • Everything would have a motor whether it needs it or not. For instance, telephones would be a minimum of 1/2 HP.
  • Even the simplest processes would now require a wash, rinse, and spin cycle. Opening the door to your house would take approximately 45 minutes.
  • Beds would be very uncomfortable, but on the plus side you could centrifuge yourself into utter unconciousness.

The Unified Force Theory of Usability

Explicitness.

That's it. End of message. Unsubscribe. Case closed. Just remember you heard it here first. Sooner or later the world will come around. The root cause is the hidden nature of electronics, so the only overarching antidote is explicit communication.

On the Usability Profession

Daniel Cohen of Washington, D.C., has just the right words to describe why many of us get into the usability fray:

"My interest in usability arose from the pain and tears of patching the wounds of suffering interface designs with the inadequate bandages of help files and user guides."

On (Windows') Error Messages

Bill Gates' dad, charged with the arduous task of doling out $17 billion in endowments, apparently uses Windows in his drudgery. Says the elder Bill: "You know, the language of some of those messages... it just drives me crazy. They are flat-out incomprehensible."

Support Nightmare January 2, 2000

I called MS one day after struggling with FrontPage database access, the only feature I had purchased it for. After 18 years of frustrating techsupport phonecalls, I was determined that if they didn't pick up the phone on the first ring... if I didn't talk to a real person... if they didn't solve my problem on the first try... I was returning the program.

Miraculously, Microsoft picked up the phone immediately... a real person, no less, talked me through rerunning the Active Server Page (ASP) install, and it fixed the problem on the first try. I'm still undergoing therapy to recover from this truly unsettling occurrence.

Who links to my website?

 

"Usability and learnability are not mutually exclusive. Decide which is the most important; then attack both with vigor." — Tognazzini

© 2003, UsabilityInstitute.com   All Rights Reserved    jackbellis@hotmail.com
Any and all content may be reused without prior consent if you simply acknowledge the source, UsabilityInstitute.com