Within a few moments of playing with the iPad’s photo browser, two things became apparent: 1. there is a better way to crop, and 2. multi-touch, despite the hype, really does have some advantages over the mouse.

The iPad’s photo browser lets you grab an image with two fingers to both pan it and resize it with a single fluid motion.  On the iPad you are merely zooming into a picture to check out your friend’s pores.  But it’s clearly a faster and more fun way to crop images.

I haven’t yet seen cropping done this way, so it constitutes today’s idea to steal.

[Researchers: It would be interesting to validate this claim by comparing the time to crop between using the mouse vs. multi-touch method.]

This scenario also exemplifies a sweet advantage of multi-touch over mouse, which is that it lets you do multiple direct manipulation operations at once.  Cropping is one fluid operation, as opposed to many micro-interactions to do the same task with a mouse:  targeting edges and corners of the crop rectangle with a mouse and dragging them.

That said, you can potentially accomplish a similar fluid crop operation with today’s mouse.

1. User selects the crop tool.  A crop rectangle appears at the largest possible size.
2. User presses turns the mouse wheel to enlarge the photo within the frame.
3. User drags the image around within the frame

This method eliminates the picky targeting of edges and corners in regular cropping.

On Macs the nubs are on the F and J keys.  On PCs they are typically on the D and K keys.  Either way, they help the touch-typist to get their fingers in the right place without having to divert attention from what they are looking at on screen.

The strange thing is, these are the only keys with nubs.  This helps with the heavily used keys.  Our muscle memory helps our fingers find other letters around this center.  But it’s difficult to accurately stretch those digits up to the digit row.  It’s error prone and slows typing as one must carefully check typed numbers for accuracy.  And typing numbers with accuracy is critical.  It could mean the difference between a $6000 and a $7000 request.  And unlike typing words, numerals cannot be assisted by automated spell checkers.

I’ve long wished for nubs up there on the number row to help me out.

Exactly which keys deserve nubs is a good university research project.  The 5-6-7 keys I find difficult to get right without care.   The 9 and 0 I find difficult also.  So offhand I would guess that the 1, 6 and 0 would be good candidates.

By the way, did you notice the little in-joke on the onscreen keyboard on the iPad?  Yes, you guessed it – the images for the F and J rows have little nubs on them. It’s surprising this one got through given Apple’s extreme discipline for minimalism.  Har har.  Yes, Apple, you’ve reduced us 60 wpm typists to hunting and pecking amateurs, and here’s the salt thrown in the wound in the form of nubs that can be seen but not felt.  Good one.

Someone at Apple has a sense of irony.

Today, if you mark your beautiful template as stationery, when you subsequently open it it creates and saves a copy of the file under the same name with the word “Copy” appended, in the same directory.

This so does not make sense.  First, people often to store templates a central repository of tools, outside any project.  That is not where you want your new project-related instance to be.  Moving it to the right location is an added, unnecessary step.  Secondly, the name of the template is never going to be the right name.  If the user doesn’t think to change it immediately it will cause confusion and make it hard to find the document.  That’s more unnecessary work, including closing the document you just created to move and rename it and then reopening it.  These required steps make the stationery worse than useless — it’s less work to just manually copy a template file to the destination.

The better behavior (to steal) is to instantiate a new, unsaved, untitled document when the stationery file is opened.  Later, when the user saves, it  she can give it the right name and put it in the right location the first time.  In other words, just like how untitled documents have always worked.

[Didn't stationery once work like this?  Anyone have insight into how and why it went astray?]

Here is the workaround I’ve been using for a while.  Never use the Stationery bit.  Do mark templates as Locked bit.  This will have almost the correct behavior.  When you open it, it will look like you are editing the template.  But it will prevent you from saving over it, instead prompting you for a save location and name.

[Bonus idea to steal #1: why can't the File Save dialog give instant access to the Finder windows that are already open?  These are the most likely save destinations because they relate to the current project.]

[Bonus idea to steal #2: When you do Save As, why must it give you what amounts to an arbitrary default save location?  Why not default to the current folder?  This would match the scenario of retaining an old version of a document while branching it for further editing.]

To understand the irony we have to go way back through the annals of user interface history, a history that is unkind to Apple’s repeated efforts at improving the mouse.

In the early days of GUI computing, it was common for mice to have three or buttons. The problem was there was no standardization for what each button should do. As a result, various apps used different buttons for the same basic operations.

Sun's 3-button mouse, circa 1987

I remember programming on a Sun workstation that had one of these three buttons mice.  It was extremely difficult to master the basic tasks of clicking, dragging, selecting and opening.  One app would train your fingers to do it one way, and another app would train them in a different direction.

Apple’s 1984 Macintosh (and the Lisa before it) avoided this confusion by limiting the mouse to just one button. Users never clicked the wrong button because there was no other button to click. Click to select. Click and drag to move something. To open an icon on the desktop, use issue a bit of Morse code, and double-click it.  Dot dot.

1984 Apple Macintosh Mouse

In the early 90s, Microsoft and Apple one better. They reintroduced a second mouse button.  But this time they avoided the foibles its predecessors by establishing a rock-solid standard for what the second button would do.  The button would invoke a context menu on the clicked object and never anything else.

It was a welcome innovation in the progression of object-oriented UI’s that we now take for granted.  You could now right-click on any object to pull up a tailored list of actions that can be done on just that object.  It was a lot faster than hunting through all the menus for items commands that became available by the existence of the selection.  And it brought the most used tasks to the forefront, right under the cursor.

A 2-button Mouse by Microsoft (there was a plainer white mouse that came before this model, but I couldn't find an image of it)

[The unsung hero who pushed this standard through deserves a place in the User Experience Hall of Fame.  Anyone know the responsible party?]

Apple resisted this convention. Actually, different parts of Apple reacted differently.  The industrial design part of Apple resisted it, never dedicating a button to context menus.  But the OS software side supported the PC convention.  Right-clicking worked on the Mac with third party USB mice since before the dawn of Mac OS X.  It was a quirky position for Apple to take: it’s okay to have a mouse with two buttons, as long as it doesn’t have an Apple logo on it.

Apple’s hack for giving access to in-place menus was to have the user hold down the Control key and click menu.  It’s always been pretty clumsy for such a common task.

Even more clumsy was the little gear sprocket button that showed up in the button bar area, introduced a few years ago. This gave the hitherto invisible context menu a visible affordance, which sounds good in theory.  In practice I don’t know if people use it much.  And unlike in-place menus, it’s dissociated with the object it relates to.

Apple's context menu sprocket button

Innovation in mice continued its march forward without Apple. Around 1997, in the early days of the Worldwide Web, Microsoft introduced the scroll wheel between the two buttons.  You could now scroll a web browser or a word processing document without having to mouse over to the little scroll bar widget.  You could keep your gaze on the article you were reading and scroll the page almost telekinetically.  We’d never had to scroll so much before the web was invented, and the scroll wheel was a welcome advancement.

Microsoft mouse with scroll wheel

The right mouse button and the scroll wheel are so critical to basic productivity that any serious Mac user simply needed to buy a third-party mouse. Buying a Mac?  Buy a functional third party mouse to go with it.

In the late 90′s an apparent error in Apple’s lab led to the inadvertent release of a mutant puck mouse, which must have scampered through a door left ajar.  The puck mouse was perfectly round.  So round that you couldn’t feel which way was up.  It was very common for it to be at a slight angle when you moved it, causing the cursor to go careening off in a diagonal direction.   Luckily for the puck mouse, it had a cord, so defenestration was hard to achieve.

Apple's painfully symmetric puck mouse

(Later models added a little indent so you could feel which was was up.)

So Apple stuck to its guns, suffering from its ongoing affliction of button-phobia.  Form continued to triumph over function.  True simplicity lost out to the appearance of simplicity (as it does on the iPhone).

I suppose a second mouse button would mean that they surrendered. Or that they were desecrating the clean lines of their laptops or and mice with another button. Never mind that brining up a context menu is such a frequent operations.  (And please put out of your mind the fact that the keyboard already has about 76 other buttons for typing.)  That second mouse button would kill.  We’re trying to think different(ly) around here, people!  (See also: Apple’s Revolutionary Laptop With No Keyboard)

Apple continued its buttonphobic ways.  They even went backwards, to no visible buttons.  Instead of clicking a button with your finger, you apply pressure to the top part of the housing and the whole thing rocked forward as a click.

Apple's zero button mouse

Beautiful, right?  And that clear outer shell never got scratched up, because it was always kept in a desk drawer.  It didn’t help that the USB cable on this mouse was only long enough to reach the port on the (also functionally challenged but also transparent) keyboard.  It would not reach the USB port on the back of the noisy G4 tower under the desk.  Oh, yeah, and the (transparent) wire frayed easily.  Anyone with actual work to do put the mouse away and desecrated Apple’s sculpture by using a functional, ergonomic, ugly Logitech mouse.

Then came Apple’s Mighty Mouse. It too used the whole housing as one physical button switch.  It had a touch sensitive area under the fingertips, and you could bring up context menus by clicking on the right side with your middle finger. If, that is, you dug into preferences and activated the feature.  That’s right, at this point right-clicking is still not acknowledged as a mainstream thing.

There was just one catch: the touch panel would only register a right-click if you lifted your left (index) finger off the left area of the mouse.  Without knowing this critical piece of information, and practicing it enough to be automatic, right clicking was haphazard.  This was fatally unintuitive and aggravating.

Apple's Mighty Mouse

The Mighty Mouse was and is also loathed for its miniscule built-in trackball.  This innovation was supposed to allow for scrolling in all directions, but would jam up with dirt after a few weeks’ use.  Later Mighty Mice were cordless, so there was no saving the poor things from windows left open.

Which brings us to today, Tuesday October 20, 2009.

Apple has been adding gestures on its laptop trackpads for the last few years.  Those gestures were nice refinements, but not earth-shattering.  And they only worked when you were actually using the trackpad.  At a desk, if you use an external mouse, the trackpad and its fancy gestures are irrelevant.  On this date, Apple introduced the Magic Mouse, with, lo-and-behold, a trackpad built in.  You can still drag it around like a regular mouse, but you can also twiddle your fingers on it to do other tasks.

Apple's Magic Mouse, 2009

And here we finally arrive at the irony.  25 years after the 1984 Macintosh mouse – belligerently endowed with just one button for the ostensible sake of simplicity — we have a sleek little wireless mouse that lets you not only click, not only right-click, but also scroll, pan, zoom, and swipe using invisible gestures.

Simple, right?  :-)

But is it crazy enough to work?

I’m curious about how usable this integrated touchpad/button is going to be.  The video certainly looks compelling. Did they solve the Mighty Mouse’s right-click problem?  Will all these gestures be inadvertently triggered during regular clicking and dragging?

If it licks these problems, Apple will have, finally, trapped a better mouse.

[Update 10/22/09: Alas: "Right clicking requires a lifting of the left click finger, just like the Mighty Mouse".  Oh well.]

Requisite idea to steal

Why is it that web apps don’t get to use right-click events? This goes both for AJAX-style apps such as Google Wave, and Flash and Adobe Air web apps. That’s right, you cannot right click on an object to bring up its properties.  This a serious productivity limitation for SaaS apps, which are striving to catch up to the evolved usability of  desktop apps. [11/17/09 Update - I'm wrong wrong wrong.  Per the comments below, it is possible for AJAX and Flash/Air apps to tailor the context menu.  It's just that many apps just fail to do so.]

And here is an older idea to steal a different way to pan and scroll without resorting to gestures: make use of an accelerometer.

See also

• Panning & scrolling with a mouse by tilting
• Apple makes the trackpad a mouse button

—–

Philip Haine has been using Macs continuously since the original 128k model in 1984, for the most part as a fan boi. He is founder and principal of Product Vision Associates, an innovation consultancy that helps product leaders and their teams envision and build products that are even better than Apple’s mice.  He also writes the Product Vision Blog.  To follow him on Twitter click here.

Most of the time you will see that I have the big monitor plugged in to my laptop.  When I do, I have things arranged a certain way. I put my e-mail on the laptop monitor. I tell the Dock to stay visible and not recede into the edge, because I can afford the screen space. I want my palettes in various productivity apps to be arranged so as to make efficient use of the big display while leaving plenty of real estate to do my work.  Scrivener and Inspiration need lots of space, so I want them to be maximized on the big screen. I want my instant messaging app to be down on the laptop monitor.

On other occasions, you will notice that the big monitor is not plugged in. It’s just me and a 15″ laptop screen.  You see me hide the Dock to free up precious space. Scrivener and Inspiration will still be maximized, but that of course means smaller height and width on the smaller screen.  You see palettes in my power tools arranged just so, to make best use of my smaller on-the-go set up.

You see me switch between these two configurations pretty regularly.  You should know now how I like things in each case.

So please, when I come and go and switch my workstation around, take care of these details for me so I can concentrate on my work.

This implies that:

• Each application needs to be aware of the various display configurations that are actually in use.  And each should keep track of UI layout so it can recreate it automatically when I move about.  The first few switches will still require the user to move things about.  But the UI will be trainable and it will learn over time.  This will save a lot of time diddling around with UI elements every time I move around.
• The Dock should learn (possibly with repetition) that you prefer it to be hidden on small screens and always visible on large screens.
• Treat “maximized” as a special state.  When the machine awakens to a smaller display, don’t put a 1900-pixel-wide window on a 1400-pixel-wide laptop display without resizing it.  And vice-versa: if a window has been told to be maximized, then make it maximized when moving to a larger display.
• When the configuration changes, put windows in reasonable locations.  (In moving to smaller displays, I find many windows stuck along the bottom edge, with only the title bar showing.)

This will also help in the future, when our world is in the cloud, and our workstation is any computer, anywhere.  Those workstations can come in any shape and it will behoove the software to arrange the workspace accordingly.

See also:

• Making efficient use of big displays (from almost four years ago)

—

Philip Haine is principal of Product Vision Associates, a product innovation consultancy that helps product leaders and their teams envision new, breakthrough products and reboot older ones.  He also writes the Product Vision Blog.  To follow him on Twitter click here.

It’s kind of cute, as long as the laptop has its own bedroom.

But, like a snoring dorm-mate, it’s the most annoying thing when you have no choice but to share sleeping quarters.  Such is the case in hotel rooms, or when a home office serves as an impromptu nursery for an eight-month-old.  The laptop causes the ambient room light to cycle from pitch dark to bright night light, piercing photons through your eyelids, keeping those synapses firing, and inhibiting sleep.

The analog remedy for both snoring roommates and obnoxiously glowing MacBook Pros is the same: get out of bed and smother it in a pillow.

What we need is a digital remedy, today’s idea to steal:

• Or, provide a preference to stop the throbbing glow
• Or, employ an ambient light sensor on the outside of the device to smartly control the throbbing glow.  By daylight, throb away.  When the room is dark, don’t.
• And while you’re at it, also dim the charging light when the room is dark. It, too, must be covered to keep the room dark enough for the laptop’s very young roommate.
• Or, just stop throbbing

As for snoring roommates, I’m unaware of a digital remedy.  Anyone?

Front Row, Spaces, Exposé, Dashboard, Time Machine, Stacks and the iApps have continually expanded the basic rules by which the graphical user experience operates,  making it harder to predict, harder to learn, and unnecessarily complex. No new Mac feature appears without another surprising jack-in-the-box animation or mind-bending world-within-a-world paradigm shift.

This is not so bad for people who have been continually using Macs every step along the way since 1984 (like Steve Jobs, or me).  But it’s an increasing challenge for the new user, the less technically savvy, and the switcher.

Features that are bolted on violate two of my top principles of user experience architecture:

1. Minimize the bag of things the user needs to learn. Do not add things to the bag lightly.  Try and find something to remove from it.  [Consistency, by the way, is a sub-case of this rule.]
2. When adding features, blend them in, don’t bolt them on. Each bolted-on UI adds to the bag and diminishes the coherence, elegance and simplicity of the whole.

With all those trademarked features and their funky UI’s, Mac OS’s bag of things to learn is becoming positively santaclausian.

This is not a push for UI conservatism.  It’s wonderful that Apple continually challenges and improves past conventions.  But please, don’t leave us with seven different conventions in one package, which is where we are today.

As software ages, the fun and important architectural challenge — and a real test of a designer’s ability — is to work out how to blend new features in, rather than just bolting them on. We have to ask, “If the system had these features from the beginning, how would it have been designed?”  The user shouldn’t be able to tell where one era’s design team left and another one picked up.

Blending Alt-Tab behavior into the Dock

Take, for example, the Alt-Tabbing UI to switch apps, which was (rightfully) stolen from Windows for inclusion in Mac OS X.

We already had a way of switching apps: clicking on icons in the dock.  But it required reaching for the mouse.  Alt-tabbing provided a way switch apps without moving one’s hands from the keyboard.  Here is how it has looked for several years:

Here, with the Dock and the Alt-Tab UI visible, we see two ways of displaying open apps, and two ways of switching between them.  They are shown in different places, in different ways with different rules.

The Alt-Tab UI sorts its icons unpredictably.  (The order mirrors the Z-order of open windows, a deck that is shuffled as you switch windows.)  The user cannot develop a spatial memory of what is where because they keep shuffling around. And the location of items in the Dock has no bearing on the order in which the same icons are presented in the alt-tab UI.

The interaction design challenge is: rather than bolting on the Alt-Tab UI, could the functionality be blended with the existing Dock without diminishing the effectiveness of either?  Here is an approach I’ve been sitting on for a while:

Before the alt-tab:  Dock appears as usual

When the user keys down on Alt-Tab, the Dock icons of the open apps stand apart from the others.  Here is a quick & dirty mockup of one way to do that:

During Alt-tab (alternative 1): active apps jump forward; inactive apps which aren’t part of the alt-tab cycle are suppressed

Alternative 2

In this variant, the icons jump out of the dock into the familiar Alt-Tab UI.  Suppressing the inactive Dock icons lets the user visually estimate how many key presses are needed.  The most recent app is the first one to be highlighted, preserving the ability to toggle between the two recently used apps with one keystroke.  Subsequent Alt-Tabs walk through successive open apps, in the usual order they appear in the Dock.

Here is a variant that is even more naturally blended in with the Dock:

During Alt-tab (alternative 2): inactive apps are dimmed back; alt-tab grows the current selection

In this alternative, the inactive apps are dimmed back, and the current selection grows.  This borrows the Dock’s pre-existing magnification feature.  It’s even more seamlessly blended with the Dock behavior.

Et voila, Alt-Tab functionality without having to bolt on another paradigm.  The order of the apps is stable and predictable, and leverages the user’s spatial sense of what apps are where.

The key lesson: as software ages, be wary of layering on new UI paradigms.  Take the time to study how things already work, and find ways to make the new features and old features feel like they’ve been together all along, and were designed by the same team.

See also:

• Bring related windows forward during Alt-Tab
• What is the Alt-Tab order?

—

Philip Haine is principal of Product Vision Associates, a product innovation consultancy that helps product leaders and their teams envision new, breakthrough products and reboot older ones.  To follow him on Twitter click here.

Well, I should clarify.  The current Google workflow is just fine for searches for which there is one clear, perfect hit to pursue.  One search, a bit of scanning, and one click to get to the results.

What Google is missing is that finding an answer often involves hunting through several sources.  Google could be made significantly more efficient by considering this larger workflow.

Here is the typical best-practices workflow for checking out multiple hits from Google:

1. Type in a search
2. Skim the results for hits that may be credible.
3. Control-click the links that may have the answer you are looking for into new tabs.  This could be many tabs.
4. Peruse the tabs one by one.
5. Search within the page for the results you are looking (it could take some digging).
6. Once you find the answer you are looking for, go back and close the rest of the tabs.

It’s up to the end-user, using facilities in the browser to efficiently examine multiple search engine hits.

Here is the design to steal:  Search engine results don’t require very much width.  So why not show the search results in one column and a preview of the destination page in another?  Clicking a link would still go directly to the destination page.  But there are additional clear buttons to view the destination page (or its faster, cached version) in another pane. The new workflow might look something look like this rough mockup:

Step 1. Type in a search and get search results

Step 2. Click the Cache button next to pertinent search result to instantly see the cached version.

The cached version appears much more quickly than loading the page from the destination site.

The user could also click “Show page” to fetch the latest, live version.

Step 3. If that isn’t the result you needed, click on other cached results

Here is the result after clicking “Show cached” button for a different search hit:

The page is pre-scrolled to the area that most closely matches the search and the relevant section highlighted.  This saves the user from having to work as hard to find the useful information within the results page.

Step 4. If you want to read the destination page, click into it.

If the user has found a useful page there is a clear way of going to it.  The search results would disappear and the entire browser window would show the destination page.

A further optimization

If Google had clear a sense of what the top hit would be for a given search, it would take the liberty of loading it by default, without the user having to click any links.  This effectively integrates the “I’m Feeling Lucky” functionality with the regular search results.

What is going on?

This solution is made possible by the larger screens we now have.  They are wide enough that we can see both the search results and a useful part of the destination page at once.

In this design approach the search results behave like a vertical set of tabs. You don’t have to manage your own browser tabs, which confers several benefits:  (1) You don’t have to work as hard to find the results within the destination pages.  Since Google is controlling the presentation of the results it can highlight the relevant parts nicely.  (2) You don’t have to worry about the memory drain of having many browser tabs open at once.  (3) You don’t have to clean up the tabs after you have found what you were looking for.  (4) And one click on each search result is enough to peruse its content, as opposed to one Ctrl-click to open the results in a tab, another click to go to that tab and another click to close the tab when you are done.  One click instead of 3 for each search result you visit.  If you have to check out four hits to find your answer, that’s four clicks instead of twelve.

For best results, the cache would be fast.  It must be, because it is competing with the efficient alternative of ctrl-clicking tabs and having the browser load the pages in parallel in the background.

Content owners may not be all that thrilled with a search engine employing this approach.  It encourages access to the cache rather than hitting the target site directly for the guaranteed freshest content displayed as the site owner intended.  Google might do is set up an API whereby site owners could find out how often their site is being served up from Google’s cache.  [Readers, do they do this already?]

[As usual, if you know someone who might be able to do something with this idea, please forward them this article.]

—

Philip Haine is principal of Product Vision Associates, a product innovation consultancy that helps product leaders and their teams envision new, breakthrough products and reboot older ones.  To follow him on Twitter click here.

I have messages with the typical subject line, “Checking in”.   As you can see, it’s threading messages I sent and received yesterday with messages from four and six months ago.  What’s more, there are three different sets of recipients. There is no way that this is a continuation of the same conversation.

So here’s a design to steal to improve threading:

• if the subject is the same but the recipients are different, consider it a different thread.
• If the recipients are the same, and the subject is the same, but a lot of time has passed, take a look inside the message. If there is little or no quoting of the earlier messages ( As happens when messages are replied to), then consider it a different thread.

[Readers: Is this problem present in other mail programs? Please comment.  And, as usual, if you know someone at Apple, please send them this feedback.]

Why can’t I just follow #hashtags in Twitter like they were @users?

English translation:  Twitter lets anyone toss their transient thoughts into the ether for anyone in the universe to listen in on.  This is useful if you know of people who say interesting things.  You can subscribe to such people — many of them — and then conveniently track their utterances over the course of the day.  And this can be very interesting indeed.  It is like being on the listening end of a cocktail party conversation where the other person says something that makes you pause and go, “huh!” (*) Serendipity happens several times a day, and it becomes addictive.

The problem is that you only every hear from people you already know of and to whom you have already subscribed or followed.  If someone you don’t know of says something brilliant about something you care about (say, cats or Madonna or product vision) you won’t hear about it unless you go out of your way to search for it.

To help identify the topic of their dispatches into the Ether, Twitter users have taken to appling keywords (a.k.a. tags) to them.  But Twitter doesn’t officially support keywords or tags.  So people make up their own and tack them into their 140 character Twitter message.  By convention, to identify the tag as such, they start them with the hash symbol (#) and call them hashtags.  Hashtags look like #catscomposite triple beat or #madonna or #productvision.

The problem is you cannot subscribe to hashtag traffic directly, as you subscribe to people. (You can subscribe to the RSS feed for the hashtag, which means going use another program.  The benefits of centralization and serendipity are lost.

So I repeat:

Um…

Why can’t I just follow #hashtags in Twitter like they were @users?

—–

*This doesn’t apply if the people you follow insist on telling you about their flight delays or what they just ingested.

I (heart) Obama, but it sucks to see him expend precious first-hundred-days political capital — and money — on this self-correcting problem.  Leaving the schedules as is would have an economic perk: it would make the remaining 6 million households to buy converters or take the opportunity to upgrade their TVs — a nice boost infusion to consumer electronics retailers.

That said, if we are going to make them switch, there is probably a better way to go about it.

But first, some key observations:

1. People tend to act reactively.  They won’t act until they sense a problem, which means further delays will not fully solve the problem.
2. Reaching everyone with traditional ads for the switchover are extremely expensive, and of limited efficacy.  (See point 1.)
3. Who says we have to change cold turkey?  Why not pull it off in stages?

Here is the design to steal:  Give stragglers increasingly bitter tastes of what will happen if they don’t switch.   Disable analog broadcast of regular programming, showing instead a 10-minute public-service infomercial loop on all analog channels, with a phone number and website for more information.

The five week schedule might look like this:

• Warning shot:  Disable analog broadcasts for one hour next week during a low viewing period, say Monday 8-9 am. This will make headlines and get people talking.  Publish the schedule of analog brown-outs that every newscaster across the country will read.
• Give people a week to switch, then fire the second warning shot:  Disable analog for 3 hours on a Saturday morning with the same message on how to transition.
• Third warning shot a week later: Disable analog for 4 hours on a Sunday evening.
• Fourth warning shot: Disable analog from 6-11 on a Monday night.
• Fifth warning shot: Disable analog from 6-11 on a Thursday night.

Here is an even bolder approach:

• Designate a Thursdays as no analog programming day.  Every week, turn off analog broadcasts for the whole day.

Two other refinements to the idea:

• In additional to the tough love, station owners could sell advertising between replays of the public-service infomercial, but only to advertisers providing products and services involved in the transition.
• If there is a local or national emergency, stations would be allowed to start re-broadcasting in analog for the public safety.

Of course this will be painful for viewers and advertisers.  But it will be way less painful than the cold-turkey approach.

It’s natural for us to have such partitions.  Our identities are different when we are dealing with our parents, our close friends, our colleagues, our students.  It’s natural and there’s nothing wrong with it.  We need to be able to tell fart jokes to your old high school buddy one moment, be silly with our children the next, then act professional at a meeting with senior management.

This is precisely the protocol that Facebook violates, by having all “friends” be on the same plane, be they friends, parents, work colleagues or nieces.

On the one hand this is a good thing.  It makes us all chillax a bit about the various pretensions we uphold in the spheres of our life.

On the other hand, it’s a bad thing. because despite the Facebook culture, most of us do still have that need to keep our worlds from colliding.  The stories of people who inadvertently made fools of themselves at work for what they did over the weekend are legend. And sometimes, you want to share something silly with one group, that your parents, or your kids, or your employer just should not see.  Without control over who gets to see information you post, prudent people must keep their edgy side under wraps.  Controversial topics that might  offend people whom you don’t want to hurt must go unspoken.

So here is the design to steal for Facebook: allow us to define spheres of friends and place each friend in one more more sphere.  When we post something, give us the option of limiting who gets to see it: everybody, or just certain spheres.

This same facility could be used for special interest sub-groups among your friends.  You could have a sphere for your college classmates, your high school classmates, your club, and so on, and post statuses or pictures that only they would see.

Allowing spheres would open up all kinds of new usage patterns and prevent users from having to water down the information they broadcast.  Go to it, Facebook!

There is no immediate visual cue that lets you scan for the project folder you want; you have to click through each and see its title and what’s in it.  The problem is exacerbated with today’s huge monitors, because you can have so many more windows open at once.  Exposé kindly splays them out for examination, but it’s still work to go through them.

This is an example of when consistency can go wrong (and why consistency does not equal usability).  In this case, too much consistency among Finder windows has suppressed important information, namely what is what.

The solution is pretty clear: find a user-definable way to customize the look of a window as it appears in the Finder.  There are many possible ways to do this.  One (fairly boring) way is to let the user change the color of the striping.

In the above example, the two greenish windows are really for the same project.  (You probably did not notice this in the first screenshot.) The front most is another, and the purple one sticking out the side is another.

Readers, what other methods of distinguishing a bunch of Finder windows might work?  Change the chrome color?  Apple already lets you set background images to folders, but only in icon mode (and when is icon mode used, except for software installers?).  Might a big, scalable background image work?

One of the things I criticized was how many steps it takes just to navigate to the calendar in order to check, tweak, or add an appointment.  On the iPhone it ranges from 3 to 7 steps, with some of those being heavyweight steps that pull eyes and your attention of other things.  On the ancient PalmPilot and its newer descendants, it is one button press.  Extremely frequent task was rightfully given top-tier treatment, with a physical button on the device.

But Apple isn’t really into buttons. (Nor are they into acknowledging that the iPhone is really more of a PDA than it is a phone.)

Can we have our cake and eat it too?  Can we have direct access to key tasks while also accommodating Apple’s pathological aversion to real buttons?  Buttons that you can actually find without looking at the device, which are always available, regardless of the mode you are in, and which have the gratifying haptic feedback of… clicking?

Here’s one way: from the iPhone’s “slide to unlock” screen (or even from standby mode) let the user jump directly to an app by drawing a gesture.  C for calendar, M for mail, F for facebook.  It would be configurable.

Gestures could go deeper than just launching apps and get you to most used tasks.  Draw an A to create a new appointment.  Draw a T to go to today.  Each apps could publish its candidates for direct-access tasks, and the user could assign them to gestures.

Here’s an even better way to give immediate access to key tasks without buttons: make voice recognition the main way to get to most frequent tasks.  Press a physical “listen to me” button and say, “Go to today” or “new appointment for next Thursday at 5:30 pm” or “Call Leslie” or “new contact” or “Address book find Edwin” or “Facebook” or “Yelp nearby sushi” or “Montreal weather” or “Apple stock price”.  These were scenarios I painted several years ago.  Now they are starting to take shape at Google and with iPhone add-ons like Say Who (which actually works well) and Say Where (which doesn’t work as well yet).

A good implementation of voice command would suddenly make all that iPhone goodness a heck of a lot more efficient.  It could be a key part of an iPhone-neutralizing device.

They did do something subtle and brilliant, though. I’ve been moaning for decades about the absence of a proper second mouse button on Apple’s computers. With the new MacBooks, Apple found a way to add a second button without desecrating the precious industrial design. The track pad itself is a real, physical, press-it-and-it-clicks button. Press it with one finger and it’s a regular click. Press with two fingers for the right-click operations.  (There’s a chance that there will be a lot of false right clicks, if the user fails to assiduously lift all other fingers before clicking. Something to look out for.)

Another great side effect of combining the mouse button with a multi-touch panel is that it greatly simplifies clicking and dragging when using a trackpad.  Before, this was a two-handed operation, one hand pressing and holding the button, and the other one doing the drag.   Now, the user can press and drag with one finger.  It’s more direct, and it neutralizes one of the advantages of an external mouse, which had this capability ever since Englebart’s day.

Combining the mouse button with a multi-touch panel has other potential.  Double-clicking, still difficult for many users, can go away: instead, click with three fingers. Triple clicking was always pretty ridiculous, but the equivalent, click with four fingers, is more tolerable.  You can zoom, pan, change the volume, scrub a video, by pressing with multiple fingers and dragging horizontally, vertically or diagonally.  These are my off-the-cuff thoughts, not what’s been announced.  Apple says:

The amazing new trackpad doubles as a button — just press down anywhere and consider it clicked. No separate button means there’s 39 percent more room for your fingers to move on the silky glass surface. Now that Multi-Touch gestures have come to MacBook, all the function is in your fingers. Use two fingers to scroll up and down a page. Pinch to zoom in and out. Swipe with three fingers to flip through your photo libraries. Rotate to adjust an image with your fingertips. Using the new four-finger swipe gesture, swipe up or down to access Exposé modes and left or right to switch between open applications. If you’re coming from a right-click world, you can right-click with two fingers or configure a right-click area on the trackpad. The more you use the Multi-Touch trackpad, the more you’ll wonder what you ever did without it.

(By the way, is it possible to use a stylus with the conductive glass touchpad?)

There’s only one little issue.  Most of us use our laptops on a desk, right?  And most of the time when working at a desk a mouse is still preferable, right?   So all this track pad goodness is only an occasional benefit, until the future mouse is invented. [Update 10/21/09 The future mouse has been invented.]

See also

• Panning & scrolling with a mouse by tilting
• The irony of Apple’s Magic Mouse

In advance, I thought I would throw out some possibilities of how a great leap forward might look.

The entire computer is in the display portion of the laptop. Is detachable from the keyboard section.  The tablet functions as a stand-alone tablet computer for mobile use: an iPhone, but bigger.  The tablet weighs less than the MacBook Air. It has the same capacitive touchscreen as the iPhone, and a similar on-screen keyboard when needed. It is transported with a protective shell/cover (which is also a keyboard).  The tablet operates in landscape or portrait mode. A stylus is tucked away for sketching and painting.  The tablet section can be plugged in for power.

For desk use, there is a “kickstand” built in to the back of the tablet, possibly hinging open in both portrait or landscape (Apple is more likely to commit to just one, landscape).  Mouse and keyboard operate via Bluetooth. There is only one wire involved, the power cable to the tablet.  To use it on your desk, you just have to stand it up, plug it in for power and start typing and mousing.

(Sooner or later we will have wireless connections to displays. In this scenario, you can come to your desk, stand the tablet up and plug in or dock it, and then start computing away on your 30 inch monitor, keyboard, and mouse.)

For heavy duty computing, the tablet can be docked to the keyboard section at the hinge.  The keyboard section resembles the bottom of traditional laptop.  It includes a complement of ports for desktop use. The keyboard section also includes a second battery to extend the charge, and to cantilever the top-heavy display.   (Hopefully this would mean that the keyboard section could support the weight of the display, for airplane use.)  The two sections close like a regular laptop.

In an alternate embodiment, the keyboard section is thin and lightweight, and serves as a cover to the tablet for transport.  The tablet has minimum traditional ports, but it does have a fat docking connector.  For desktop use, the tablet is is docked into a hinged stand that provides power and a communication bus.  Peripheral ports are on the dock. The docs may or may not include the keyboard and touchpad.

The tablet portion may alternately be laid flat to use as a graphics tablet with a display behind it.  Great for designers or artists.

I don’t know if the mechanical or technological challenges of this approach are yet achievable, but let’s see what tomorrow brings, shall we?

1. Directly rename a document from the titlebar

You just realized that the document you are working on is really about something else.  The original title was wrong, and now you need to rename it.  Go.

In the old days (ie. today), you had to locate the document in the Finder and rename it there.  It’s a good idea to close the document first, because some apps complain when you move or rename them while open.  So you locate the original document, close it back in the source app, rename it in the Finder, then re-open it.  It’s about seven steps including all the switching between the Finder and the app.  What a drag!

Here’s a new way:

1. Activate the titlebar (click & pause or double-click it)

2. It lighlights

3. Rename it

3. Click elsewhere to deselect and commit the change

Ahhh.  That’s better.

2. Move a document by dragging its mini-icon

The Mac OS is nice enough to let me drag a mini-icon of a saved document from its titlebar.  Press and hold on the little icon, then start dragging to create an alias.  To make a copy instead of an alias. press shift or Cmd or Option (I STILL have to experiment) to get a “+” sign.

Today, you can make an alias (left) or a copy (right) by dragging from the titlebar icon

However, say you had quickly saved the file in some random place just to save it.  You were in a rush, or you didn’t want to lose your train of thought, or you were trying to quit the app, or you weren’t sure where to put it.  But now it’s time to put it in the right spot.  You will have to forget that dragging goodness; you need to dig out the document in the Finder and drag the icon to its new home the old fashioned way.

Two observations: First, why shouldn’t you be able to move a document using its titlebar mini-icon?  Second, those modifier keys have been with us since the 80′s.  They’re hard to discover and remember and a pain for the throngs of PC migrants to learn.  How about a more overt UI?

How about this: provide an in-place menu at the destination of the drag, with options to copy, move, or make an alias:

1. Drag out from the titlebar, possibly with a modifier key or using the right mouse button.

2. Select what you would like to do with the explicit menu

This menu could be pie menu or a regular vertical menu.  It could open with a modifier key or when dragging with the right mouse button (a good idea that is in Windows).  Either way, it would permit moving and would be easier to learn.

3. Allow saving of untitled documents by dragging the icons.

Curiously, untitled documents don’t have a titlebar icon to drag:

Unsaved documents don't have a mini-icon

This is surprising since this is when I need it the most.  I have my project folder open, I have my document folder open.  I need to put the document into the folder.  Alas, no dragging allowed. I have to go through the darned File/Save dialog even though the objects I need are right in front of me.

Why not put the mini-icon in the title bar as usual, let the user drag it to the Finder, and prompt for its name?  It would be a lot faster and more direct.

You could even tie this in with Exposé, to minimize the amount of advance window shuffling required:  Start dragging, then invoke Exposé to splay out the Finder windows, then drop into the appropriate Finder window. Provide a name, and you’re done.  Much faster than futzing with that File/Save dialog.

4. Make the File->Save dialog Finder-aware

I haven’t tried to work out the exact rules, but all I know is that when I want to save an unsaved document, or when I want to do a Save As of an existing document, the File->Save dialog rarely guesses the right folder to save to.

Can we make the File->Save dialog a bit smarter?

• When doing a Save As, default to the folder of the original file.
• When doing a Save for the first time, default to the frontmost Finder window.

(I know there are utilities to help with them but last I checked they were quirky, ugly, and excessive.)

Saving files is an old and fundamental GUI problem, but we can still teach the dog some new tricks.

If you know someone who can do something about these, please pass this link along.  The permanent link for this post is: http://stealthisidea.com/articles/gui-titlebar-tweaks

Related posts:

• Bring related windows forward during Alt-Tab
• Making efficient use of big displays

—–

Philip Haine is a product vision specialist and interactive product designer.  He founded Obvious Design, LLC in San Francisco in 1997.

With the iPod Shuffle the point is moot because the device is mute. There is no display at all, so you must navigate across and within songs by trial-and-error. Playlists are precluded from the device because there is no good way to navigate them. This makes it hard to use the same Shuffle for different situations. If you don’t have one, believe me, stepping through tracks on a Shuffle is a real pain.

You already have the earphones in.  Why shouldn’t the iPod use them to speak with you?  Here are some details of how it could work.

The design to steal is for the music player to use the headphones to give you information to tell you information and enhance its usability. What might the iPod whisper into your ear?

• a “rising” sound effect for next track and corresponding “falling” sound for previous track
• better yet: verbal announcement of the track number as you skip forward and back: “Track four. (press forward) Five. (press forward) Six. (press back) Five.” This would help you know where you are on the disorienting Shuffle.
• bips for every 10 seconds you are fast forwarding, because it’s really hard to know where you are without looking when fast forwarding a digital player
• Better yet: verbal feedback to how far you are fast forwarding or rewinding in rising increments as you hold the button down: “(blah blah) bip (blah blah) bip (blah blah) ten seconds, twenty seconds, forty seconds, 60 seconds, 90 seconds”
• For shuffles, pre-render text-to-speech of the tracks on the desktop before syncing to the device. The device would declare the names of the songs as you skip around: “Alicia Keys track three superwoman. (forward) four: no one. (forward) five: Like You’ll Never See Me Again.”
• To bring badly needed playlists to the shuffle: “(press Up button) Playlist one: running mix. (press next) two: ted talks (press select) Track eight: Jeff Hawkins (track then plays)”

(I deliberately omitted sound effects for changes of volume level, which would interfere with enjoying the audio.)

Music players (including cellphones) have direct line to the user’s ear. Why not make use of that for useful UI information?
—–
(Readers: Does the Zune or any other music player reinforce the user interface with sounds?)

Dedicated buttons for expressing your pleasure with the current song, or lack thereof

Music is so easy to come by these days. We should be in sonic bliss, right? But we aren’t, because so much of what we have on our music players is, well, crap. Our shuffled music is a mix of stuff we love and stuff we don’t. Not so pleasant.

Our goal is not just to get piles of music, it’s to have piles of music that we love. We want our music collection to have a high signal-to-noise ratio.

The iPod has a clever function to let you rank a song you hear. If a bad song comes on, you can rank it as one star and delete it from you collection when you get back to your computer.

The trouble is, it’s way too much trouble to do this. On a typical iPods it’s a multistep, multi-sensory operation: 1. Unlock the buttons 2. press the select button repeatedly while watching the device until you are in the rating mode (not the volume mode, not the progress bar mode, not the album cover mode) 3. turn the clickwheel while watching the screen to get the right number of stars 4. Click select to confirm 5. re-lock your buttons. Then, later, you need to do the cleanup chore: return to iTunes, search for your one-star songs and destroy them.

Not only is this a lot of work, it’s also completely non-viable if you are driving, running, or doing anything else that occupies your eyes or attention. The net result is you don’t. You must endure the bad music until the next time you are able to take a few hours out to hone your music collection, which is to say, forever.

Here’s the design to steal for a modern music device: real, tactile, mode-less Thumbs-Up and Thumbs-Down buttons on the surface of the music player. (Not the typical Apple non-button button.) (Thank you Pandora for the thumbs up/down inspiration). Pressing the thumbs affects the song’s star rating, and thus their likelihood of it being selected by the elven DJ within the machine.

Here’s the fun part: Pressing and holding the Thumbs-down button banishes the song from your ears permanently (after a second confirmation press). No further interaction needed. You can do it while running or driving or conversing. It’s gone from your portable player and after syncing, it’s gone from your desktop.

This gets even more interesting with subscription music services fed to portable music players, which let you listen to as much as you want as long as you keep paying. The system feeds you songs you might like. You gong the songs you hate by pressing and holding the thumbs-down button. The next song begins right away. The banished song is kept on a do-not-play list forevermore.

Music subscription services sometimes let you capture and keep songs you like. With this design you would do the opposite: press and hold the Thumbs Up button to keep the song locally for access anytime.

Thumbs Up/Down buttons should also appear on your home audio remote control, for the same reasons.

There are a couple of other bonus ideas to steal. Now that rating information is facilitated, the information can be shared:

• with artists and advertisers, so they know whom to reward for appreciated songs
• with your friends, so you can see who likes what (if you are into that sort of thing)
• with the whole world, to do your part in sorting through the gobs of indy music being produced. Later, those elven DJs in the machine can feed you the best indy music as rated by the collective.

Very quickly, the signal:noise ratio of your music collection would go up, increasing our enjoyment of music and minimizing the hassle of managing it. Which is nice, because life is too short to listen to bad music.

[Update 1/18/09: the Slacker G2 player, introduced 8 months after this article was published, has "Heart" and "Ban" buttons for tuning its 1-to-1 streaming audio service.]

We’re so lucky. We have cellphones and GPS, cheap high speed Internet, free shipping and Wiis. I’m grateful, I really am. The progress has been astounding.

But there are some perennial UI issues in everyday products that year after year never seem to get fixed. Every year I expect someone will finally do something but year after year ticks by and nothing happens. Perhaps if I wish real hard out loud here on StealThisIdea some of these these problems will finally be resolved.

Here is my wishlist for 2008:

1. Awesome speech recognition on MacSpeech recognition works and it’s here to stay. It is one of the few remaining advantages that Windows has over the Mac. Unfortunately the Mac has been second-class citizen for years. It’s only worth using the best speech recognition system available, and that system is Dragon NaturallySpeaking, available for Windows only. Apple, buy Nuance, willya?[1/27/08 It's working already! Within days of writing a draft of this article, MacSpeech announced they have ported the Dragon NaturallySpeaking engine to the Mac with a product called Dictate! I can't wait. I currently use NaturallySpeaking on WinXP within Parallels on a MacBook Pro, channeling input to the Mac side of my Mac using TightVNC on the Windows side and Vine Server 2.2 on the Mac side. It works really well, and I depend on it. But it's memory-intensive and cumbersome. A Mac-native solution will be most welcome.]
2. Put a real second mouse button on MacsIn the mid-80s, I used a three button mouse on Sun workstations. It was a scourge of usability. There was no standardization of which button should do what. The user was left to flounder, learning and relearning button definitions across applications.In that climate, it was refreshing for Apple to pronounce, “let there be but one button.” One button, no ambiguity. If you wanted a second action you could double click. Advanced users could Option-click or Shift-click. (Or Shift-Option-click. Usable indeed!)

   Later, Microsoft introduced a second button, But they were careful to declare a clear and unwavering mandate: “Let there be a second mouse button, and let it be used only for contextual menus.” It has been an unqualified success. Every app uses it. Even your proverbial mom knows how to right-click to get options on things. Even on the Mac, support for second mouse button is ingrained in every serious app.

   Apple seems to agree: Mac OS X, the iLife and iWork apps fully support the second mouse button.

   The only thing missing is an actual second button on Apple mice and laptop trackpads. It’s as if Steve Jobs himself is petulantly holding out on his 20-year-old pronouncement out of sheer stubbornness. The only Apple-branded bone we’ve been tossed is an invisible, barely functioning fake second mouse button on the Mighty Mouse that requires that you lift your fingers off the left part of the mouse in order for it to register a right button click.

   A third-party mouse with a proper second button therefore remains a required purchase with any Mac. Laptop users are still out of luck. It is a point of confusion and an ongoing barrier for Windows users who would otherwise switch to the mac.

   Apple is a well-known button hata and we hope it gets over it in 2008.

   [1/27/08 The signs on this one are not good; Apple looks like it's going to use multitouch trackpad gestures to get around having to desecrate its laptops with a second physical button. Maybe that will work, but I'm skeptical, based on bad experience with gestures on Powerbooks]

3. Put a real, physical keyboard on the iPhoneWe are evolved to sense things by touch, not just by sight. Tactile, haptic user interfaces make use of that faculty.On-screen keyboards require much more user attention than physical keyboard. The user must look not just at the text field but at the keyboard. The user cannot trust that a keypress will be interpreted correctly like a real button and must therefore verify what has been entered. It’s a “type->verify->proceed” mental loop instead of a more efficient “type->proceed” loop you use when you can unequivocally trust that a key press gave you what you expected. Finally, keyboards with real buttons you can feel are easier, faster, and more gratifying to use. Apple, please get over the buttonphobia. Stop trying to be clever with the workarounds and put a proper keyboard on the next iPhone.

   [Update 4/24/09 - Apple has said "emphatically" that it does not believe in fixed keypads for phones.  This either means that they aren't going to do it, or they aren't yet ready to show their fixed keypad for the iPhone.]

4. Put physical playback and volume controls on music devicesThere are very few universally-applicable UI principles. Almost all have contingencies and caveats. The only safe answer you can give to a general UI questions is, “It Depends.”But there is a solid, generally applicable principle that you could teach a monkey: identify and streamline the most common and frequent tasks.

   My first Sony Walkman cassette player got this right in 1979: I could adjust the volume and pause the music instantly, without looking, without changing modes, without unlocking anything, without even removing it from a belt clip. Yet most iPods are horribly modal. Turning down the volume on my current iPod requires pulling it out of the pocket, unlocking it, looking at it, turning the click wheel, locking it again and putting it back in my pocket. As I have pointed out, this makes the iPod touch flawed as a music player. So please, Apple, in 2008, put the volume and playback controls physical, pressable buttons that you can feel.

5. Stop the bouncingOn the Mac, icons of applications which require your attention bounce. And bounce. And bounce. Even if you’re in the middle of something else. They clamor for your attention like a needy child. Instead, icons should bounce once or twice and then stop. If they still require your attention, they may step forward from the dock, peeking out a little bit until a moment befitting the user.
6. Cars should stop self-destructingHow many products can you name, that you rely on for your life that self-destruct when the user makes a minor error? This is what happens when you accidently walk away from most cars with the dome light or headlights on. The car will dutifully shine that light all night long until your battery is dead and the car is no longer operable, leaving you stranded.In 2008, at this point in human history, all cars should be smart enough to know never to allow the battery level to get below what is needed to start and recharge itself. This should be a national safety requirement.
7. Allow graphics to be copied and pasted into web forms; allow files to be dragged inBlogging apps, SaaS apps like Google Docs, any webform requring a photo: all of these require that you provide files. Unfortunately you cannot interact with a web browser as you can with regular apps and the desktop. You cannot copy and paste images one application into a web app. And you cannot drag one or a dozen files from the desktop into an upload area. Users must contend with a cumbersome file open dialog, and do so repeatedly to upload multiple files. These facilities are needed now to upload images in many web apps, and they will be needed for evermore in RIAs and SaaS apps.  [Update 11/9/09 I was extremely surprised to discover that dragging a photo from my desktop into a Google Wave pane accepted the upload elegantly.  How'd they do that?!  Turns out it was Google Gears at work, the offline extension that was created to let you work with your web apps when you had no connectivity.]
8. Cell phone service with the clarity of VoIP and the low latency of landlinesCell phone service sucks. It has always sucked and so we take for granted its suckitude. But it doesn’t have to suck. There are two key problems: latency and audio quality. Latency is the delay from when you say something to when your friend hears it. You can get a sense of how bad it is by having both parties clap on the count of three. Latency affects cellphone service and VoIP and makes for awkward conversations. Either you work out a telegraphic protocol with clear, unnatural pauses to clear the air, or you talk over one another clumsily. Latency doesn’t have to suck so badly: it is negligible on old fashioned landline service, so it should be possible with cellphone communications.The other problem is audio quality of phone calls. You don’t know what you have been missing all along until you participate in a VoIP call using headphones. The other person sounds like they are right next to you. Puhs, buhs and duhs are clearly distinguishable, as are v’s and f’s. It’s wonderful. This is a mere matter of bandwidth and it should be solvable, not just for mobile phones but for landline phones as well.  [Update 11/9/09 As of September 2009, "France Télécom has become the first mobile operator to transmit voice calls and audio in high definition, part of an effort by telecommunications companies to improve the quality of cellphone conversations."  h/t Steve Portigal]

   How many more years must pass before we have clear, instant, reliable voice communications? I hereby wish for someone to do something about it in 2008. We have HDTV; the time is ripe for HD phone service.

9. Bring back OpenDoc

OpenDoc was killed ten years ago, but the idea of mixing and matching components of applications has always made sense. I want to be able to put an OmniGraffle chart in a Pages document or a Numbers table in Stone Create. PenPoint did it pretty well in 1991, Microsoft botched it (with OLE), integrated apps like ClarisWorks approximated it, and some ISVs have been pushing the ball forward with LinkBack. But it is still not yet a robust, well supported standard. In 2008 I wish a proper standard and a workable cross-platform technology would emerge for embedding components of apps in other apps.

10. Make it impossible to leave an ATM without your card and your cash.My Washington Mutual ATM seems designed to want you to leave your card behind: after it gives you your money, but before it gives you your card, it throws up a full screen ad for several seconds. You’ve got your money, the message it’s sending you is that your transaction is over. You start walking away, and if you’re lucky, you realize that you don’t yet have your card. I saved myself several times but one day it happened to me and I left without my card. When I returned to the bank later the teller told me that this happens several times a week.It’s not terribly difficult UI design problem, and it’s amazing that it persists after twenty years of ATMs. The solution is to withhold all three items, card, cash and receipt, until all three are ready, and spit them all out at once. The best design I saw was years ago in Tokyo, where the three slots where together and you could grab all elements at once. Please, everyone who works at a bank: in 2008, make it impossible to leave without your card.

That concludes my top 10 UI wish list for 2008. Let’s check in again next year to see what has been fixed.

[Readers: if you know anyone involved with any of these products, please send them a link to this article. It's: http://stealthisidea.com/articles/2008-ui-wishes]

BART, the San Francisco Bay Area Rapid Transit system

I had trouble with the BART (San Francisco Bay Area Rapid Transit) mobile phone user interface for checking out schedules, so I sent them the following email.

The improvements are just good old-fashioned information design and matching the solution to the situation. I thought I’d share it here since it shows a bit of design thinking.

May I make a couple of suggestions as a product design consultant about improving to the usefulness and usability of the QuickPlanner?

This goes for both the web and mobile versions of the QuickPlanner.

Have a notion of “today” and let the user bookmark routes results page. For example a common route I take is from 24th & Mission to Lake Merrit. 80% of the time I am planning this for today. But every time I want to check the BART schedule I have to interact with the pop-ups. This is cumbersome and slow, especially on a mobile phone.

Here are details.

1. On the QuickPlanner form page, provide a radio choice for “today” vs. “another day”.
2. Default the choice to “today”. (On the regular web version of the QuickPlanner you could hide or disable the date & time controls until the user chooses “Another day”)
3. When “today” is selected, on the results page show all the remaining trains for that route today, no matter what the date is.This page is bookmarkable and always brings up the schedule for the rest of today, no matter what day it is. Most of the time this is all the user will ever need.This would greatly reduces the amount of steps needed. The user no longer has to operate two long drop-downs, doesn’t have to review the date and time and press submit.
4. On the results page, make it easy to skim the results by boldfacing key information and factoring out redundant information.
   - For a direct journey with no transfers the results would reflect today’s date, the start and destination stations just once, at the top of the results page (rather than with each hit) and the fee.

   - To make it easier for the user to zero in on the key information, make the operative information boldface Each result might start with the boldface header: “Depart 11:19 am Arrive 11:40 am”. Under that are the details of the journey and whether “Bikes are allowed” or “Bikes NOT allowed” (to make it stand out a bit more, but not too much).

   - For journeys involving transfers, the cyclist only needs to know once whether the entire journey allows bikes. (We save clutter and reduce errors by saying it once for the journey and not for each train.)

5. At the bottom of the results page, put a note in suggesting: “We suggest you bookmark this page for faster access”. This line would only makes sense when the user has chosen “today” since specific dates would not be very useful to bookmark.
6. The notion of “today” would be common-sense enough to go over midnight barriers. If it’s 11:30 pm, the user wants to see trains past midnight, not strictly today.
7. Rather than paging after a handful of results. I suggest erring on the side of longer pages with more results. It’s slow to initiate and transfer data on a mobile phone; faster to just get it in one fell swoop and scroll through a longer listing.
8. An instant bookmark to today’s schedule is handy, but sometimes the user does need to look ahead. At the top of the results page next to the date there is a “change” link. This goes to the QuickPlanner page. The start and end stations are pre-set, saving the user the chore.

Please compare this before and after mock-up of an itinerary involving a transfer:
Before: http://tinyurl.com/2upzjg
After: http://tinyurl.com/2pwrxo
You can try these URLs on a mobile phone.

Hopefully this would not be too difficult a change. Please let me know if I can help further.

Thanks and best regards,
Philip Haine
Obvious Design
phaine@obviousdesign.com

Here is roughly what the before and after look like:

Before and after of BART QuickPlanner search results page

To get a more accurate picture of the differences, browse the before and after links above on a mobile phone.

Hopefully BART can implement bookmarkability and these improvements to the information design. I’ll let you know what they say…

This immediately leads to a quick idea to steal: Give the option of saving and restoring all content when the browser is re-opened.

This scenario hints at something larger, an observation that browser makers seem to have missed: The pile of tabs can be thought of as a reading list. What if web browsers let you create reading lists, like music playlists in iTunes, but for web pages? You could drag the current page or a tabs into a reading list to read later, or to save it forever. You might have a reading list for sports, one for humor, one for macrame.

This concept is different from web bookmarks: it is the content that is stored locally, not just the page’s location. The benefits are convenience, speed, permanence and searchability.

You could have multiple reading lists, just as there are multiple play lists in iTunes.

Reading lists are designed for transience. Once a page is read, it is discarded, to keep the focus on unread material. This differs from typical bookmark managers, which typically make you switch to a bookmark management mode to clean up bookmarks.

Sometimes there are pages you want to keep forever as reference or for a historical record. There is no guarantee that the company serving the page will still be in business ten years from now, with the article still available for free and at the same location you bookmarked. The New York Times, for one, expires its articles pretty quickly. The user has the option of storing pages indefinitely, as a permanent archive.

Academic or scientific researchers, reporters and students would use this to collect read articles over time the way a reporter collects boxes of newspaper clippings.

The saved content within reading lists would be indexed and searchable from within the browser, making it easier to recall a useful article from the past.

Reading lists would help with mobility. Before traveling you could load up on readings for future offline browsing on an airplane, or anywhere else the Internet don’t shine. This is better than leaving your browser open with a lot of tabs — a running browser trickles off some CPU load and therefore battery life.

Engadget or SlashDot are examples of pages that have the useful content on the home page. You rarely have to drill in further. While pages in the reading list are normally static, for this scenario, the user might designate a page as automatically refreshed. They would update automatically in the background and thus be instantly available when called upon. Their freshness level would be clearly indicated so you always have a sense of how old the material is. In the airplane scenario, pre-caching would save you from having to remember to load up on content beforehand and to spend frantic packing time doing so.

The latest RSS feeds would be available instantly and automatically, even when offline.

Pre-caching reading lists would be a boon for mobile users. Today’s iPhone, for example, has poor digital bandwidth, making surfing painful. And even the fastest wireless networks aren’t available everywhere, such as in a subway tube or in a different geography. Reading lists would work with mobile devices in a couple of ways. First, reading lists you line up on your desktop would be kept in constant sync with the handheld. Stuff you didn’t have time to read at your desk is therefore available to you on the train or in the waiting room.

Secondly, the mobile device could load up piles of subscribed web pages, RSS feeds and video snippets while charging, so it doesn’t incur a hit to battery life. If the device has WiFi like the iPhone, it could make use of it for faster fill-ups. Then when you have a spare moment, calling up the pre-cached pages would be instantaneous.

This new capability is not much of a technical stretch over what browsers already do. It is already possible in most browsers to save a page locally in the file system. This concept provides a more streamlined and integrated experience for saving, grouping and recalling locally stored pages.

This is one of those ideas that could have been created years ago. The last major innovation in web browsers was tabbed browsing. Hopefully, we will see browser makers incorporate an elegant design of reading lists some time soon.

[If you know someone involved in browser technology, please send them this article!]

[Update 9/7/07: OmniWeb v5 seems to have some of this functionality in a feature they call Workspaces. It seems to have much in common with this idea, but a different bent, more oriented to reconstructing configurations of tabbed window browers.]

But when, at a 2003 keynote, Steve Jobs introduced the backlit keyboard to adulatory oohs and aahs, I was in the minority, waiting impatiently for the moment to pass. The backlit keyboard looks good, but does it really solve a true need? Are there really legions of hunters and peckers hunched over their keyboards in the dark, squinting to find the letters, praying for a flashlight?

If you’re a touch typist, you keep your eyes on the screen. Does it help you that the keyboard is backlit? For non-touch typists, when you happen to be in dim lighting conditions, doesn’t the display illuminate the keyboard enough to find the key you need?

How often do you compute in the dark? The clearest scenario might be the dimmed cabin of a night-time flight. If you aren’t a touch typist a backlit keyboard would make it easier to type. Wouldn’t you just turn on the overhead light? Battery life is often the scarcest commodity, and there never seems to be enough of it. I tend to turn the screen down as far as possible to stretch it to the bitter end. Sure, a glowing keyboard might attract attention and earn me some desperately needed cool points, but it would come at a cost of frantic computing minutes.

When I got my first backlit PowerBook, my expectations were confirmed. I used it for years, hardly ever needing the backlighting. When I tried, there were issues. You see, in good lighting, the keys are dark on light. And in a dark room, the keys are supposed to be bright on dark. With in-between lighting, the keys are mid-tone on mid-tone. Yep, very low contrast. Unreadable. Imagine all the keys being like the ‘I’ and ’9′ keys in this simulation:

When the lights go down the MacBook Pro’s keyboard lights up. When lighting is in-between, contrast can be low.

At the end of the day, the cool back-lighting was just as likely to make the keys less legible than more legible. Oops. (This issue has come up before: The Palm V also went from dark-on-light with the backlight off to reverse text (light-on-dark) with backlight on. It was thus nearly impossible to read in medium ambient light.)

By the way, the newer MacBook Pros of 2006 have corrected the problem with much brighter backlighting. At full blast it will burn holes in your retinas. What this does for battery life, I cannot say.

Another issue with the first back-lit PowerBooks: the Function keys were not lit, only the QWERTY keys. As a touch-typist, I don’t need help with the QWERTYs, thank you. The QWERTYs I have had down cold since college. If I ever needed backlighting it would be on on the function keys, the ones that are less used, small, un-bumped, un-clustered keys. The ones that I sometimes have to look at the keyboard for. The Function keys, which were dark on the original Powerbooks.

So backlighting on keyboards looks very cool but isn’t all that functional, at least for touch-typists.

But it made me wonder: if we had to take backlighting as a given, is there a way to make it more functional and not just a fashion statement?

One annoyance I do run into is having an Num Lock key pressed accidentally. Pressing Num Lock turns a parallelogram of keys on the right half of the keyboard into a faux numeric keyboard. The rest of the keys are disabled. The problem is, it’s maddeningly easy to accidentally enter Num Lock mode. All you have to do is accidentally press F6 when you meant to press F5 or F7 or 6 or 7. And it can be hard to figure out why the keyboard is not responding normally.

Meanwhile, who actually uses that faux-numeric keyboard for its intended purpose? [Readers? Do you?] It’s just too hard to find the tiny secondary numbers labels, and they are in an odd shape.

What if, in Num Lock mode, we could selectively brighten the little numbers and keep the other keys black? It would look like this:

Mock-up showing numeric keys backlit in a different color when Num Lock is activated and other backlighting turned off.

This would require another channel of light, preferably in a different color. This is not an innovation that will solve global warming, just a nice, functional tweak. Perhaps more people would learn, use and benefit from the embedded numeric keyboard.

Here’s a gratuitous tweak. On the Mac, to enter an accented letter, you first type the accent with the Alt key, then you type a vowel. Between the two strokes, the keyboard is in a transient mode, waiting for you to type the right letter to go under the ¨ or the ˆ. What if, during this mode, the possible letters that could be accented were highlighted?

The keyboard could highlight context-sensitive command keys. For example, when an accent is entered, the vowels would highlight.

Okay, this is pretty gratuitous too. It’s a stretch trying to make backlighting actually functional.

Maybe the backlit keyboard could help users find special glyphs like æ and ƒ and ®. My first computer, the 128k Macintosh, had a great Key Caps desk accessory for just this purpose. (Curiously, this feature that used to be SO important that it was built into the cramped ROM of the 1984 Mac is now extremely hard to find in 2007 MacOS X. If you need it, try out the free KeyViewer utility.)

Keycaps from the 1984 Mac System 1.1 help you find alternate characters on the keyboard.

Maybe when you hold down option for a moment the keycap glyphs would emerge from the keyboards with backlighting as I describe for the numeric keys. Unfortunately, this idea is not very practical. You would need different glyphs for Alt- and Alt-Shifted keys. What’s more, the glyphs depend on the font in use. If you really wanted to pull this off, you would need something like the exorbitant Optimus keyboard.

The Optimus keyboard concept demonstrates keycaps with small color displays under each key.

I am not bullish on this keyboard as the future of computing for [regular] users. Who wants to take eyes off the display to look at the input device? There is some benefit to displays-on-keycaps for learning keyboard shortcuts, but the cost for that benefit is far too high.

[Update 9/13/07: After seeing the video for the new $28,000 Xynergi keyboard I'm a bit more bullish on the idea's potential, especially for pro users. The demo video demonstrated new scenarios for arbitrary key cap images that the Optimus did not: 1. for color coding clusters of functions 2. to reflect modes (e.g. play/pause) and 3. to reflect system status. The keyboard becomes not just an input device, but an output device as well, an extension of the display. For professional media editing and other specialized fields, it would be a welcome luxury. And maybe, when cheap enough, a luxury for the rest of us too.]

So perhaps the greatest function of the backlit keyboards is to make you look and Apple look cool.

Readers: When do you use keyboard backlighting on your Apple laptops? How important is it to you?

A design that avoids needed buttons is like a guy with poor eyesight avoiding glasses. He looks pretty cool standing there, until he starts moving and bumping into things.

The iPhone, too, looks great on a spinning pedestal. But the clumsiness of its outstanding but buttonphobic UI did not escape the reviewers at CNN:

[..] the lack of buttons requires a lot of tapping to move about the interface. For example, the Talk and End buttons are only displayed when the phone is in call mode. And since there are no dedicated Talk and End buttons, you must use a few taps to find these features. That also means you cannot just start dialing a number; you must open the dialpad first, which adds clicks to the process. The same goes for the music player: since there are no external buttons, you must call up the player interface to control your tunes. For some people, the switching back and forth may be a nonissue. But for mutlitaskers, it can grow wearisome.

(To its credit, Apple included physical volume controls to the iPhone, controls that remain absent on the iPod.)

By adding these buttons back, are we giving up too much? Would the iPhone or the iPod be what they are with another two to four buttons on the outside? Here is the industrial design challenge for Apple: find a way to give the products the buttons they need, while remaining sleek and cool. Maybe blend them into the black surface to keep the device looking stark and minimal. Maybe put little OLED displays behind them.

This also constitutes a design to steal for cellphone makers scrambling to catch up with the iPhone: add a small number of globally-available mode switching buttons for key tasks. Then, in your marketing, play up how much more efficient your user interface is than the iPhone’s.

And remember: the right pair of eyeglasses can actually make its wearer look cooler.

7/26/07 Update: Wall Street Journal has an article specifically about Steve Jobs’ animus towards buttons.

See also:

• UI Friction and Apple’s Front Row
• UI Friction

Apple’s Front Row UI

Each button press requires that you wait for the cool animation to complete. Input is ignored while that is happening. You cannot queue up several button presses, and there is no short-cut to get to the top of the menu tree. You have to press the button, watch carefully for it to finish, press again and repeat.

It’s a tedious form-kills-function design. It’s not long before the form undermines itself and becomes not cool, just irritating. The experienced user cannot get faster through time and repetition — everyone must wait.

Once again, the advice for interaction designers is: give snappy response first, animate second. Do not let the latter get in the way of the first, and especially not for frequent tasks.

More can be said about UI friction and Front Row’s strictly hierarchical, iPod-like interface. Before you can get to feature B you have to do a lot of mode management overhead work to get out of feature A. Front Row’s Menu button is essentially a Back or Escape button. There is no Home button.

How might the strict hierarchy of Front Row and the iPod be done differently? Imagine if there were not just a mode-relative Back button but a global Home button. Also imagine menu choices that were always in the same place. Operations could then be reached deterministically — with the same sequence of key presses.

Determinism is a very valuable design requirement. It allows users to learn key sequences through repetition and get faster over time. (It also lets programmable remotes work reliably since they are not dependent on the starting state of the system. Every piece of consumer electronics should accept distinct On and Off commands and not just a “toggle power” command.)

We could go a step further. Top features could be accessed directly with separate, global Music, Video, Photos and DVD. Each would always be one button press away, guaranteed. (More buttons on the remote, yes, but that is the trade-off between true simplicity and merely the appearance of simplicity.)

The original Palm Pilot was wonderfully low-friction because of this simple idea. It had independent, global buttons for calendar, contacts, to-do’s and memos.

Globally accessible buttons on the original Palm

The PalmPilot always responded to these four hardware buttons. No state the device was in could override them, no app, no dialog box, not even the state of the device being off! It even had silk-screened buttons for four other most-frequent tasks: Applications (aka Home), Menu, Calculator, and Find.

Palm’s friction-busting approach is a great design to steal for anyone wanting to improve an overly modal consumer electronic product.

See also:

• UI Friction
• Buttonphobia, UI Friction, and the iPhone
• Impressions of the iPod touch

Patent Application number 20070080945 details a mouse having a button-less pan and scroll switch. [..] the mouse would sense different hand positions and act in different ways according to how it is being held.

“In one embodiment, the first mode of operation of the mouse may be a cursor control mode and the first operations on the display screen may be cursor movements on the display screen. Additionally, the second mode of operation of the mouse may be a pan and/or scroll control mode and the second operations on the display screen may be scrolling and/or panning movements on the display screen.”

So maybe this means if you hold the mouse normally you move the mouse; if you hold it a different way — maybe close to the bottom — it scrolls and pans.

How about this alternative as a design to steal: Hold the mouse the usual way all the time, but tilt it to scroll in a given direction. Tilt left and right to scroll horizontally or tilt to the top or bottom edge to scroll vertically. The more you tilt, the faster it scrolls.

One advantage here is you wouldn’t have to lift & shift the mouse to keep scrolling down a long page. You could just tilt the mouse up at the right steepness to scroll down the page and lift again to keep scrolling. Plus, you don’t have to shift your hand to start scrolling.

I think this idea is different than the patent application. The patent seems focused on detecting the user’s grip and in having different modes of operation, interpreting the mouse motion in different ways. This idea is about adding extra sensory input to the mouse and allowing it to remain modeless.

How might this be implemented? There are probably a number of ways… Accelerometers may be tricky as regular mouse motions accelerate the mouse.  Presumably if the mouse was moving, it wouldn’t be scrolling or panning.  Alternatively, multiple distance sensors under the mouse would be able to measure the height of different edges of the mouse and from this, tilt angles can be computed.

The sensitivity would have to be done right to avoid excessive wrist twisting. A little motion should go a long way. It should be possible to lift the edges of the mouse only by lifting fingers while keeping the wrist flat. Some rebalancing of the mouse may be in order to shift the center of mass closer to the center of the mouse.

Another consideration is the case of the mouse reaching the edge during normal mouse motions. We need to reliably distinguish between tilting to scroll and tilting while shifting a mouse back into range. One possible way would be to detect mouse movement while tilted. (The sensors on the edge of the mouse would be full-fledged mouse position sensors.) Another way would be to require the angle to pass a threshold before it’s interpreted as a scroll. The user would snap an edge of the mouse up in one direction and then reduce the angle for finer control. This topic calls for some research, starting with an analysis of how mice are brought back in-range.

Alternative: Press and drag the heel to scroll

If this tilting thing is too expensive or difficult to implement an alternative design is to construe pressure on the heel of the mouse to indicate scrolling. Dragging the mouse while pressing the heel scrolls in either direction. You can think of this as another button on the heel of the mouse that just happens to be used to initiate scrolling.

It would probably be better to interpret these movements as changes in scrolling velocity rather than in absolute scrolling position, to avoid having to shift the mouse back in range. The further from the “heel down” location the mouse moves, the faster the scroll. Releasing the heel stops the scroll.

This feels pretty good on my old, lightweight Logitech mouse: it’s easy to add pressure on the ball of the hand to press the heel. Unlike the Apple patent this avoids having to shift the hand on the mouse.

[One other thought: would it be possible to add detection for yaw? Say the tip of the mouse is lifted off the desk and the mouse pivoted clockwise and counter-clockwise on its heel. Could multiple optical mouse sensors detect the direction of the twisting? Perhaps a nice research topic.]

1. Palettes that must be painstakingly re-arranged to get them off the content area (hello Photoshop and many others). When switching display configurations, the user must get all palettes placed appropriately before doing real work. We would like to see systems recognize common monitor configurations and intelligently partition a display into tool areas and content areas. When switching between, say, a laptop screen and a 24″ display, the user should be able to plug in and work without having to reconfigure the workspace.
   Vision to steal: This should be supported at the OS-level, for two main reasons: 1. For cross-app consistency, so the user can get used to finding tools at the right or left of the screen across all applications. 2. So the system can referee window positions and sizing. For example, on the Mac a maximized window knows not to extend under the Dock, so it’s scrollbar and resize handles remain accessible. See also: Making efficient use of big displays.
2. Often-clicked buttons that are too small and hence difficult to target and click (hello Fitt’s Law). Examples of this abound. In GarageBand, for example, the user must often mute and isolate audio channels, yet the buttons to do are tiny:
   

   The principle is straight-forward: if the user must click a button frequently, make it big. (Resistance may be expected from visual design quarters: tiny text and controls look cooler, especially surrounded by massive whitespace.)

3. Unnecessarily modal UIs that require you to put the system in the right state before being granted access to an important function. Try turning down a blaring iPod when it’s in its protected sleeve with the lock button on. Worse: try turning down Nine Inch Nail’s latest while you are navigating the menu structure. The very cool scroll wheel cannot be used as a volume control until you first navigate your way back to the current song. Better to just yank out those earbuds.
   Compare this against a 20-year-old Walkman: its physical volume dial can be adjusted without even having to de-holster it from your cargo pants. (The upcoming iPhone mercifully brings back physical volume buttons. Apple may have clued into this UI issue.)
4. Gratuitous up-front animation. A Windows XP user wanting to use a menu must first wait for it to fade in. This behavior has reportedly gotten 20% worse under Vista. Mac OS X is not immune: dialog boxes slide down from the titlebar with lovely acceleration and deceleration motions. The taller the dialog, the longer the slide. [Anyone know how I can hack this to make it stop?]
   Before complying with the user’s request to leave, Clippy the insolent paperclip would sarcastically wave Buh Bye. (The stupid bent wire knows that such cloying anthropomorphisms are what did him in to begin with.)

People crave and buy ever faster machines for responsiveness. Yet these up-front animations want you to chill out, take life a little slower. We’re not opposed to elegant animations, but they need to be on the tail end of the user’s operations. The simple principal is: whenever productivity matters, UI elements should snap to attention when called upon but may fade away gently once the user has moved on to something else.

The moral of the story is: when architecting systems, take a moment to isolate the most common and frequent tasks; think of the most efficient theoretical interface to these core tasks and keep comparing your design to this theoretical best. Beware of design solutions that introduce delay or overhead in these core tasks and eliminate this UI friction

Question for readers: what productivity apps have the best palette management UIs? How are Microsoft’s new tool ribbons and Adobe’s new palettes working out?

See also:

• UI Friction and Apple’s Front Row
• Buttonphobia, UI Friction, and the iPhone

What struck me was how Pythonesque the whole thing seemed. Each post began by insulting a prior user, followed by adding the writer’s alternate viewpoint. Imagine this with an upper class British accent:

User 1: “The Proposition ‘A’ is true.”

User 2: “From the stunted logic of your post, your mother clearly must have smoked throughout your gestation. ‘A’ is certainly not true.”

User 1: “Eureka! I thought the dodo extinct, yet here is one posting on this very bulletin board. ‘A’ is quite self-evidently true, as any animal evolved beyond the invertebrate knows reflexively.

It’s as though everyone was following a ritual template: insult, then comment.

Clearly, urging users to avoid flame wars is of no use. That approach has failed for decades.

Is there another way? Perhaps try and go with the flow instead?

Here’s a design to steal (or at least a research project): In message boards, provide two input fields. The first is an optional insult field. The second is the body of the message, in which nothing insulting may be uttered.

Variants to try:

• Allow readers to collapse/hide the insult field for all postings, until they are turned back on again. If they don’t like that sort of thing they never have to be exposed to it.
• Allow readers to police the postings and indicate whether the no-insult-in-the-body rule is violated. A critical mass of readers reporting a violation automatically bounces a submission back to the sender for correction.
• Allow readers to rate the quality of the insult. Give positive points to most good humored or creative or funny insults, negative points to the droll or crass.

By acknowledging peoples’ need to vent and by giving it an explicit place, could we separate out the content? Someone please try and let us know.

You then turn around and dive back into the line, swimming upstream against the frowning hoards. Everyone, including you, wonders how you could have made such a silly mistake. It turns out the utensils were at the very start of the line, at a point where your mind was preoccupied with food, not the logistics of eating it.

But you are comforted to see you are no longer alone in your salmon run: others have realized they too have forgotten their knives and sporks.

Once again, the system sets up a trap. Once again, the users blame themselves for the "error" when a better designed system would have made the error impossible.

How might the buffet line be improved?

Although part of the analog world, the buffet line as a design problem is not much different than sequential tasks done on a computer. Examples of this include placing an order on a web site or guiding the user through the initial setup of a new piece of software.

Some key considerations for such sequential problems:

• Sensitize people up-front about what to expect.
• Only provide the essentials necessary for success at each step. Don’t convolute what is needed here and now with future concerns.
• Defer non-essential options to the end.

Idea to Steal: Guidelines for Buffet Line Design

Applying such considerations to the design of a buffet line leads to the following sequence of items:

1. First, show the complete menu with vegetarian options, common allergens and any other important information clearly called out, so the user can ponder their choices.
2. Offer the plates that will contain the food (preferably ones with separate compartments to help prevent plates from folding and to keep the liquid from individual dishes separated)
3. Next comes the food. Space the serving dishes widely enough to allow people to temporarily put down their plates. For those in a rush, serve grab-and-go foods such as pre-dressed salads and pre-made sandwiches.
4. Offer utensils and napkins at the very end, preferably in individually rolled-up packages for compactness and efficiency.
5. Separate the drink and dessert stations to keep them out of the flow of the buffet line.

Deep Fried Food for Thought

The buffet line is just one example of an interactive system in the analog world. We normally take them for granted, but they are worthy of closer analysis. Both good or bad examples can offer lesson on digital designs, just as design principles of the digital world can apply to the analog world as illustrated here.

And the next time someone cuts in front of you at a buffet line to grab a fork and napkin, smile at them knowingly and as you hand over the goods and say, "No problem, it’s not your fault".

[Readers: Let us know if you run across other examples where design in the the analog or digital world informs one another.]

David S. Cortright is a veteran Bay Area interaction designer currently at Yahoo! Inc. David’s previous stints included Microsoft’s Mac division, Claris Corporation and Oracle Corporation. David has a degree in computer science from Stanford University. You can read more from David at http://360.yahoo.com/davidcortright.

• Build a kiosk with a PC and a nice microphone. (Maybe a push-to-talk button if necessary.)
• Hook up speech recognition software like Dragon NaturallySpeaking.
• Write an applet that receives the spoken text, parses out filler tex, looks up key phrases in Wikipedia and “formats” it for output to speech
• Have a text-to-speech synthesizer dictate the introductory paragraph of the Wikipedia article.

Then videotape some interactions:

Human: Computer, tell me about 419 scams
Computer: Advance fee fraud, often also known as the Nigerian money transfer fraud, Nigerian scam or 419 scam after the relevant section of the Nigerian Criminal Code that it violates, is a fraudulent scheme to extract money from victims after making them believe they will get an immense fortune. Victims are requested to pay an upfront fee before their purported fortune is released.

Human: Tell me more
Computer: These scams have come to be associated in the public mind with Nigeria due to the massive proliferation of such confidence tricks from that country since the mid-eighties, although they are often also carried out in other African nations, including Togo, Côte d’Ivoire, [...]

Human: (interrupting) That’s enough, thank you.
Computer: You’re welcome.

Human: Computer, tell me about Archaeopteryx
Computer: Archaeopteryx, from the Late Jurassic of Germany, is the earliest and most primitive known bird. The discovery of the first intact specimen, Archaeopteryx lithographica, in 1861, two years after Charles Darwin published The Origin of Species, set off a firestorm of debate about evolution and the role of transitional fossils that endures to this day.

Human: Computer, tell me about RSI [This is a topic with several articles.]
Computer: I have nine topics about RSI. Do you mean Repetitive strain injury, a disorder affecting bone and muscle from repetitive movement? Or…
Human: (interrupting) Yes.
Computer: Repetitive strain injury, also called repetitive stress injury or typing injury, is an occupational overuse syndrome affecting muscles, tendons and nerves in the arms and upper back. It occurs when muscles in these areas are kept tense for very long periods of time, due to poor posture and/or repetitive motions.

Human: Computer, what happend in 1521?

You get the idea. Bonus points if you make it work well over the phone. And if you get William Shatner to play the human.

Of course this mostly demo stuff. It will always be easier for humans to interact with machines primarily using hands and eyes, not voice and ears (as long as eyes and hands are available). And the human I/O ports of voice and hearing are certainly under-exploited today.)

Nevertheless, building Captain Kirk’s computer would be a cool and funny demo and a fun interaction research project. [Has anyone done this yet?]

Better yet: we already have our phone numbers recorded on our computers. Shouldn’t we be able to leverage that data and all the effort it took to get it onto our computers?

Design to steal

• Let the user manage address book entries online, from the website of the mobile carrier. The actual experience would be akin to managing contact lists with Yahoo! Mail or eVite. Changes made online are quickly, quietly synced down to the user’s mobile phone. Just doing this much would be a godsend.
• Cellular carriers: insist that all future phones be made to support a single phone book standard, to insure interoperability between the web user experience and all future phones. (There is already precedent for carriers imposing standards on phone vendors: Sprint’s phones are converging on a standard battery charger connection.)
• Let the user import phone numbers into the web app from any of the standard address book formats: vCards, CSV, etc. This is a quick and dirty way to leverage data that already exists somewhere.
• Best yet, establish live syncing between the phone and the user’s data source (Outlook, Address Book). The Palm and Blackberry devices have always had this.
• Address books on the PC can get huge, with many old and obsolete entries. So let the user pick which numbers should be imported. Better yet, import everything so it’s there for reference, and let the user pick out the favorite numbers which take precedence when searching the address book.
• Don’t stop at just phone book entries: allow the configuration and management of the phone to be done using a web app. I’d like to be able to bring up a web link to the alarm configuration screen and tell my phone to go off at a certain time, rather than fussing with the little buttons and hard-to-use menu structure. I’d like to be able to add my preferred mobile websites to a bookmark manager on the phone, without using the clunky and slow phone web browser.

The broader principle

There have always been major compromises made when fitting an experience onto a small device, and there always will be. The devices have smaller screens, smaller print and their input methods are less efficient than a regular PC, monitor and keyboard.

Mobile devices should allow for configuration and data management using the richer desktop or web UI. They can and should still allow for editing while on-the-go. (The iPod, unfortunately, does not. If you hate a song, you have to delete it back at your computer. If you want to sort songs into playlists while riding the bus, tough luck.)

Palm was the first to grok this principle of managing a mobile device using a PC, with the very first PalmPilot. Its predecessors, the General Magic device, the Go Corp PenPoint tablet devices (which I contributed to) and to a large extent the Newton attempted to be worlds unto themselves; alternates or even replacements to the PC. Only the Palm Pilot conceived of the mobile device as a satellite to the PC and shipped with a sufficient desktop-based PIM. It was a visionary insight that, along with Graffiti input and long, forget-about-it battery life finally made the notion of a PDA viable. (Unfortunately, Palm Desktop has languished for years. The incompatibilities between its schema and that of the predominant desktop PIMs are a daily pain for millions.) But it’s nevertheless preferable that today’s Treos sync imperfectly than not at all.

The iPod got this right. Earlier MP3 players had no integrated way to manage your songs on your PC and on your portable music player. Because it was so hard to rotate the music, users wouldn’t bother. The players gathered dust. This integration between the iPod and iTunes desktop app was one of the key elements of the iPod’s breakthrough product vision.

The Harmony remote control gets this right. Rather than laboring over one of those loathesome programmable remote UIs, you program the device from the web. You pick out the model numbers of your home entertainment components, it downloads the codes to the remote via a docking cradle.

A prediction

The idea of setting up a cellphone from a web interface seems pretty self-evident, right? Wouldn’t you expect everyone to be working on this?

My guess is this won’t be mainstream any time soon. Why not? Because the gadget guys and the software guys are different people working in different companies. The natural propensity of the gadget guys will be to apply ever greater mobile horsepower to increasingly sophisticated functionality to the devices, despite the inherent limitations of the medium’s user experience.

To bring these two worlds together will take industry leaders with competence in both worlds, plus a pinch or two of vision and systems thinking. That gives Palm, Microsoft, RIM and Apple a sustained advantage, and will leave the commodity mobile phone vendors playing catch-up.

In tabbed browers, when I open a link in a new tab it loads the content in the background, without disturbing the current page. Nice.

But when I select “open this link in a new window” to glance at what the link points to, Safari and Firefox both open the new window over the current one, obscuring the curent page. It would be kinder for them to notice the copious space next to the open window and fill the new window there, so I can continue reading the original page while it does its business.

Here’s a quick & dirty design to steal: When opening a new window, look around for unused areas of the screen and put it there if possible. Minimize overlap on existing windows. This applies to most multiple document apps, not just browsers.

The point is even more general. Most apps and OS’s are not yet enlightened when it comes to huge monitors. Windows XP has an archaic “maximize” button that offers up the entire screen to the lucky window. This was reasonable in the era of the 15″ or 17″ monitor, but most apps have no clue about what to do with the acres of real estate on 20″ or 24″ displays. (Don’t get me started on the MDI/SDI mess.)

On the Mac things are a bit better because the window zoom button is not sworn to fill the whole screen no matter how gargantuan. A zoomed Safari window, for example, will take the full screen height but will contain itself to a reasonable width. But these common sense limits are not universal. An MS Excel 2004 spreadsheet with only a couple of columns of data will nevertheless fill the entire screen when maximized, obscuring all other windows and forcing the UI overhead task of resizing the window.

The point even extends to web sites. Some of the most common web sites also take the lowest-common denominator approach, scrunching their content into a dense block even for users with larger monitors:

Yahoo.com on Windows XP, maximized on a 24″ window: not the most effective use of whitespace.

Vision to steal:The OS vendors need to describe and demonstrate best practices for making use of big screens and multiple monitors.

Design research topic:What should those best practices be? We need to account for different classes of applications including web pages that must scale between tiny and huge displays, “power apps” like photo, video, music editing that establish self-contained workspaces, and so forth. How can window management overhead be minimized? What is the best approach to floating palettes of tools? How should they work with multiple monitors? How should they adjust when monitors come and go?

[A brief primer: for me to send you an encrypted message I have to lock it up with a public key that you provide to everyone. The message can then only be unencrypted with a private key, which you keep to yourself. Before I send you something secret I must first obtain your public key, which can be a hassle. Today the typical way to get someone's certificate is for them to send you a signed email.]

Trading public keys for the first time

The basis of this approach is to have the email clients talk to each other about the public keys. Once that’s established then your secret message can be safely passed along.

Here is the outline of a typical interaction of sending an encrypted email to someone for the first time:

1. User A tells his email client to send User B an encrypted email
2. A’s email client sees that it doesn’t have B’s public encryption key, so it can’t yet send the message
3. A’s email client keeps the email queued up and sends B’s client a request for her public key. This is just a regular email message in a format that will be automatically recognized by B’s client.
4. B’s email client automatically responds to the request with B’s public key. The request for public key is human-readable. So if B’s email client does not know this protocol, user B sees something like this: "This message is a request from A a@a.com for your public key, in order to send you an encrypted message. Please reply to this message with yor public key. If you are not sure how, click here."
5. User A’s email client receives B’s public key, and incorporates into B’s contact information silently.
6. User A’s email client sees that it has messages awaiting B’s public key. It encrypts and sends the message.

The net result is that secure email can be traded as usual, with the details worked out by the clients. It cuts out middlemen "Certificate Authorities" who collect and distribute public keys. If someone needs to send something sensitive to someone who is not yet setup for encryption, it lays a clear path for that user, alleviating the burden on the sender to educate the recipient.

Bonus security: Making sure B is really B

Security freaks may be concerned that someone who is not B may intercept my request, impersonate person B, give a fake public key and get me to send the secret message to the bad guy. This concern seems most directly addressed with a dose of lithium.

Nevertheless, if it really becomes necessary to make sure that B is who B claims she is, here is a more natural way:

• At step 2 above, A is prompted for a question to ask B that is something that only B could answer: "To make sure this message is really going to John Smith, please enter a question that only this person will be able to answer (eg. your nickname or a piece of information you recently told B verbally)."
• Person B receives the request as an email message and replies with the answer to the question.
• Person A receives the response with B’s answer to the question. A’s email client asks the user to accept or reject the answer. When the response is accepted the accompanying public key is associated with B’s contact record.

Again, this is probably not necessary for 99.9% of cases and should be avoided, as it adds another geeky layer.

Forcing corporate and government employees to exchange encrypted email

What can executives appalled at the corporate secrets coming and going through the ether do? They could establish a corporate policy that blocks unencrypted emails from leaving the premises. This would quickly force insiders and outsiders to play by the rules: no unencrypted email exchange with the outside world. [Anyone know of corporations with such policies?]

What about partners sending things in? Even more heavy-handed policy would be to prohibit incoming email from being delivered without encryption. The gateway at the corporate boundary would automatically bounce-back a message, telling outsiders to resend the message with encryption, and link to clear step-by-step instructions for setting this uip.

A more humane variant would allow the first x (say 3) messages through without warning, to allow for sporadic inquiries. The next y (say 5) messages would also be allowed through as a grace period. The outsider would be forewarned that ongoing communication will require that future messages be encrypted, and provided instructions for setting it up and the public key of the recipient. Finally, subsequent messages would be rejected. The recipient inside would be notified that a message from that user was rejected.

These policies would get outside partners onboard with encryption very quickly, plugging the inadvertent exposure of sensitive information to the open Internet.

See also

• Open, yet encrypted Wi-Fi

Questions for Readers

• Has public key trading been solved in a better way yet?

Apple made Alt-tabbing prettier, but they didn’t fundamentally improve the interaction. So Alt-tabbing has remained fundamentally unchanged for about fifteen years. Here is a refinement on the micro-interaction, that applies to both Macs and Windows.

What’s to improve? The issue is that using Alt-Tab to switch between apps is mentally indirect. When using the mouse, the user can just point and click, effectively saying, “Go there, assuming the target window is visible. Very direct.

Alt-Tabbing requires more mental effort. The user must first figure out which app owns what they are looking for, then locate the app’s corresponding ‘s icon, then tab to it. It is not a visual process of just pointing to what you want. This is not a big deal if you only have a couple of apps open. But today’s fat PCs encourage the user to use many apps simultaneously. And if those apps are similar and confusable, such as with multiple text apps, or graphics apps, or web apps, it can be a real distraction to the work at hand.

Design to steal

When the user Alt-Tabs between apps, bring forward each app in succession, dimming back the rest.  Users can Alt-Tab until they see the window they are looking for.

1) Starting point – App A is the front-most app. Windows B1 and B2 belong to the same app. App C is hidden or minimized. App D is visible.

2) User presses Alt-Tab; windows B1 and B2 come forward because they belong to the same app. Everything else dims back.

3) User presses Alt-Tab again; app C becomes temporarily visible, from its minimized or hidden state.

4) User presses Alt-Tab again; app C hides again and app D comes forward.

5) User releases the Alt key; app D is now front-most.

This approach is more direct and visual — users no longer need to mentally map what they are looking for to the application and its icon.

The windows for hidden apps or minimized documents become temporarily visible as the user cycles through them.

Refinements and variants

Smoothing it out – This solution may cause a lot of inelegant flash as windows come and go. One way to smooth this out is to experiment with bringing forward and brighten the next app instantly (because we must minimize UI friction).  Then fade the others back, over the course of a half second or so. This would help make the transitions feel more organic and gratifying.

Switching between documents – In the course of juggling work, one is as likely to need to switch between documents within an app as between apps. Despite these being sister tasks, document switching is done very differently than app switching. On the Mac, the user presses Alt-` to cycle among documents.  Each keystroke reveals the next document.  Unlike app switching, no Alt-Tab UI is shown.

How might document switching and app switching be blended? What if the document cycling worked analogously to app cycling? Instead of merely bringing document apps forward, Alt-` would reveal a row of document miniatures.  Successive key presses would step through these.  Releasing the Alt key would bring the selected document to the forefront.

[Update 7/27/09 Here is a mock-up of the idea that uses the style of Exposé]

The user then gets to navigate to a document using either of the two strategies: the old way, by Alt-`ing and releasing until the document is frontmost, or by keydowning on Alt-` to see the line up of available documents spotting the desired document in the line-up and then repeating the Alt-` keystrokes until it is highlighted, then releasing.

Combining both ideas: the user could get to any document by first Alt-tabbing to the right application, then Alt-`ing to the right document.

Follow-up Research work

This is not the end of the story with updates to be made to application switching. Here are some related problems.

• Apple’s vaunted Exposé feature exists to solve the same needs and scenarios of switching between windows, yet it does so in a completely different way. It scatters all the visible windows out on the desktop in miniature, so the user can select one. This s fine if you have few windows open, but not if you have many. It’s just too much to scan through a dozen windows, finding a needle in a haystack. It’s even more work if the windows are splayed out on a large, modern display. And in a frustrating oversight, your efforts are in vain if you’re looking for an app you happen to have hidden or a document you minimized. How might Exposé, app cycling, document cycling and even the Dock be consolidated into a simpler, coherent, continuous system? [See Blending it in versus bolting it on, and Alt-Tabbing for part of the answer.]
• On Windows, how can app cycling be melded with some improvement on the painful system tray? How can document switching be added to the mix?
• This proposal works with the fundamental conceptual model of applications owning documents. Is there a better way?

Related questions

Does anyone know what logic Mac OS X uses to determine the order of the icons in its Alt-Tab UI? The first two are the last you used but the rest seem to be in a random order. Is this a bug or a feature?  [7/27/09 This was answered in a comment to What is the alt-tab order?]

See also:

• Blending it in versus bolting it on, and Alt-Tabbing
• What is the alt-tab order?

[Updated 2/22/06 to clarify the document Alt-` idea]

[Updated 7/27/09 to further clarify and add mock-up of the document switching UI]

Have you gotten into the habit of selecting a block of text before you click that button, so you have a distinct point of reference to look for after the zoom?

Browsers are doing something strange when you increase or decrease the font sizes.

For example:

• In Safari, scrolling to the middle of an article and repeatedly clicking the font up button to zoom in progressively scrolls to the top of the article until its headline is visible at the top.
• Clicking font down repeatedly scrolls down until the bottom of the article is visible.
• Firefox and Internet Explorer do something similar.

Does it have to be this way? Not every app has this problem: Microsoft Word’s zoom feature, for one, keeps the content where you expect it when you zoom in and out.

Designs to steal

The effect should be akin to moving closer and farther from the screen.

Here are three possible heuristics to try out:

Alternative 1. When the user clicks the font size up/down, keep the line at the top of the page where it is after the zoom.

Alternative 2. Keep the line of text at the center of the page where it is after a zoom.

Alternative 3. If there is a selection active, keep its top edge where it is after a font up/down

I expect number 2 to feel most natural because it should give the brain the effect of zooming in and out.

[Readers: do you notice this too? Are there any browsers who do this well? Anyone know why most browsers have this issue?]

Much as we wish otherwise, Photoshop does not have an object-oriented conceptual model. You can’t just click and act on an element of a composition. You need to find and select the layer on which the element resides.

Someday someone will demonstrate how much funner graphics work can be if the bitmap manipulation capabilities of Photoshop were combined with the object-oriented approach of OmniGraffle, Visio, Stone Create, the old ClarisImpact and many others. With those apps you select an item merely by clicking on it.

In the mean time, Photoshop users are stuck with having to select layers. Unfortunately they don’t make it easy. To select one of the rounded rectangles in this example, you have to try and discern the layout from the nasty layers palette (at right):

To make life a bit easier, Photoshop lets you right click to see a list of layers under the cursor (assuming you are in the right mode):

So what’s the problem?

To come up with a better solution, it’s important to get precise
about what you’re trying to fix. Here, the issues are:

1. Who knows what the name of the layer is? Most layers are never labeled.
2. And even those that are labeled requires the designer to mentally map what they see into its name, which requires thought. Is there a more direct way?
3. Photoshop doesn’t indicate what layer is selected on the canvas. So even if you have the right layer selected, you can’t be sure. You either have to assume you do (which leads to the frequent and maddening wrong-layer error), or look over at the layers palette to check.
4. Even if you check with the layers palette you may not succeed: the thumbnails are small and you may have multiple layers with similar looking thumbnails. The remedy is to hide and show the layer and see if it’s the one you were expecting.

Can we do better? Is there a more direct and sure-fire way to select a layer without guesswork? Can we do it visually so the user doesn’t have to enter the world of words?

Selecting layers graphically

Here is how a graphical layer selection menu could look:

a graphical layer selection menu

Some elements of this approach:

• The graphical menu includes the name of the layer for the use cases where that is needed and used.
• Rolling over an item in the menu highlights the corresponding item in the layout. This helps when there are multiple similar looking layers.

Variants of the idea

1. Skew the layers to emphasize that you’re looking at a stack of layers:

2. For some extra (Mac OS X-inspired) bling, rapidly animate proxies of the layers from their spot on the canvas to the stack of layers.

3. Let the user press a modifier key with the right-click to line up all the currently visible layers. Maybe even the invisible ones, too, to facilitate finding and turning on a wanted hidden layer.

This idea isn’t limited to Photoshop and its layer issues, by the way. It can be hard to select the right object in a layered composition even with the object-oriented graphics apps.

[Readers: Do any current apps do this well?]

And it’s all your fault, isn’t it? For not knowing by now which way to insert it? For not looking at the little pictogram that makes it all clear?

I conducted some quick & dirty product research, asking several supermarket checkout clerks how often customers mis-swipe. The estimates they gave ranged from 1/3rd to 50% error rate, a critically high rate. Since so many people make the error, it’s not your error at all, but a trap built into the system.

What is the problem?

There are two main sources of the problem:

1. There are four possible ways to insert a card, but only one way is considered “correct."
2. Card readers are inconsistent among themselves. Some have a horizontal slot, some a vertical slot, some a face that you swipe. These different experiences tug the user in different directions, with the training imparted by one device reversed by the next. As a result, one never really get good at inserting the retched card in the retched slot.

Different card readers try to show a diagram of how you’re supposed to hold and insert your card. The best of these show it in perspective, making the mapping from reality to the diagram easier. But these efforts are beside the point. To process instructions, even visually, requires you to halt your conversation, break your train of thought, read and think. This is expecting too much of someone doing a cursory activity.

Some ATMs detect the leading edge of the card and block the card if it’s not going in the right way. This is a bit better, but it still requires experimentation to get right.

Regular keys don’t typically have this problem. Must card keys?

Vision

We need a solution that is as automatic and thoughtless as inserting a regular key into a keyhole. One that doesn’t require you to stop, think, experiment; one that is obvious. Why can’t the slot just accept the card however you insert it?

Possible remedies

Instead of just one solution, let’s show a range of possibilities that might be appropriate depending on the circumstances: whether we need to worry about backwards-compatibility of legacy cards, economic constraints, and so forth:

1. Make the shape of the card asymmetric, so there is only one way it can be inserted. (Precedent: the punch card of the 60′s or the SD card of today). The downside is you still have to insert the card before discovering that it’s the wrong way.
   
2. Include two or four magstripe readers in the slot. This makes the machine tolerant of other ways of inserting the card. Two readers reduces the error rate greatly; four readers eliminates it altogehter. No instructions needed![5/26/05 Update: I came across a soda vending machine that allowed bills to be inserted face up, either way]
3. Put the stripe down the middle of the card, not against one edge. Have the reader read the information backwards or forwards. Then you only have to insert the card up or down. This solution works if you don’t have to worry about the “installed base” of users. Here’s the before (left) and mocked-up after (right):
   
   
4. Have a strip in the middle of the card and include two magstripe readers in the reading device. (hybrid of 2 and 3): This allows all four ways of inserting the card, with the lower cost of only two readers.
5. Avoid having to insert the card to begin with. There are office doors that require only a wave of a card key across a reader. Prius owners never have to insert a key into the ignition; it just detects your presence through a key fob and lets you open the door and start the car. (But be wary of the unintended consequences of RFIDs.)

Applies to

• Any device that accepts magnetic cards: ATMs, Credit card readers, check-in kiosks in airports, parking ticket kiosks, transit turnstiles, library self-checkout kiosks.
• Vending machines that accept bills

Follow-up Research Topic

For the interaction design researchers or card reader companies: create a prototype card reader which accepts cards in any orientation. Try out different orientations of the reader. Measure the natural ways that people insert the cards to inform the design solution.

(Hypothesis: vertically orientated would have fewer errors than horizontally-oriented readers, because there is a clearer “up”. If so, it reduces the necessity — and cost — of including magstripe readers for two of the orientations.)