I’ve spent too much time developing web applications recently, and
getting fed up with the constraints of designing user interfaces on
the web. Try imagining having to write Microsoft Excel for the web to
run in Netscape, not using Java, and you’ll know what I mean.
So in order to compensate, I’ve been toying with some Windows
application development, just for fun. And it struck me how
Microsoft have always been really, really good at writing complete,
solid UI widgets. From simple things, like the standard text entry
field, or the menu widget that most application windows sport, to more
complicated things like the file open dialog or the Excel spreadsheet.
This becomes apparent when you’re suddenly exposed to an application
that doesn’t use the standard components, such as Netscape 6, or
applications built on Java Swing, or even worse, Gnome. They just
don’t work as well as Microsoft’s ones.
So what is it that makes Microsoft’s widgets better? Several
things. They always allow for as many channels of interaction as
possible: Normal typing, arrow keys, special keys, such as
Alt-Backspace, arrow keys, shift-control-tab and other special keys,
alt-shortcuts, cut, copy, paste, keyboard selection, mouse selection,
moving selection, right click, drag and drop, animation, sound, you
name it. They always display without flicker, something that
makes them seem more robust. This is very basic, yet many
widget developers overlook this factor. And they always have a
professional, if boring, graphic design to them. It always
shows when the graphic design of a widget isn’t done by a
professional.
Now, the interesting thing, of course, is that none of Microsoft’s
main applications use their own supplied standard widgets. Their
toolbars and menus can be docked and un-docked. Their menus have icons
in them. Their scrollbars have this little tooltip thing pop up to
show you where you’d currently be scrolled to if you let go.
This is obviously easier for Microsoft to do than for any other
company in the world, since they have the source code to the original
components, so they can merely extend them, while all other
companies will have to rewrite them. And when rewriting, you’re
likely to introduce subtle differences that are going to present
themselves as annoying inconsistencies in the user experience. Another
exploitation of their monopoly power.
Bottom line is that it makes sense to invest heavily in these building
blocks of the graphical user interface, since they’re going to be
used in application after application. Microsoft is constantly
evolving their widget library, cross-using it between applications,
and they always keep the latest iteration to themselves, only
gradually releasing them for third-party developers after they’ve been
exclusive property of Microsoft for a year or two. Unfair, but clever.
LocalWords: pinds
Which would you prefer to write a letter to your grandma: A word
processor, such as Microsoft Word, or a text entry widget in a
browser? Or which would you prefer to read your email: Microsoft
Outlook or web-based Yahoo! Mail?
There’s no denying it. Despite the many advantages of web-based user
interfaces, or WUIs for short, they’re generally a major step back
from the desktop application GUIs (graphical user interfaces) that
came before.
It’s not that the windows-icons-menus-pointer (WIMP) interface
paradigm of typical desktop applications is all that great. But
browser-based interfaces, while admittedly adding a few neat new
ideas, are much more limited.
In a WUI, you can’t provide an application-specific menu. You can’t do
drag-and-drop style interaction. You can’t create a context menu that
pops up when the user right-clicks on an item. You can’t create your
own interaction gizmos that suit your particular application’s needs.
Some things you can do using JavaScript, Java, Activex, and
similar technologies, but they’re generally not stable or responsive
enough, and ActiveX in particular will only work on Microsoft
platforms.
To make matters even worse, the WIMP-features of the browser, i.e.,
the menus and the tool bars, clash with the web-style content of the
page to produce an unpleasant and inconsistent mess. Almost 20% of
the screen real estate is used up by features of the browser, such as
the menu, the toolbar, and the status bar, that aren’t part of the web
user interface itself.
There are of course a number of advantages to web-based user
interfaces, the most important one being that you don’t have to
install software on your machine to use it. And there’s no on-going
system administration cost, e.g., for upgrading the application to a
later version. You just need a computer with a browser. And
browser-based interfaces have also cut down significantly on the
amount of work it takes to develop the user interface part of a
software application, which can run upwards of 75% of the number of
lines of code in traditional desktop applications.
How long will users put up?
Microsoft’s take.
You can always tell an out-of-towner in New York’s subway. He’s the
person that has to swipe his card five or six times through the
turnstile, jamming the whole weight of his body against the
immovable bar, until it finally works.
Real New Yorkers take pride in operating the turnstile as smoothly as
possible. They learn through bitter experience at exactly what pace
the card must be swiped, and manage to do the
walk-up-swipe-and-walk-through maneuver in one smooth, yoga-esque
motion. And just when you’ve really got the hang of it, your
metrocard is expired, and there you go slamming your body against the
bar, embarrassed to look like you’re from out of town.
Slit, Not Slot
A little while back, I wrote about <a href=”http://pinds.com/articles/2001/04/04/metrocard-mess”
title=”MetroCard Mess”>how frustrating
the Metrocard vending machines are. But the fun doesn’t stop
there. The turnstiles in the subway in New York have several usability
problems.
The main problem is the fact that they use a slit that you must
swipe your card through. Other subways, in contrast, has a slot
that takes the whole card inside the machine, so that it can suck it
through the system at its own pace, thus eliminating a whole category
of errors. In New York, it’s up to the user, not the machine, to
ensure that the card is swiped at the right speed. And it’s up the
user to ensure that, when aiming for the slit, he doesn’t dip the card
too late, or pull it up too soon.
Please Swipe Again at This Turnstile
This problematic design also leads to more subtle errors,
which, in turn, is the reason behind the infamous “Please swipe card
again at this turnstile” message. With a single-ride metrocard, for
example, the machine must first read the available balance on the
card, determine whether that’s enough, then deduct the $1.50 fare, and
write that new amount back on the card, all within that single swiping
motion by the user.
If, for some reason, the user pulls out the card too soon, it might
get interrupted before writing the new amount back, or even
while writing the new amount back. In order to deal with this
problem, the turnstile has to remember what card it just saw, so that
when you swipe your card again, it can finish the transaction it was
doing, rather than start a new transaction.
Of course, people frequently ignore this message, and assume that it’s
the turnstile that’s broken, so they move to another turnstile and try
again. So the MTA has to put up posters, explaining to people that
it’s important that they stick to the same turnstile. All in all,
both the turnstile and the user must do a whole lot of
work to make up for the fact that the design doesn’t guarantee
that the transaction is atomic.
Did It Go Through? Ouch! I Guess Not!
All of this is augmented by inadequate feedback. As mentioned, people
have taught themselves this smooth walk-and-swipe
motion. Unfortunately, this means that, by the time you’ve swiped your
card, your body is already so far ahead that you can’t read the
display that tells you that you failed.
There is an audible feedback: A beep that I believe actually is
different when you’re okay and when you’re not. But the difference is
too hard to notice. There’s also the clicking sound when the bar is
released, so it’ll turn when you lean against it. The
absence of this clicking sound will also help tell you that
you’ve failed. But the timing here is tricky, since it’ll take a
while before you realize that the sound is not just delayed a bit,
it’s actually not planning on coming at all.
In any event, I usually end up unconsciously sensing that
something’s wrong, but by the time this realization reaches my
conscious mind, it’s too late. I have too much inertia to stop
moving, and a split-second later, I jam my body against the bar,
embarrassed look up and around, hoping that nobody noticed.
What aggravates the pain is that, while probably about 95% of my
swipes are successful, when I have to swipe again because of a
failure, it usually takes three or four more tries before I succeed. I
believe this is because the swipe is an unconscious bodily skill.
When there’s a breakdown, and I become conscious about swiping, I
can’t do it right. This is a common phenomenon: Try to breathe
normally while consciously monitoring your breath, and you’ll know
what I’m talking about.
The English Boarding School Effect
At first, I actually liked this interaction style. When done right,
the elegancy, ease and speed with which you can pass through the
turnstile is, ahhh, gratifying. And, having a technical
background, I was impressed with the technical achievement of
conducting that whole transaction is one swipe, as well as with the
amount of thought they’d put into recovering from failures.
Also important, I enjoyed showing off my mastery of the
turnstiles when I was accompanying visitors. I could clearly
demonstrate that I had truly become a New Yorker.
But later, I came to realize that New York’s subway doesn’t have to be
like an English boarding school. There’s no need to unduly harass the
newly arrived, who are already adequately intimidated by the city
itself. And I also started noticing the frustration and embarrassment
in the faces of especially native New Yorkers, when they occasionally
fail to swipe correctly. This is wrong. Technology should not make
people feel stupid.
Lessons for Design
A few lessons can be learned from the turnstile design:
- Design with a clear goal
-
If the goal is to penalize newcomers and reward regulars most of
the time, then the design can be considered a success. But this is
not a good design goal. It should be easily accessible for both
newcomers and regulars, and in any event, it shouldn’t make any of
these feel stupid.
- Eliminate the causes of error
-
When the turnstile programmers realized that they were spending so
much effort trying to recover from aborted transactions, maybe
they should’ve considered changing the interaction style to
eliminate this whole class of errors.
- Give the right feedback at the right time
-
The audible feedback should more clearly distinguish between
success and failure, and the visible feedback should be moved
further back, past the bar, so the chance of seeing it while
you’re moving forward is increased. Normally, the absence of sound
is a good way of signaling error, because it avoids telling the
bystanders that you’ve made a bummer, but since the interaction
here happens so fast, by the time you realize that the sound is
missing, it’s too late. If the sound could be designed so it’s
directed towards the person in the turnstile, so bystanders can’t
easily hear it, that would help avoid some of the embarrassment of
failure.
- Usability test in realistic settings
-
The turnstiles must be tested both with novices and with people
that have had a lot of time to practice, and be tested by people
moving through the turnstile fast. At this point, it would be
prohibitively expensive to replace all the turnstiles, but at
least new replacement turnstiles could be designed better. The
upside of the massive installed base is that it’s easy to gather
test data: Just mount a couple video cameras at selected subway
stations and analyze the many failures.
Good luck, MTA!
Has control of the desktop, including the browser. Extending this to
other devices, such as palms (pocket pc), cell phones, and gaming
boxes (xbox).
Expanding on the server side, with features that make software running
on MS servers (dot-net) better able to exploit the MS clients (Dot-Net
UI stuff).
Expanding this into services, such as Hailstorm, that they can charge
for.
