The app presents these genres, plus four additional functions, as icons on a screen that looks very similar to the standard iOS Springboard for launching applications.

A total of twelve icons is spread out over multiple screens, which can hold up to six icons each. To flip between the screens, you use the familiar horizontal swipe gesture.

The app also lets you re-order these icons, so that you can compile your favorite sports genres onto one screen: As you would in Springboard, to enter editing mode, you tap-and-hold any of the icons until the latter start wiggling.

While in editing mode, you drag the icons around to arrange them. And when you’re done, you tap the “Anordnung speichern” (“Save Arrangement”) button to save your changes.

As you can see, the Sport1 app very closely mimics both the appearance and the behavior found in Springboard. There are, however, two noticeable differences: In addition to the swipe gesture, the app supports navigation arrows, and icons are automatically re-arranged if you leave any empty spots on a screen.

Turning helpful arrows into sources of confusion

The navigation arrows can be hidden via a checkbox — “Pfeile anzeigen” = “Display arrows” — that appears while the app is in edit mode.

If this option is checked, the arrows appear in the place of a regular genre icon. Unless the app is in editing mode!

While in editing mode, the arrows are always hidden, regardless of the setting for this option. This leads to an annoying problem: If you fill all six spots on a screen, all icons are re-arranged as soon as you leave editing mode to make room for the navigation arrows.

What you see in the screenshot above will, after exiting editing mode, look like this: The Basketball icon had to move to the next screen to allow the right-arrow to be displayed.

One way to address this would be to also display the arrows in editing mode. In that case, it would be essential to properly restore the previous icon arrangement when checking and un-checking the arrow option, though.

Every empty seat must be filled

A useful way to arrange app icons on an iOS device is to use “themed” screens. E.g., you could have a screen for games, one for communication apps, one for utilities, etc.

This works just fine, because Springboard won’t “re-flow” all icons to completely fill all spots on a screen. If you wish, you can have just a single icon on a given screen.

Not so in the Sport1 app.

Let’s say, you’re mainly interested in Formula 1, soccer, and U.S. sports¹, and you would like to place just these three genres on the app’s main screen. The app does let you configure that arrangement, as you can see here:

As soon as you leave editing mode, however, the app just re-flows all icons so that the three empty spots in the bottom row are now also filled.

Oddly enough, this does not happen when the navigation arrows are active. In that case, the icons are not re-flowed.

Why should the decision about whether you would like see those navigation arrows have any impact on how the icons are (re-)arranged? Is this just a bug, maybe?

Mimic, or don’t mimic. There is no “sort-of”.

The icon screen in the Sport1 app re-creates the iOS Springboard’s appearance and basic behavior so closely, that a user can reasonably expect it to work exactly like the “original”.

Expanding and modifying the original’s behavior, however, may confuse users because the way the Sport1 app works differs from what they’ve come to expect based on their experience with the original “role model”, Springboard.

At the time, the application that is mentioned in this message was not even running!

Little Snitch is a network utility, and it consists of a “daemon” — a software program without a user interface which runs in the background all the time — and a regular application for configuring the software. It’s the latter that allows checking for updates.

I’m not sure whether a bug caused this dialog box to appear¹, but, in any case, it provides a great example for what an application should not bother its users with: Anything that does not require the user’s immediate attention, unless she explicitly requested a piece of information.

Don’t bother me unless it’s important and urgent

What’s it really say in that message? “This application is up-to-date. There’s no need for you to do anything at all about this right now. Just sayin’.”

Although this message was anything but important, it showed up front-and-center on my screen, thus interrupting my workflow, and making me lose my focus and concentration.

Compare this to warnings about my laptop’s battery being low, so that the machine will go into hibernation within a few minutes; or about the machine’s hard drive running out of space, potentially preventing me from saving any more files very soon.

In both of these cases, the computer makes me aware of something that could have a serious impact on my ability to properly use the machine. I must do something about it, and I better be quick.

These kind of critical warnings are annoying, too, but if they didn’t appear, the consequences would go well beyond annoying.

Imagine, however, what it would be like to use a computer that also “warned” you of the fact that everything’s OK! “There is lots of space on your hard drive!” “Your battery is fully charged now!” “There is still enough space on your hard drive!”

Unless you explicitly request a piece of information, e.g., by selecting the Check for Updates menu item, you should never be confronted with a dialog box that merely states that “everything’s fine”. There’d be so many of them, you wouldn’t get any work done at all.

What dialog boxes and secret documents have in common

In a way, well-designed dialog boxes are like confidential documents: They should be presented strictly on a “need-to-know” basis only. If the user doesn’t need to know now, software should just remain quiet.

In cases where there is a need to convey non-critical system status information, status icons or status bars are a much less intrusive and more user-friendly approach.

Some internet service providers override this behavior by displaying their own, branded search page. Like this one from CenturyLink, which is named Web Helper service.

It is easy to see how such “error pages” provide ISPs with extra income from sponsored search results (read: paid ads).

Nevertheless, they are a poor substitute for the browser’s built-in error handling, because it creates usability problems:

1. The ISP’s search page masks the underlying error,
2. it obscures the URL that was entered originally, and
3. restoring the default behavior is tedious.

Masking the underlying error

The error message that appears in Safari is unambiguous. It says exactly what went wrong in easy-to-grasp language.

Users who may still be confused by the error message can click on the Help button next to the message text to summon a help page in OS X’s Help Center, which lists possible causes for the error, and provides useful instructions on how to fix it.

Contrast that to CenturyLink’s page, which completely fails to explain what just happened, and why you are seeing it instead of the web page you originally wanted to visit.

Thankfully, there is a link at the top (and bottom) of the page, labeled “Why am I here?”, that promises to answer this very question.

Compared to Safari’s concise error message, the explanation is much more verbose and purely descriptive. It does not contain a single prompt telling the user what to do now, as in “To fix this problem, do this!”

As a result, understanding what went wrong, and learning how to solve the problem, take more effort.

Obscuring the original URL

Look at what happens to the data, i.e., the URL, that you enter into the browser.

Safari leaves it unchanged despite the error. In contrast, CenturyLink uses a redirect to hop over to their search page, which replaces the link in the browser’s address field.

In cases where the error is caused by a typo, seeing just the original URL that you had entered makes it much easier and faster to verify what you had typed, and to fix any typos that you may find.

Making it tedious to restore the default behavior

As stated in the “Why am I here?” text, you can opt-out of this service. All you need to do is change a setting on the Web Helper service’s preferences page, and click Save.

Once the changes have been confirmed, you will be spared CenturyLink’s Web Helper page and see Safari’s plain old error message, instead.

If, that is, you changed the setting on a computer that is connected directly to your CenturyLink modem. Otherwise, the setting won’t stick, even though the website presented you with that confirmation screen.

What “directly connected to the modem” means is this: Plug one end of an ethernet cable into your computer, and the other right into the modem’s LAN socket.

Depending on your network setup, this is a non-trivial task.

In our home, for example, we use an older Qwest-branded Actiontech M1000 modem. This device only has a single Ethernet port, to which our WiFi router is connected. All of our computing devices go through this router to connect to the Internet.

As an important detail, I have configured our modem to operate in “bridge mode”, and user name and password for signing into our ISP’s network are configured in the router, not the modem.

To follow CenturyLink’s instructions for disabling their Web Helper service, I would need to unplug the router from the modem; connect one of our computers to the LAN socket on the modem; find our credentials for PPPoE access and enter them into the computer’s Network preferences; and then I could finally opt out of the Web Helper service in the hopes that this setting would stick.

What a mess!

The least that CenturyLink could do is to let you change the Web Helper setting via their customer account dashboard. Better yet, just get rid of this page already, or make it opt-in. Why?

Because any state-of-the-art web browser provides better error messages for, and faster and easier recovery from, invalid URLs than customized “error response” pages like CenturyLink’s.

And if you really need to perform a web search for finding the proper URL, there’s a prominent field for that in every browser, anyway.

According to the article’s author, Pablo Villalba, a feature that premiered in OS X 10.7 Lion — overloading the scrolling gesture with “Show previous/next page” commands — leads to interaction mayhem (emphasis his):

[This behavior] can be disabled with a system-wide setting from Preferences -> Trackpad -> Mouse gestures (disable two-finger swipe), but my problem with it is that it breaks the web with a non-standard behavior, and gives you no JS API to prevent it.

Thankfully, the situation is not quite as gloomy, because Villalba’s claim is flawed:

1. The swipe-for-page-turn behavior is not non-standard,
2. it does not break the web, and
3. disabling it on a website-by-website basis would be the wrong solution.

Just another way to turn a page

Macs equipped with a multi-touch trackpad have offered a two-finger gesture for scrolling window contents for a few years now.

Under OS X 10.7 Lion, this gesture does double-duty for page turning: If the window contents cannot be scrolled (e.g., if the document is fully visible), or if you have scrolled the content as far as it will go, the gesture will switch from scrolling to jumping to the previous or next page in a document.

This two-finger-swipe-to-turn-the-page behavior is a system-wide feature in OS X Lion, and is supported by several applications. For example, you can use it to turn pages in a PDF document in Preview, or to step through photos in Aperture.

In principle, it is just another way to trigger a common operation. As such, it complements existing keyboard shortcuts and button clicks, and constitutes perfectly standard behavior on any Mac running OS X Lion.

If going to another webpage in Safari via the two-finger swipe is breaking “the” web, why doesn’t Villalba accuse the Previous/Next Page buttons of the same crime?

Admittedly, using one interaction for triggering different commands is always problematic, because the user needs to understand what command will be triggered based on the software’s current mode of operation.

Consequently, the risk of inadvertently moving away from the current webpage via the two-finger swipe is likely higher than inadvertently clicking the Previous/Next buttons. But this is not the core problem here.

The real problem is that, for applications, the web’s page metaphor does not make sense.

Web apps and the page metaphor don’t mix

The original concept for the World Wide Web was based on hypertext, and the data you would view right inside the browser was mostly that: interlinked text.

For this kind of data, a page is a natural “serving size”, and this fact is reflected in the way browsers let you navigate “pages”.

If you’re dealing with an interactive web application, however, the page metaphor does not make sense. For a web application, its user interface is the only “page”, and browser features for handling pages — including the Previous/Next Page commands — are not only meaningless. They can even interfere with the proper functioning of such an app and also lead to data loss.

The problem, therefore, does not lie in how you step away from a webpage running an app — via clicking a button, pressing a keyboard shortcut, or gesturing on a trackpad –, but in the very existence of these page-turning functions.

Keeping things consistent across, and within, apps

To address this problem for his own web application, Villalba would like to disable Safari’s turn-the-page gesture programmatically. He bemoans that, as of yet, there is no way to do this.

As I explained above, though, using this gesture for page turning is not limited to the Safari web browser. It is a system-wide feature in OS X Lion. Therefore, if a user has chosen to use this feature, it should work consistently across, as well as within, applications.

If it were possible to disable the gesture on a website-by-website basis, then that actually would break “the web” for any user who wants to use the gesture.

Instead of letting web developers disable system-features in this manner, I would prefer another solution to the very real problem that Villalba talks about.

An application mode in web browsers

The features and related user interface elements that browsers provide for handling web content as pages is what gets in the way when running a web app.

One possible solution, therefore, could be based on a dedicated “application mode” that is supported across different browsers and invoked by a simple, standardized command or tag.

In this mode, the “Previous/Next Page” buttons would be deactivated, forcing the user to stay on the web app’s page. Selecting the Close Window command would present a warning dialog whose text could be customized programmatically, and the user’s response to it passed on to the web app, before it is requested to quit.

Surely there are other functions that web app developers would like to see being enabled or disabled based on this app setting. Also, I’m not sure exactly how these features should be implemented design-wise: How should the application mode status be communicated to the user?Should there be an override for deactivated functions? Etc.

In any case, the key is that the solution is standardized across browsers and web applications, and that it provides a flawless user experience that does not rely on the design and coding skills of the individual web applications’ developers.

Just as importantly, the application mode must not modify any interactions — like scrolling or page selection in a browser — that may be un-conventional overall, but perfectly common on a specific computer platform.

Here are some fresh observations from a recent stay in Denver, Colorado, and related, useful design guidelines.

Don’t baffle me with wrong affordances!

One of the first discoveries when we walked into the room, was this knob on the night stand.

How neat: Looks like you can pull out a board to extend the nightstand’s surface! Only you can’t.

Although the knob looks identical to these two on a fully functional drawer, …

… the one on the nightstand does nothing. It’s pure decoration. And awful design, because things that look identical should work in identical manners.

Make devices physically easy to use!

Our room had a balcony, that you access through a sliding glass door. Its lock is a poster-child for visibility: Not one detail of its inner workings is hidden behind a cover.

Although this makes it easy to understand how the lock works, it is painfully difficult to actually operate it.

The fit of the lock is very tight. Unless you manage to move the door to just the right position in which the friction between the bolt and the holes is minimized, it is simply impossible to pull the lock bolt out of these brackets.

The lack of a proper handle on the bolt only makes matters worse, and we managed to send the thing flying across the room more than once.

Provide useful instructions for non-simple devices!

Not all things in a hotel room are as simple as the balcony lock. Some of them, like this coffee maker, require instructions to make them work.

Instructions should be easy to find, easy to read, and easy to understand.

The coffee makers instructions, however, are hidden on the inside of its lid, and nothing on, or near, the device points to that location.

The “manual” itself uses tiny low-resolution images, which are difficult to decode. For example, compare steps two and three: Can you make out the two disks representing the coffee pads inside the machine?

Why not place a placard next to the machine to make the instructions as easy to find as possible? This would also provide ample room for bigger, easier-to-decipher images, as well as plain text instructions.

The device’s user interface could also use a bit of attention.

Its three buttons would benefit from higher-contrast labels, and coloring the more-important “Stop” button red would make it easier to distinguish between it and the “Brew” buttons.

Clue me in on how this thing works!

Speaking of easy-to-use buttons, this beautiful block of chromed metal is the toilet flush-lever. It does stand out from the off-white ceramics of the bowl, so it’s easy to find.

Its very clean rectangular shape, however, fails to provide any visual clues as to how to operate it.

To trigger a flush, you need to push down on the rear (i.e., wall-side) end of the lever. A little indentation on the lever would remove any doubts about where to place your finger, and in which direction to move this control.

Help me find stuff quickly!

We prefer to fine-tune our rooms’ temperature, but sometimes it’s difficult to find the respective control panel.

See that little box on the wall to the right of the TV? That is the A/C control panel.

The corresponding heater/AC unit is that large thing towards the far end of this wall, several meters away from the control panel.

It’s almost funny how unfortunate the control panel’s mounting location has been chosen, because when you enter the room, it’s hidden behind the narrow column on the wall that you can see near the photo’s right edge.

And when you lie down in bed, it’s hidden behind the huge-screen TV. In fact, my fiancée noticed the panel just when we were about to leave the room to check out …

To close this article on a positive note, something that is essential to us traveling geeks was wonderfully easy to find in this room: Power sockets!

Instead of rummaging around under desks, behind TVs, or inside fridge closets for precious electrons to recharge iPhone & Co, two empty sockets were in plain sight

Placed in the base of the desk lamp, they are easy to find, convenient to access, and provide power exactly where you will need it.

Yet more (if older) hotel room observations

If you find “hotel room usability” as exciting as I do, you will enjoy reading my observations on a radio alarm clock designed specifically for hotel rooms, a usability problem with hotel safes, an annoying shower curtain, a make-up mirror with a touch user interface, and even something as mundane as an elevator button panel.

The concept of seamlessly integrating an “intelligent” command line into a modern graphical user interface has been around for quite a while in the form of utilities like LaunchBar, Alfred, or Quicksilver.

These programs allow you to not only find files, but also let you search application-specific data like address book contacts, music tracks, and browser bookmarks, and apply meaningful operations to the search results.

While not quite as powerful, the system-wide search features in Windows 7 and Mac OS X also transcend simple searches based on the files’ names or their content.

What is new about the Ubuntu HUD is its scope: Instead of operating on just files and data, the HUD can also find and execute commands from the application’s menu.

Apple uses a similar approach with a text field inside the Help menu, which lets you search the entire menu structure of the currently active application as well as the app’s help file.

The key difference between the two approaches is that Apple designed the menu search as an extension of the contextual Help system. As such it complements the application’s menu.

In contrast, the Ubuntu team considers their HUD interface to become a menu bar replacement.

> Say hello to the Head-Up Display, or HUD, which will ultimately replace menus in Unity applications.

As much as I am intrigued by the Ubuntu HUD as such, getting rid of the menu metaphor completely — including keyboard shortcuts — is not just unnecessarily drastic. It is short-sighted and misguided for a number of reasons.

For sheer speed, keyboard shortcuts are hard to beat

When graphical user interfaces were in their infancy, keyboard shortcuts were “invented” to allow users to more quickly invoke commonly used menu commands.

Instead of opening a menu and selecting one of its items with the mouse, you press a combination of a special “command” modifier key and one or more additional keys.¹

The key combination for a command is displayed next to its menu item, so you are reminded of it every time you select the command from the menu via a pointing device.

Once you’ve memorized a keyboard shortcut, pressing it takes a fraction of second.

Compare this to the Undo operation in the “Introducing the HUD to Ubuntu” video (which you can watch embedded in Shuttleworth’s article or on YouTube): At 0:50 minutes into the video, you can observe how the user literally types “undo” into the HUD.

It takes the user about three seconds to issue that command!

This single interaction in the video provides sufficient proof that getting rid of keyboard shortcuts would be a seriously foolish move.

The HUD is modal, a keyboard short isn’t (quite)

To ensure that key presses reach their intended destination — either text entry into a document or text field, or a menu command –, the computer needs to be put into a temporary “command” mode when entering keyboard shortcuts.

The machine enters this mode when you press the Command key, and as soon as you let go of the key, it will leave the mode again. When you press the keys that make up a shortcut, Command is merely “first among equals”.

Once you’ve familiarized yourself with a shortcut, you will no longer “build it” key by key — “first, the Command key. Then the Shift key. And now press ‘S’, and there’s Save As…!”

Instead, you will “chord” the command, and it will feel like a single interaction step.

The HUD, in contrast, always requires at least three interaction steps:

1. Pressing a key (or shortcut) to summon the HUD
2. Pressing one or more keys to enter the search term
3. Pressing a key to commit or cancel the selected command

Keyboard shortcuts are non-ambiguous and non-arbitrary

Depending on the search term you enter into the HUD, you may have to make a conscious selection from the list of search results that the HUD presents to you.

If you do have to make a selection beyond accepting or rejecting the “best match” that is automatically pre-selected for you, then that requires another interaction step, possibly consisting of pressing the up or down arrow keys multiple times.

In contrast, a keyboard shortcut always triggers one, and exactly one, command.

Command-P will always print the current document, but the top match that appears in the HUD when you enter a “P” may just as well be “Preferences”.

Speaking of the match between shortcut keys and commands: Shuttleworth claims that …

> Hotkeys are a sort of mental gymnastics, the HUD is a continuation of mental flow.

At least for basic shortcuts, that claim doesn’t hold water.

When assigning a key to a menu item, developers don’t make random picks. Instead, they carefully choose letters that have a meaningful correlation with the command. Like “Open”, “Save”, “Print”, “Close Window”, or “Quit”.

Note, by the way, how you would start the corresponding HUD search with the exact same letters that are used for the shortcuts!

In cases such as these, where you know exactly which command to execute, the HUD does not offer advantages in terms of learning, recalling, or finding commands.

Some shortcuts use less intuitive letters, like Command-Z for undo, or Command-[comma] for opening an application’s preferences (on the Mac). Once you use them often enough, though, even they will become second nature over time, especially when they are among those commands that are standardized across the entire platform and, thus, trigger the same function in all programs.

Shortcuts and menus leverage motor memory

When you issue a shortcut like Command-Control-F, you will likely not have to consciously place the three fingers on their respective target keys. After you’ve gained enough practice in “chording” the shortcut, your fingers will move into place automatically.

The same holds true when selecting certain commands with the mouse. E.g., on a Mac, the “About [this application]” command’s position in the menu structure is standardized across the operating system.

Therefore, you know (from experience) that your first mouse pointer destination is “somewhere up there in the top-left corner, and it’s the menu directly to the right of that Apple thingy.” Your second destination is the first thing right underneath the menu’s title label.

Even though their positions aren’t standardized as strictly, many other often-used commands — for creating, opening, and saving files, for example — are found in similar locations in every application on the platform.²

Combined with motor memory, selecting a menu item this way can be surprisingly efficient.

Driving around with the mouse? All day!

Here is another quote from Shuttleworth’s article:

> So while there are modes of interaction where it’s nice to sit back and drive around with the mouse, we observe people staying more engaged and more focused on their task when they can keep their hands on the keyboard all the time.

For someone who mainly works with text, that may very well be true.

Watch someone work on non-text data, however, and you’ll observe that, for these people, keeping one hand on the mouse (or graphics tablet, etc.) and another on the keyboard is their standard “mode of interaction”.

This approach is common for any work that involves a continuous mixture of entering keyboard commands and moving objects on the screen, regardless of whether these objects are shapes on a canvas in a graphics editor, audio and MIDI snippets in a track arrange window in a music recording program, or images in a photo management app.

In such cases, you manipulate the on-screen elements with one hand on your pointing device of choice, while using the other hand to enter keyboard shortcuts for copying, pasting, etc., or pressing modifier keys for changing the cursor behavior from dragging to rotation, for example.

Consequently, assuming that keeping both hands on the keyboard at all times is the optimum solution for every type of user is pure nonsense.

For anyone who spends the better part of their working day inside applications like Photoshop, Pro Tools, or Aperture, it would be a nightmare to be forced to use a command line instead of being able to concurrently combine keyboard shortcuts with the extensive use of a pointing device.

The Ubuntu HUD’s content isn’t optimized for its use

When you watch the demo video, keep a close eye on the search results in the HUD. In its current implementation, the HUD provides just a different view on the application’s menu structure. Its output is not optimized for use in this UI control.

For example, at 1:55, the user enters “alic” into the HUD to search for “Alice in Wonderland”. The matching result is listed as “Tools > Bookmarks > Alice in Wonderland”.

What average computer user thinks of an audio track as a bookmark? And how is a bookmark related to tools?

In cases as this, displaying the full menu structure that encloses the “Alice in Wonderland” track, is not adding any useful information. In fact, it even makes decoding that search match confusing.

Compare that to how LaunchBar displays a music track: All you see is the track name.

The search results’ types are communicated by simple, reasonably intuitive icons. Unlike the Ubuntu HUD, LaunchBar hides the found items’ meaningless taxonomical overhead from the user.

Using the left and right arrow keys, you can further explore the results list. Moving “right” from the “Cyberfunk Acoustic Revenge” album, you get to see all tracks on that album.

Digging into the selected track, your are presented with the track’s artist, the album that it’s on, and its genre.

The core difference between the Ubuntu HUD (as it is working now) and LaunchBar is that the former is based on a rigid menu structure, whereas the latter searches arbitrary data, and presents it in a way that is meaningful and highly accessible to the user.

Instead of mapping a flattened menu tree structure into a linear text list as demonstrated in the video, the HUD should display its information from a task perspective by:

• displaying contextual information when it is useful ( “History > Planet Ubuntu” ⇒ “Browser History > Planet Ubuntu”),

• reducing redundancy (“Bookmarks > Bookmark This Page” ⇒ “Bookmark This Page” or “Edit > Undo Fuzzy Glow” = “Undo Fuzzy Glow”), and

• speaking the user’s language (“Tools > Bookmarks > Alice in Wonderland” ⇒ “Play Music: Alice in Wonderland”).

In with the new, but do keep the old!

I applaud Ubuntu’s efforts to come up with new ways of interacting with “The Machine”.

The HUD has the potential to combine the best from advanced search technologies like Apple’s Spotlight, smart command line interfaces like LaunchBar or Quicksilver, and new ways to access an application’s menu commands into a single, extremely powerful, yet usable interface element.

Shuttleworth is probably right when he claims that:

> the HUD is faster than mousing through a menu, and easier to use than hotkeys since you just have to know what you want, not remember a specific key combination.

Conversely, though, the HUD isn’t easier to use than a menu nor is it faster than hotkeys.

To use the HUD effectively, you need to have an understanding of which commands it understands, whereas you can browse (and sometimes search) a menu for the commands and functions it makes available.

And while you have to memorize a hotkey in order to you use it effectively, it is much faster to access than entering a command via the HUD.

Therefore, I hope the powers that be at Ubuntu will revise the decision to completely tear out the support for classic menus from their operating system.

Instead, they should let your users decide whether the menu bar is displayed in its standard on-screen location, whether it’s stashed away in the panel, or whether it should be fully hidden from the user’s eye.

Sometimes, new ideas aren’t good enough to fully replace the old ones. But, more often than not, they’re just right to complement and extend them.

The New York Times has all the details.

The incident received lots of attention on the Internet, with many a commenter accusing the iPhone’s owner — who has kindly been anonymized as “Patron X” — of being simply too stupid to use a “smart” phone.

As a user interface designer, you can view this unfortunate incident as a real-life usability test. And the iPhone failed this test. Yes, the phone failed, and not the user.

The iPhone fails a usability test

Here is a key passage from the New York Times article:

[Patron X] said he made sure to turn [the iPhone] off before the concert, not realizing that the alarm clock had accidentally been set and would sound even if the phone was in silent mode.

“I didn’t even know phones came with alarms,” the man said.

This user was expecting the mute switch to completely silence the phone.

Since he had just gotten the iPhone the day before the concert, he had to rely on his intuition to make sense of the device’s controls and related on-screen messages.

The mental model he came up with for the mute switch was very simple: “This thing switches the phone’s speaker on or off.”¹

His exact thoughts might have been different, but the important part is that he was not expecting the general function of the switch to be any more complex than that.

“It’s ‘all sounds on’ or ‘all sounds off’. Got that!”

This is a perfectly sound expectation of how the mute switch works. Here’s is the reason why: There is no indication in the iPhone’s UI that would contradict this straight-forward expectation. I’ll explain that in a minute.

A conflict of expectations, not a conflict of commands

Marco Armend is among those who disagree.

He argues that the iPhone switch works just as it should, and offers this explanation for what went wrong (emphasis his):

The user told the iPhone to make noise by either scheduling an alarm or initiating an obviously noise-playing feature in an app.

The user also told the iPhone to be silent with the switch on the side.

The user has issued conflicting commands, and the iPhone can’t obey both.

Alas, he’s wrong. Well, kind of.

Marco takes the point of view of a programmer. From that perspective, there are, indeed, conflicting commands that the designers of the iPhone’s user interface had to foresee and address.

Keep in mind, though, that Patron X was not only not aware that an alarm had been set unintentionally in the iPhone’s Clock app.² He claims that he did not even know that that feature existed on his phone.

The expectation of the user clearly was this: “When I flip this switch, the phone won’t make any noise whatsoever during this concert.”

Therefore, from the user’s perspective, only a single, non-ambiguous command was given: Stay quiet, no matter what!

This is not a case of conflicting commands. Instead, it is a matter of conflicting expectations of how the device operates, or should operate. A classical example of the user’s mental model not matching that intended by the device’s designers.

Managing user expectations through status visibility

According to page 11 of the iPhone User Guide (iOS 5 version), the “Ring/Silent switch” operates as follows:

In ring mode, iPhone plays all sounds. In silent mode, iPhone doesn’t ring or play alerts and other sound effects.

Important: Clock alarms, audio apps such as Music, and many games still play sounds through the built-in speaker when iPhone is in silent mode.

Alas, the iPhone’s user interface does not make the user aware of these exceptions at all.

To understand the behavior of the mute switch, you must read the user’s manual. And to apply this understanding, you have to memorize it.

Let’s put this into perspective: A premium “smart” mobile phone whose user interface is considered by some to be the epitome of user-friendliness, requires you to memorize configuration details, because the device does not properly communicate its system status.³

If you take a closer look at the status feedback the iPhone provides with regards to the mute switch, you will find that they do not take alarm settings into account.

When you mute the phone, you feel a single vibration burst, and this info bezel appears on the iPhone’s screen:

Un-mute the iPhone, and you get to see this (without any vibration):

The only setting I could find that affects this behavior is the Vibrate option in the Sounds settings. Un-check that option, and the vibration feedback is now reversed: the phone vibrates when you un-mute it, and stays quiet when you mute it.

The icons shown above look exactly the same, however, regardless of whether an alarm is set, or not.

There is an indication that an Alarm may sound: the clock icon in the status bar. Similar to the bell icons, however, it also has the exact same shape and color, regardless of whether any of the active alarms will actually “make a noise”.

Therefore, if you absolutely, positively must make sure that your iPhone stays quiet while it is muted and the Alarm icon is showing, you will need to open the Clock app and check the list of alarms.

Which list, by the way, again fails to provide visual cues as to which alarms have a sound assigned to it, or which are vibration-only. You can only check this by entering edit mode, tapping an alarm, and checking the Sound setting. Seeing a corresponding icon right in the list items would be useful here.

Of course, you can switch the iPhone off completely, but that would make the very existence of the Ring/Silent switch rather moot. It would also prevent you from quickly looking up a piece of information on the iPhone due to the time it takes the iPhone to cold-start. And if you did do so, you may just be surprised by an alarm going off the moment your log-in screen appears …

As a third option, you could try to memorize which alarms you have set for which times, and whether any of these will play a sound, or not. That is a “suggestion” that you hear a lot from the commenters attacking Patron X over his mishap: “He should have remembered that he had set an alarm that would go off during the concert.”

I cannot begin to explain how stunned I am by these people’s notion that it is perfectly acceptable for a high-tech 21st-century digital device to offload memorizing system status information to its user in this manner.

When designers do not expect their user’s expectations

Given that the iPhone does not present any status feedback — neither visual, nor audible, nor tactile — that it may play a sound while muted, and that a simple control for a simple function should cause the least possible surprise when operated, I think it is perfectly valid and appropriate for a non-expert user of an iPhone to expect the mute switch to work exactly like Patron X thought it would.

I’m not arguing that this simplistic behavior is the most appropriate or the most useful for average users, mind you!

What I am saying, though, is that it is be the most intuitive behavior, i.e., the behavior that a non-expert user would most likely expect to see.

Do tell, little iPhone, what are you up to?

Without hands-on user testing, it is not possible to say which changes to the iPhone’s UI would have been necessary to prevent Patron X from making his mistake.

I have no doubt, though, that more explicit status feedback would have helped immensely.

For example, the “muted” status bezel could display a warning in case an alarm is active that may play a sound.

For those of us who toggle the Silent mode with the device in their pockets, the iPhone could play different vibration patterns in response to flipping the mute switch.

I assume that the tactile feedback from physically flipping the switch provides sufficient status information about what that switch has been set to. Hence, I don’t think the reversal of the vibration pattern when de-activating silent-mode vibrations is necessary⁴.

User-testing notwithstanding, the vibration patterns could be modified to vibrate once when the phone is un-muted, stay quiet when it is muted, but vibrate thrice when the phone is muted while alarms with sounds are active.

In other words, “no vibration” means “no sound”. Both vibrations mean “sounds will play”, with the triple-vibe effectively operating like an exclamation mark: “Are you trying to silence me? Well, you better BE AWARE THAT I MIGHT PLAY SOUNDS, you know!”

“Least surprises” is good default behavior

When it comes to making decisions about a system’s default behavior, the “Principle of Least Surprise” is a useful guideline.

In my opinion, the ”Incident at Avery Fisher Hall” is a sign that Apple’s design of the default behavior of the mute switch violates that principle.

Besides adding more explicit status indicators as outlined above, the — again: default — behavior of the mute switch should be to silence all of the phone’s sounds without any exceptions.

To allow users to customize this behavior for their personal preferences, I would test adding an option — “Play sounds in Silent mode” — to the Notification settings.

Every app that can play sounds while the phone is muted, would gain this override option, with its default setting being “Off”.

With a standardized UI for this behavior, the user would have to learn how to set this option for one application in order to understand how to set it for any and all others.

It would also get rid of the guesswork involved with the current design’s imprecise list of “Clock alarms, audio apps such as Music, and many games” by supporting a clear, unambiguous selection of which apps will blare away even during “silent” mode, and which are muted for good.

For the users, however, these manuals come at a price. They can be more tedious to navigate than a single-language document, and they require more storage space.

When I recently unpacked an electronics gadget, the manual inside the box was folded into a dense, almost children’s fist-sized wad of paper.

At first sight, it reminded me of an oversized version of the information flyers that you find in medicine packages — and whose folding pattern is so complex that you can never get it back into the box.

Unexpectedly, the wad unfolded into several individual double-sided sheets, each of which contains instructions in two languages.

Two perforation lines run from top to bottom along the sheets’ centers.

Thanks to the perforation, you can rip each sheet in two, so that you end up with a customized manual that only contains instructions in your own language.

This design is a double-edged sword, because you throw away the majority of the printed document, so that the waste of resources — paper, ink, and energy — is the same as with bound booklets.

Customizing the document in this manner does make it more usable, though, because it reduces its content scope and physical size to just exactly what you need.

I wonder if there is a way to apply this approach to larger documents whose contents exceed a single page per language.

As another advancement in this field, Apple introduced a novel UI element in OS X 10.7 Lion: The so called “search token” aims to simplify compound searches.

Entering compound file searches

A compound search combines searches across several metadata fields to fine-tune the list of resulting matches.

For example, to find all presentations about Mac topics from this year¹, you might look for files whose …

• kind is (Keynote) presentation,
• date is this year, and
• contents include “Mac”.

Previous versions of Mac OS X offered two methods for entering this kind of search. The more efficient one uses Spotlight with search operators like “kind:” or “date:”.

To run the example search, you would enter “kind:pdf date:2011 mac”² into Spotlight’s search field.

Apple has published a complete list of Spotlight operators as well as further information on how to use Spotlight operators on their support website.

Besides having to remember which operators are available, and what their correct spelling is, you must know about this Spotlight feature in the first place. The chance of accidentally discovering it is very slim.

The second method for entering a compound search is by using the metadata fields in the Finder’s search window.

While entering a search this way is not as efficient as using Spotlight operators, it is much easier to discover, and the menus provide a built-in reference for the searchable file attributes.

The best of both of these methods has been combined into the new “search tokens”: Pure text entry and a menu of search suggestions.

Entering compound file searches with tokens

As soon as you start typing something into a Finder window’s search field, a menu pops up. Its contents are grouped by the metadata fields in which your search string was found.

When you see what you’re looking for, you select its menu item with a mouse click or via the cursor keys on your keyboard. There is no need to switch between keyboard and mouse while you refine your search.

When you make a selection from the menu, the search is encapsulated in a lozenge-shaped token, which combines your search term with the metadata field within which the search is performed.

After adding a new token, you can continue typing to further refine your search.

Unfortunately, the search field has a maximum width of about 35 characters, regardless of how you configure the toolbar in the Finder windows.

On average, this should be sufficient room for two or three search tokens. If you enter a more complex search, however, you cannot see the entire set of criteria at a single glance anymore.³

Combining the best of both worlds — and adding a caveat

Entering compound searches with the new search tokens merges the efficiency of typing into a text field with the discoverability of a menu.

Thanks to the tokens, you need to type even less than if you used Spotlight operators. That’s because you only need to enter the search terms, but not the operators themselves, as you pick these from the menu.

Besides the limited space in the search field, the current implementation of search tokens has one caveat: They only support a small subset of all available file metadata fields. Many more are available in the search section underneath the Finder windows’ toolbar.

Despite these shortcomings, the search tokens make performing compound searches of medium complexity more convenient and more efficient than either of the older methods.

In order to force-eject such a rogue disk, you have to restart the Mac and hold down the mouse button during the boot process. Before the log in screen appears, the disk will pop out of the drive.

This brute-force method has worked for me every time I used it, but it is massively disruptive.

Imagine doing creative work on your computer. You have meticulously arranged numerous windows from multiple applications into a super-efficient workspace.

And now you have to close all apps and shut down the entire machine, just because the OS does not properly recognize a CD.

Insane!

You can’t select what isn’t there, …

Why won’t the OS let me select some icon in the Finder and then execute the Eject command? Well, if there is no icon that represents the disk in the drive, how would you select it?

Part of the problem is that the Mac’s Finder differentiates between a (physical) drive and the (logical) volumes stored on that drive. This differentiation also applies to drives with removable media.

In the Finder you will only see icons representing volumes, but none for the physical devices. This is different on Windows.

On Microsoft’s OS, icons for drives with removable media like CD/DVD drives, etc. always appear, regardless of whether there is a medium inside that drive, or not.

In everyday use, there is a drawback to Microsoft’s design, because if you select such a drive while it’s empty, Windows will still try to read from it.

It takes a few seconds until the system recognizes that there is no medium inside the drive, and during that time you cannot continue working inside the specific Windows Explorer window. Which makes inadvertently clicking on an empty drive’s icon rather annoying.

… or can you?!

There is one application on the Mac, however, that does let you access physical drives: Disk Utility.

As you can see in the screenshot, the Finder only displays the volume — “Beyond Tomorrow” — for the computer’s internal hard drive.

In Disk Utility, in contrast, you can also access the physical hard drive as well as the optical drive. The latter is grayed out, since there is no medium inside.

This application would be the logical place for offering an Eject command that operates on the drive, not the medium. Such a function would force-eject whatever is inside the drive, regardless of whether the Finder has properly recognized it, or not.

In fact, this function should probably be deactivated, unless the Finder failed to recognize the disk, so that the user has to properly eject mounted disks to avoid data loss.

Then again, most users will have no need to ever use the Disk Utility application. They may even be scared by it due to its deep-down-inside-the-drives’-guts functionality.

A rare specimen: the non-evil time-out

That’s why I would like to see a different solution to this problem: A time-out!

As much as I loathe user interface time-outs in general, it would make a lot of sense for the computer to automatically eject a removable medium, if it is not recognized within a few seconds after it has been placed inside the drive.

Add in an error message window that informs the user, why the disk has been ejected, and you have a very user-friendly solution to an as-of-yet nasty problem.