|
|
Morsels... A Running Log of Usability
Anecdotes and Antidotes
2009-May-26: Hall of Fame-Worthy Videos
- "Human Interface" http://vimeo.com/4697849 ... 6-minute video of a person in a glass-top-box, acting out interactions from an unseen fingertip.
- 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...
- Newsgroups
- Distribution lists
- Forum
- Blog
- Chat
- Tag
- Wiki
- Friend (probably not a type, just an option)
- Notify (RSS, feeds, formerly distribution lists?)
- Community (formerly newsgroups?)
- Rating
- Voting
- 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.
- 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.
- The only items in the root should be folders.
- Folders that have names with repeating phrases or have
only minor differences should usually become a group of subfolders.
- 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.
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:
- Whereas... most software is informational (research-oriented) moreso than manipulative (such as tools that create data)...
- And... graphical representations of data, though they've come a long way, are still far from fulfilling their destiny...
- 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:
- The Web As Platform
- Harnessing Collective Intelligence
- Data is the Next Intel Inside
- End of the Software Release Cycle
- Lightweight Programming Models
- Software Above the Level of a Single Device
- Rich User Experiences
|
The O'Reilly article even cites a similar list from Christopher Alexander, who offers this breakdown:
- The Long Tail
- Data is the Next Intel Inside
- Users Add Value
- Network Effects by Default
- Some Rights Reserved.
- The Perpetual Beta
- Cooperate, Don't Control
- 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.
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:
- 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)
- Alphabetical (the traditional index of true "keywords"...
intelligently organized and structured hierarchically).
- Alphabetical by every word (full-text search; sometimes
mislabeled "index" by organizations that don't want
to spend time on an index).
- 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).
- The Learning Order (pagewise links between successive
topics in the order that they would logically be presented
for conceptual understanding).
- 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...
- ... scan my 84-cent, 1/4" brass compression fittings (ignoring
the habla espanol prompt),
- put in $1.00 and
- 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:
- Study the problem.
- Collect requirements in a workshop.
- Confirm the requirements back to the client for them to
study.
- Discuss the requirements in a 2nd workshop.
- Draft a high-level design.
- Send draft to the client for them to study.
- Discuss the design with the client in a 3rd workshop.
- Optionally send a list of proposed changes, collected
in the workshop.
- Send an improved design, with changes enumerated, for them
to study.
- Discuss the improved design with the
client in a 4th workshop.
- Optionally send a list of proposed changes,
collected in the workshop.
- Send an improved design, with changes enumerated, for them
to study.
- Invite any remaining remarks.
- 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":
- 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.
- "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.
- 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!
- "Usability and learnability are not mutually exclusive.
Decide which is the most important; then attack both with
vigor." — Tognazzini
- "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"
- "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:
- 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.
- 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.
- 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
- Browsing off a page and losing your work.
- Incomprehensible feedback during processing delays.
- Meaningless messages from a level of software other than
the application.
- 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.
- 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.
- Methods you've memorized, such as double-clicking, cause
unintended consequences.
- Every page and function puts things in a different place,
and sometimes with a different name or look.
- Techniques that previously required a few memorized keystrokes,
such as entering a date, now require a mix of browsing and
clicking and keying.
- You can't tell "where you are."
- 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.
- 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."
- 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.
- 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':
- Users can find documents by searching for any word within them.
- Users can find documents by browsing through a structure that mimics
the corporate org chart. This means department-based navigation is available.
- 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.
- 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.
- 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? |