Beachballin’

The iPhone’s Moving Target Problem

I’ve said this before, and probably will a dozen times again in the next month, but I love my iPhone. Still, I wouldn’t be a good geek if I didn’t think about problems and how they could be resolved, and how things could work better. The latest problem that I’ve been thinking about is what I call the ‘moving target’ problem.

I first noticed this issue with Safari, and I’ve found it’s fairly easy to reproduce - since it happens to me up to a dozen times in a ten-minute interval. First, a brief example of when you might see the moving target problem.

1. Visit a page on the web somewhere that takes a few moments to load. It doesn’t have to be a long time, but it can’t be instantaneous. I’ll use Digg’s mobile site as my example.
2. Tap on a link to visit the target page (in Digg’s case, the article detail page). Once the page has finished loading, tap the ‘back’ button.
3. As soon as the previous page (the main index) is visible, you will be able to scroll it. Do so, moving either up to the top or down to the bottom, and then pick any random article, and notice where on the screen it is.
4. Once the page has finished loading (indicated by the blue progress bar behind the address bar), you will see the ‘moving target’ effect. Safari will jump to the position it was in when you tapped on the FIRST link and left this page originally.
5. There is a brief moment where tapping on the screen on the second article will not be registered until AFTER Safari ‘jumps’ back to where it was. In conjunction with the delay between choosing a target (in your head) and tapping the target (the moment your finger hits the screen), you may see the ‘moving target’ issue manifest - you will tap one article, but Safari will register the tap on another, and take you to the page accordingly.

The part that I find most annoying is that it’s so reproducible, but also that in this example, it’s almost self-causing, if you will. Think about it - the user has just inadvertently tapped on the wrong article, and the wrong page is loading. Their first reaction (if they notice right away that it’s highlighted the wrong link) is going to be… to hit the back button and tap the right link. The problem, of course, is that that’s where the moving target problem happens. They’ll know what they want to see, so they won’t have to think about it. The page won’t finish loading right away, they’ll scroll, tap, and end up with another (or the same) wrong article.

The problem happens less frequently, but more frustratingly, with Mail as well. When the user opens mail, they immediately get a list of all the mail my iPhone knows about (or rather, the first 25). The phone, however, immediately checks the server for new mail and fetches it if it exists. The most recent message is now the eighth most recent message, and is shoved down off the bottom of the screen to make way for the new messages, and here, again, the user is given a prime opportunity to trigger the moving target problem. Interface lag plus human lag means that you have a chance to end up tapping on the wrong e-mail, and then furiously tapping on the ‘back’ button to try to return to where you were.

In terms of solutions, there are a few things that could be done to solve the problem in various ways.

Safari already stores the location it was scrolled to, and the instant it begins rendering the page, sets the scroll to that position, but it also does this when it’s done loading. Presumably this behaviour is to work around the problem that the page as the browser knows it can change - a small ad at the top of the page could turn into a larger ad, and suddenly the content of the page has moved downward by a paragraph. On a desktop machine, this is less of an issue, but on a small screen, it’s easy for the user to lose their place. The best solution here would be for Safari to avoid the second ‘jump’ if the user has changed the scroll position. The assumption here is that if they’ve moved the view, they’re either looking at what they want to see, or they’re interacting with the device and will likely not appreciate it changing the view out from under them.

Mail has a slightly more complicated problem, in that the application isn’t doing anything wrong necessarily. It’s displaying a list of messages, and if the list changes so should the display. Again, this could be mitigated by being aware of when the user is interacting with the screen and changing the display accordingly. If the user is scrolling, or has scrolled recently, then add the messages onto the top of the list, but keep the view in the same position, displaying the same messages. This should be relatively easy to do, since all entries in the message list are of the same height. A simple action to prepend the messages and simultaneously ‘move’ the view to point at the same messages as before should be relatively seamless to the user.

There is another problem here, and that’s the pervasive issue of interface lag. This happens in every OS on every platform, and isn’t an easy one to solve. The issue generally arises when the system is unable to process user input, so it queues the input up to be handled. When the problem is resolved, all the input is processed in the order it was received. Thus, if I had typed this entire paragraph while the system was frozen or lagging, then when the problem was solved all of my keystrokes would be played forward.

The problem comes when we realize that we’re in a world of windows, menus, and pointers. If a system freezes up, the user may become frustrated and click randomly around the screen, or attempt to perform the same action repeatedly. When the system becomes responsive again, their actions are played forward, which results in them clicking on (for example) a menu, a menu item, an icon on the dock, a close button, a minimize button, the ‘bold’ button on the toolbar, several other applications, links on a webpage, and so on. Suddenly their desktop devolves into chaos, and they’re forced to clean it up. Hopefully nothing irreversible has happened, but it’s impossible to tell.

This is a more difficult problem, because it makes the queueing much more complicated, and it’s a problem that has not been solved appropriately by any platform I’ve used. The simplest method, which tends to cause the least frustration, is to simply drop whatever the user had attempted to input, with the logic that the aforementioned chaos is going to occur, and is almost definitely not what the user wants. This generally solves the problem in a reasonable manner, and while it’s frustrating to be forced to re-input your commands, this is basically what the users are trying to do anyway, and we can judge from their behaviour that it is the response they are expecting. In the case of typing, it becomes an issue when the system momentarily pops out of its funk and then back into it, and you end up with disjointed fragments of whatever the user was attempting to type.

Another method of dealing with the issue, and one which I think would be most effective but which would be most beneficial to the user, would involve tracking not just the user’s input, but what the user was trying to do, and this will probably require explanation.

Let’s say my system has just frozen up, and I haven’t realized it yet. I click on a title bar and drag it up and to the left, and then release, before I realize that nothing’s happening. I try again, clicking in roughly the same spot and dragging to the same spot again. Maybe I do this three or four times. When the system ‘wakes up’, it will register the first click-drag-release event, and move the window. It will then register the second click-drag-release event, perhaps selecting some text inside of the window, and then it will register the third, possibly dragging and dropping that text elsewhere in the document, or into another application entirely.

A better way to do it would be for the system to notice when the queue is unusually large (even one or two pending events) and to begin tracking what the user is actually trying to do with those events, one by one. In this example, it sees that the first click-drag-release was on the title bar of the active window, and so it moves the window. It then looks at the second event and sees that the click was in roughly the same spot. Here, it sees that when I clicked, what I was actually trying to click on was the title bar, which has moved. Because this is an invalid action (because the state that my action relied on has changed), it throws the action away.

Not all actions would need to be thrown away. For example, if a user clicks a certain location on the screen which, at the time of their click, was a window’s close button, the system could close the window, even if the window has since been obscured by another window, a pop-up, or so on, because nothing about the target has changed.

I’m no UI developer or programmer, and I should stress that there are a lot of complex issues around UI design. Fixing more problems introduces more complexity, and there’s a fine balance between frustrating professional users and confusing novice ones. Apple isn’t perfect, but they’re striking a decent balance so far. Still, there’s a lot of work to do. 

Irony…

So here’s irony for you.

Apple’s been making inroads in homes, huge inroads in schools, and some inroads in business - but not in the ‘enterprise’. Why? It’s almost as though Apple is ignoring enterprise customers entirely. They have features that make it easier to manage larger amounts of Macs, but it’s still not a done deal. It’s as though they’ve only been making a token effort, ignoring the realities that businesses face. For example, OS X works well with ActiveDirectory, but not with Exchange support - unless you buy Entourage, which isn’t a very good program at all, to be honest. Now, however, with Microsoft’s help, Apple is poised to replace Windows on the desktop in large corporations as well, cutting Microsoft’s revenue stream off at the knees.

› Continue reading

Mac Keyboard Shortcuts

There are a lot of shortcuts in OS X that no one seems to know about other than by random discovery and sharing on the internet. Some of these are neat, while others can be huge time-savers if you know about them and how to use them best.

› Continue reading