• Reliability: Operations should work. Period. And events should not happen randomly.

All of these principles are rapidly disappearing from designers’ tool kits, aided, we must emphasize, by the weird design guidelines issued by Apple, Google, and Microsoft.

What are we talking about? Let us explain.

Visibility

Nonexistent signifiers. To delete an unread message in Mail on the iPhone, swipe right across the unopened mail and a dialog appears, allowing you to delete the item. Open the email and the same operation has no result. In the Calendar, the operation does not work. How is anyone to know, first, that this magical gesture exists, and second, in which settings it operates?

With the Android, pressing and holding on an unopened email brings up a menu that allows, among other items, deletion. Open the email and the same operation has no result. In the Google calendar, the same operation has no result. How is anyone to know, first, that this magical gesture exists, and second, in which settings it operates?

Whenever we discuss these examples with others, we invariably get two reactions. One is “Gee, I didn’t know that.” The other is, “Did you know that if you do this [followed by some exotic swipe, multifingered tap, or prolonged touch] that [the fol-lowing] happens?” Usually it is then our turn to look surprised and say, “No, we didn’t know that.” This is no way to have people learn how to use a system.

Misleading signifiers. For
Android phones, there are four
permanent controls at the bot-
tom of the screen: back, menu,
home, and search. They are
always visible, suggesting they
are always operative. True for
three out of the four—not for the
menu button. This visible menu
button implies there is a menu
available, but no, many applica-
tions (and places within applica-
tions) don’t have menus, and
even those that do don’t always
have them everywhere. There is
no way to tell without pushing
the button and discovering that
nothing happens. (Actually, it
means multiple pushes because
the lack of a response the first
time may reflect the unreliability
of the technology.)

Feedback

Both Apple and Google recom-
mend multiple ways to return to
a previous screen. Unfortunately,
for any given implementation,
the method seems to depend
upon the designer’s whim.
Sometimes one can swipe the
screen to the right or downward.
Generally, one uses the back
button. On the iPhone, if you are
lucky, there is a labeled button.
(If not, try swiping in all direc-
tions and pushing everything
visible on the screen.) With the
Android, the permanently vis-
ible back button provides one
method, but sometimes the task
is accomplished by sliding the
screen to the right. The back but-
ton has a major flaw, however.
Push the back button to go to the
previous page, then again, and
then again: Oops, suddenly you
are out of the application, never
having been warned that the
next button-push exits instead
of simply going back. (The same
flaw exists on the Blackberry.)
The back button moves the user
through the “activity stack,”
which always includes the origi-
nating activity: home.

 

Consistency and Standards Whatever happened to the distinction between radio buttons and checkboxes? Radio buttons meant selection of only one out of all the possibilities: Selecting one precluded the selection of others. Check boxes, however, allow one to select multiple alternatives. Now, with these new systems, check boxes can work any

September + October 2010