Posts Tagged cell phones

Inconsistencies in Deleting Objects on the iPhone/iPod Touch

Posted by jasonwong in bad design, training, user testing on June 29th, 2008

Transfer of training is the concept that if you learn how to perform a function in one context, learning is much faster to perform the same function in a different context if the actions are the same. For example, copying and pasting is the same between Microsoft Word, Notepad, Adobe Photoshop, and others – Control-C and Control-V. These conventions are created through traditions and user interface guidelines, such as Apple’s Human Interface Guidelines for OS X and the iPhone. Consistency is good: users learn an action once, and it can be applied everywhere. Transfer of training.

However, the iPhone/iPod Touch interface has several glaring inconsistencies. One is how to delete objects. What’s been touted in Steve Jobs’ presentations has been swiping your finger across an object to delete it. For example, in Mail, the user swipes their finger across a message, and they get:

Then, they press delete, and it’s done. Simple enough, once users learn the finger swipe action.

This is almost the same with deleting a video. The finger swipes across a video and the red Delete button appears, but there’s a second confirmation:

This is not too drastic of a change, and adding a confirmation is not necessarily a bad idea, especially when it’s so obvious as to which buttons do what.

However, trying to delete a bookmark in Safari requires not only confirmation, but trying to guess at the meaning of buttons. The user brings up the bookmarks list, and a finger swipe does nothing. Instead, there is a button on the lower left labeled “Edit,” which does not evoke the “Delete” action at all. Once the user finally presses “Edit”, they are presented with little red circles to the left of the bookmark. It is important to note that this iconography is not used anywhere else in the interface. Finally, once the user clicks on the red circle next to the bookmark, they see the familiar red “Delete” button. Whew, that was different.

Moving on to the Notes application, however, shows a major breakdown. This, in my opinion, is the worst offender of implementing the delete feature. Deleting a note does not involve a finger swipe or an “Edit” button. Instead, to delete each individual note, they must be opened one-by-one. Of course, there is no indication of this. Once the note is opened, the user is presented with:

Suddenly, there is a Trash Can that is assigned the Delete command. More iconography that is never used in the iPod Touch interface, despite its familiarity to the user.

Yes, the iPod Touch interface is very new, but Apple is known for its consistent and intuitive user interface. This is an example of a total disregard for consistency in Apple’s shiniest new product, and it detracts greatly from the usability of the iPod Touch. Every computer user knows how to Copy and Paste, because the keystrokes are the same across applications. But when something as simple as a Delete command takes on four different implementation in four applications on a system, there is a problem. Apple desperately needs to standardize their interface to make transfer of training much easier from one iPod Touch application to the next.

,

No Comments

Animations and the iPhone

Posted by jasonwong in data visualization, good design, perception on June 24th, 2008

Animation in computer interface has been used for as long as the technology has been able to support it. The infamous “Clippy” in Microsoft 1997-2003 is an example of that. However, Clippy was almost universally despised because the animations tended to slow down completing a task. Even worse, when the user is idle (possibly thinking about something), the on-screen character would do a little dance, providing a distraction. No wonder why Clippy was even hated by Microsoft.

Animations can be useful, though, in the right context. On the iPhone/iPod Touch user interface, there are several examples of animations providing information about the state of the interface. This video below (created by me, which explains the awful production values), shows two instances of this. One is zooming and scrolling during navigation in Maps, and the other is scrolling in Safari, the web browser.

These animations naturally fit in the interface; they are not superfluous like Clippy. The zooming and scrolling in maps provides information about location and space. As users progress through the fake turn-by-turn directions, Maps could simply display the next turn. Instead, Maps zooms out from the old location and zooms in to the new location. This provides the user with a sense of where they are in the global sense, but also where they’ve come from in the relative sense (“We’ve driven very far southeast.”) This is useful in giving users a sense of situational awareness about the state of their trip.

The Safari animation is much more subtle – you scroll a page by tapping on the screen with your finger and dragging. When you reach the top or bottom of a page, trying to scroll more gives the user the sense of dragging the whole window, which visually implies to the user that there is no more to see. This is incredibly smart for this interface. In a regular computer interface, scroll bars are used to give the user a sense of position in the document. Scroll bars would not fit well in the iPod Touch interface, however, because many users would feel they had to use this bar to scroll, and the finger is not precise enough to grab a narrow area like that. Instead, the iPod Touch uses the entire screen as an effective scroll bar.

The downside to this is that there is no indication of document position, which is especially crucial at the top or bottom of the document. If the user is at the bottom but thinks there is more to see, the user may try to scroll. If the animation was not present and the interface did nothing, it would look like the scroll command performed by the finger did not register. This would prompt repeated actions by the user, all met by silence from the interface. Instead, this natural “rubbery” action by the interface signals that there is no more document to see. It’s natural, informative, and unobtrusive, which makes for an excellent use of animation.

,

No Comments

iPod Touch User Interface: Touch controls

Posted by jasonwong in good design, training, user testing on June 15th, 2008

I know I’m extremely late to the party, but I just got myself an iPod Touch. It is quite impressive, and one of the major aspects of the user interface that I love so much is how intuitive the touch-based action gestures are. Being intuitive is hard to define, but I like to think that if something is intuitive it appeals to common sense.

The touch controls are something that have been highly touted and are well-known at this point. In order to zoom in on a location in Maps, a photo, or a web page in Safari, you put two fingers around the location you want to zoom in on, then you bring them closer together. This is known as the “Pinch.” Conversely, to zoom out, you spread your fingers apart (the “Anti-Pinch”?). Finally, to move around the map, you simply press your finger against the screen and move it in the direction you want the map to go.

This is an example from the Mobile Safari web browsing application:

These actions seem so intuitive that they elicit a reaction of “Well, obviously!” from many people. However, this is not one of those times when common sense would seem to point to these gestures. This seems to be more a function of hindsight bias (hindsight is 20/20) than anything else.

For example, the simple “pulling” action to scroll around in the Maps application is the most intuitive, gestures. This is so intuitive, in fact, that I find myself trying that with other map programs. Google implemented this first with their web-based Map application (so this was not an Apple invention). However, other companies have simply not caught on – MapQuest, for example, does not implement this feature. My GPS (a TomTom Go 720) has not, either. When I want to make sure the route it is giving me is correct, I want to be able to grab the map and scroll to get a better sense of where the route is taking me. Instead, the GPS thinks I tapped the screen, which brings up a different part of the interface. I am left unsatisfied.

The zoom controls are another aspect of the interface that are intuitive. I don’t find myself trying to pinch and anti-pinch on other interfaces. Instead, I am satisfied with a zoom bar (pictured below) or using a scroll wheel to zoom in and out.

The biggest reason for this is that zooming on the iPhone/iPod Touch requires two fingers, and there is no way to emulate that using the input devices available to modern computers. However, the iPod Touch pulls it off quite nicely, and it is continually impressive to show off. The master, Steve Jobs, certainly impressed the crowd when he introduced the iPhone:

What this all boils down to is ease of use, which can be split into two parts. One is ease of learning, which is what intuitiveness is all about. A shallow learning curve for these gestures means they are grasped easily. This then improves information retention, the second part of ease of use. Users remember what action to perform to reach a desired state, and they perform the action admirably.

Compare this with a new computer user learning Copy and Paste. Click + Drag over text, choose one of 50 different commands that let you copy (right-click, the Copy button in the toolbar, the Edit menu, a keyboard shortcut…) and then repeat for paste. The learning curve is somewhat steep, and the retention of information is not all that great.

The iPhone/iPod Touch, however, gets it right.

,

No Comments

Sprint Mogul: Button placement issues

Posted by jasonwong in physical ergonomics on January 2nd, 2008

My old phone (the Sprint PPC6700 – a catchy name!) died recently, and Sprint was courteous enough to replace it with the new version, the Sprint Mogul. Here are the two phones for comparison (the PPC6700 is on the left and the Mogul is on the right).

PPC6700PPC6800

The Mogul is a great phone. It runs Windows Mobile 6, which is significantly less prone to crashes than Windows Mobile 5. It’s slightly thinner and much lighter, making the phone actually bearable to carry around. Another nice feature of the Mogul is the inclusion of a scroll wheel, which lets you scroll through lists simply by rolling the wheel. In order to make a selection, you press down on the wheel. Handy.

Well, almost handy. The scroll wheel is on the left side of the device and on the right side, nearly at the exact same height, is the power switch. Now, when you’re using the device one-handed, you can’t really just press one button. You have to effectively pinch the phone. When I pinch the phone using my middle finger to press down on the scroll wheel, I often pinch down on the power button with my thumb. So I make my selection and also turn off the phone at the same time. Whoops.

Note where the scroll wheel and the power button on – virtually parallel on the left and right of the phone:
Mogul Left
Mogul Right

The power button for the PPC6700 was on top where it was not in the way but still not difficult to get to. I wonder why they moved it? Admittedly, not everyone holds their phones the way I do, but it sure is inconvenient! I wonder if the issue ever came up in user testing?

No Comments