I recently discovered that in iOS, you can delete a table row by making a slash (i.e. /) gesture over the row. I didn’t figure this out on my own; I read about it while studying the iOS SDK. This gesture only works with Cocoa Touch tables of a certain type, so not every row in every table in every app will support this gesture.
I made a similar discovery in Android, namely CyanogenMod (@cyanogen). In the notifications pane, swiping horizontally across a notification dismisses it, a very useful addition to stock notifications, which do not support clearing single notifications without opening the notifying app. This gesture only works with CM7, not any other variant of Android.
Gesture-based software has lots of these features. I’m going to call them Easter Eggs, even though many are actually documented, if you can find the documentation. Let’s face it: no one reads the documentation in full before diving into a new device. Apple doesn’t even ship a user guide anymore because “you already know how to use it.”
This assertion is essentially true. Features like the slash-to-delete gesture are augmented with clear buttons, but if you subscribe to Don Norman’s view of design affordances (or more accurately perceived affordances), you’ll be wondering why these features are included at all if they’re imperceptible.
In a nutshell, affordances let the user know some action is possible, e.g. a door with a handle or a button with a label.
Neither of the gestures I mention above has a perceived affordance; they just happen if the user makes the gesture, leaving the user surprised and frequently unable to duplicate the behavior.
So, kind of like finding an Easter Egg, but in a bad way, if you’re building UI or designing UX.
The problem is that including affordances on mobile can be difficult because you have a smaller screen, less memory at your disposal and many other device restrictions.
Plus, because iOS and Android are so new, they lack a standard set of conventions and perceived affordances that developers can use as a starting point. Sure, Apple provides guidance with the Human Interface Guidelines. However, developers aren’t required to follow these guidelines, and Apple’s own HIG includes Easter Egg features like slash-delete, which only encourages developers to build without affordances.
There are clever ways to include affordances, but many still end up feeling like Easter Eggs. Within the first few hours using Chrome OS on my Chromebook, I noticed that some of the tabs had a very subtle glow moving right-to-left across the top. These were tabs with updated content, e.g. GMail, Google Reader, Twitter. Now, I’m not a huge fan of adding badges to everything like iOS does, but when you compare the two affordances, the latter is much more obvious.
So, sometimes affordances can be a bit too precious.
Mobile development is new ground, and very few expectations exist for users, at least compared to what they expect from within a browser. This is one reason why the average user has so much trouble switching from iOS to Android or vice versa. So many things seem to be the same, but there are so many differences.
And this isn’t limited to the differences between the OSes. Apps build by the same development shops for iOS and Android behave differently as well, creating confusion. The one broad exception is games, and there’s something key about that. Gameplay must be the same on all platforms to retain players.
Developers building other types of apps should take this cue from game developers. Even if the platform is different, make your app behave the same.
Anyway, if you’re interested in this kind of stuff, read the Nielsen Norman Group’s iPad usability studies and subscribe to Jakob Nielsen’s Alertbox.
Thoughts of mobile’s lack of affordances? As a user, do you even care?
Find the comments.
