Programming the iPhone : UX Anti-Patterns - Sleight of Hand

10/3/2012 2:20:49 AM
The layout of Cocoa Touch user interfaces can have a big impact on usability. This is especially true in regards to user interface controls. A control is any interface element that causes the application to do something when a user touches the screen. Standard controls include buttons, sliders, and switches. Table cells can act as controls, as can entire views.

The Multi-Touch interface on the iPhone and iPod Touch requires that applications implement virtual controls. Unlike physical knobs or buttons, virtual controls provide no tactile (or haptic) feedback. A great example of tactile feedback on a hardware control is the raised bumps on the F and J keys of a standard English QWERTY keyboard. These bumps indicate to users that their fingers are in the proper place on the keyboard. On a touchscreen, muscle memory is built with repeated use, but orientation is based purely on the portion of the screen a user is touching.

The sleight of hand anti-pattern occurs when developers change the perceived meaning of a touch-sized area of the screen by placing controls that perform different actions in the same place across views.

Apple provides a good example of the sleight of hand anti-pattern. The iPhone displays one of two screens in response to an incoming call. In both scenarios, the screen shows the name of the caller and, if available, a photograph assigned to the incoming phone number. If the iPhone is locked, users see a large slider labeled “slide to answer” and a slider handle that moves from left to right. Sliding will unlock the phone and answer the incoming call. Figure 1 shows the incoming call screen on a locked iPhone.

If the phone is unlocked, the screen shows the same standard incoming call screen but replaces the large slider with two buttons: one to decline the call and one to answer the call. The Decline button is on the left, and the Answer button is on the right.

In this example, the sleight of hand occurs when a user who often keeps his phone in a locked state receives a call when the phone is in the unlocked state. The user is probably trained to touch the left side of the screen and quickly swipe to the right to answer a call. This causes problems when the phone is in an unlocked state because the user will instinctively touch the lower left part of the screen, inadvertently hitting the Decline button.

Figure 1. An incoming phone call on a locked iPhone

The sleight of hand anti-pattern commonly appears in navigation controllers. When working with a navigation controller, a user will often tap the upper left area of the screen multiple times in quick succession to move up a hierarchy of information. Users learn to perform this type of operation because so many applications use Apple’s navigation controller design pattern to display hierarchies.

Navigation-based applications use a navigation bar at the top of the screen. The navigation bar usually has a button on the left that takes a user up one level, assuming she isn’t already on the topmost or root level of information. If a user is on the root level, the left button area of the navigation bar should probably be empty to keep users who repeatedly tap a back button from accidentally performing an action due to a control taking the place of the button they are tapping.

Figure 2 shows the sleight of hand anti-pattern in the Facebook application. Tapping the “Photos of Toby” item shows the “Photos of Toby” second screen. The “Toby” back button on the second screen transitions the user back to the first screen and swaps the back button for a Logout button. An extra tap on the top-left portion of the screen can trigger the logout process. The Facebook application handles this well by requiring a user to confirm that they wish to log out, but the issue could be avoided completely by moving the Logout button to the right side of the navigation bar.

This can be a tough pattern to avoid because there may be perfectly valid reasons for a control taking a particular spot on a particular screen. Designers can find balance by looking at how users interact with an application holistically instead of designing layouts as a set of decoupled screens.

Figure 2. A sleight of hand in the Facebook application

Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8