
As applications move to mobile, the context and intended usage change. You can't expect a swiss-army knife of a desktop app to provide the same functionality on an iPhone or Android device. This is already well known, and there are many blog posts and books and courses on this topic. It's great for users, because well made mobile apps are tailored well to the mobile lifecycle they need to survive in.

When it comes to input methods on handheld devices, the same rules apply. You can't expect a standard desktop date-picker to perform well on a touch-only screen. That's why controls like the iOS UIDatePicker are so wonderful: they translate the desktop task to mobile. Some of the functionality is lost, however; in the date picker, showing which days are weekends doesn't translate to the iPhone at all. These reductions _streamline_ the process on a device dealing with a far lower attention span.

If you have the benefit of selecting the input methods for the app you're designing, take to heart exactly what the intention of the input method is for. This includes your target users, attention span and amount of user effort. An expert user might be willing to use a hard to use but accurate input method some of the time, but if the usage scenario includes using the app while rock climbing, you'll need to select an easier to use method, at the cost of precision.

In the Winter 2011 term of my PhD program, I took [Robert Biddle](http://hotsoft.carleton.ca/hotsoft/people/robert-biddle/ "Robert Biddle's homepage")'s course on Human-Computer Interaction for User Interface Design. I ran a preliminary user study comparing different touch-screen input methods for numerical input. I compared the two commonly found input methods of increment/decrement buttons and seek bar with thumb against the more whimsical method of a rotary dial—like a volume knob. The seek bar was the only absolute-scale input method, so values that users selected fell within the entire range of the seek bar used. Users "spun" the dial clockwise or counter-clockwise to increase or decrease the value for selection.

![Screenshots of different numeric input on a test Android app](/media/2011-07-25-input-methods.png "Screenshots of different numeric input on a test Android app")

The study actually ended up revealing an interesting result: the timing to select a value with rotary dial wasn't statically significant from the buttons or seek bar. Anecdotally, users preferred the dial as an input mechanism due to it's perceived ease of use. While very common, especially on Android, dragging a thumb across a seek bar requires more concentration. Personally, I feel that buttons are simply tiresome and dated.

Think carefully about what emotions your input method of choice evoke. If you want a fun or highly interactive application, losing some precision might be okay. More serious or rigorous applications have different design constraints too. Simply going with the default input method for your platform of choice is not always the best idea.

The dial lives on, if you're interested. A good friend of mine, [David Underwood](http://www.theflyingdeveloper.com "David's Blog"), has adapted my simple testing dial in his Magic: The Gathering life counter, [Life Dial](https://market.android.com/details?id=com.inflatableapps.lifedial "Life Dial Android Market Page"). Eventually, we'll get around to releasing source so you can add it to your own Android apps.


As applications move to mobile, the context and intended usage change. You can't expect a swiss-army knife of a desktop app to provide the same functionality on an iPhone or Android device. This is already well known, and there are many blog posts and books and courses on this topic. It's great for users, because well made mobile apps are tailored well to the mobile lifecycle they need to survive in.

Posts about my grad work