Sunday, July 17, 2011

iPhone app idea: "flow forms"

Some iPhone app ideas. Feel free to make use of them. If you do, an acknowledgement is all I'd ask. I'd play around with some of these ideas myself, but my PhD is what I need to focus on at the moment.

"Flow forms"

This idea is for a novel (at least as far as I know) type of UI for tasks like adding new expenses in an expenses app, where each time you do it you choose from the same set of options and you frequently perform the task.

The point of it is to make doing the task as fast and fluid as possible.

It aims at doing this by removing two sources of friction that you find in the existing form-like UIs normally used to perform these sorts of tasks.

How the normal UIs work. There's a screen for the form, showing the different fields. You tap a field to be taken to a screen for the various options for that field. After you've chosen a value for the field, you're returned back to the main screen for the form.

Friction 1: you have to complete a task before you can see the screen for the next task. A task is either tapping a field to select it, or tapping a value for the field. So you have to tap a field's name before you can see the screen for choosing the value for that field. So when you go to perform that next task you have to take a little bit of time to survey the layout of the screen and find the item you want. Even if you're familiar with the screen's layout and roughly where the item you want is located on it, it still takes a little bit of time to find that item.

Fiction 2: a lot of finger movement. You have to move your finger around a bit - to tap a field here, to tap a field-value there, and so on. This doesn't sound like adding friction, but I think it is something that can be reduced.

These might not sound like much, but if you're frequently using the same form these things start to feel tedious.

The basic idea of the proposed technique.

The form would be just one long page, which would continuously scroll up the screen. Below each field name would be one or more horizontal bands, each divided into equal-sized cells. Each of those cells would represent a different value for the field. To fill out the form the user just needs to slide their finger to the left or right as the form scrolled by.

Essentially the user only needs to move their finger along one dimension, thus simplifying the task. And all they need to do is select field values. They don't have to tap to go to the next field. And the hope is that if the next field is visible on the screen while they're entering the current one, they will have some sense of where the items of a field are located before they come to select them.

Here's some more specific details of one way it could work:

  • the line for selecting a field's value would be divided into N equally-sized segments, where N is the number of different options. (if there were too many options I'd be split up over multiple lines).

  • probably have these lines fairly thick - like 2.5 cm, so that the user has a fair bit of time to select the item as it scrolls past.

  • each segment would contain an icon (or short-description, if there is one) representing the particular value.

  • when the user has their finger on a segment, it would show a label describing the value.

  • the user could swipe their finger across a line to see the descriptions of all the items.

  • if the user made a mistake or missed entering a value for a field, they could scroll the screen back down just like they do in other applications.

  • perhaps they could also be a way to pause the scrolling.

  • perhaps the user could flick their finger up (just like they do in documents on the iPhone to scroll down) to quickly move down to the next field, once they've selected a value in the current field.

  • the user may not want to enter the values for all of the fields. if they've only entered a couple of fields and want to save the record, they could click a save button (or perhaps a two-finger sideways swipe).


  • how to handle the input of numbers? Would it just scroll a keypad into view and then pause the scrolling while you enter in the value? Or could number-entry also be handled in a similar fashion to the rest of the form entry?

    • it could show eleven choices across two rows: one for each of the ten digits and one for the decimal point.

    • if after you selected on of those you moved your finger over to a 'gutter' area on the side of the screen it would assume you'd finished entering in the numeric value.

    • but if you instead kept your finger within those gutters it would add another two rows for selecting another digit or decimal place.

    • the above process would continue on until you'd finished entering the number in.

    of course the question is whether this, or some alternative, would be convenient and fast enough.

  • similarly, how to handle the input of textual values (such as for a 'note' field for an expense item)? Would it just scroll up a keypad and a text area and pause the scrolling while you enter in the value? Or might there be useful way of entering it in a 'flowing' fashion, like I described concerning entering in numbers?


  • ideally it would show the fields in an order such that the most commonly used fields come first. I typically just enter two field values, and if these were the first two that came up I could just save the record after I'd selected values for them.

  • since the user is likely to buy the same item a number of times (e.g. I buy the same coffee everyday, or I might get a packet of chips every day) their muscle memory may be able to learn the path their finger traces out to enter the expense for that item.

  • to make entry even faster, you have an option to control the speed it scrolls at. As you got more familiar with it you could increase the speed. Perhaps there could be a speed-control slider that sat at the top of the screen next to the save button. It could even have a setting to automatically -- but gradually -- increase the speed over time. For example, it could get gradually faster every month.

Another question I have is: are there any other sorts of tasks or apps that this kind of UI technique might be useful for?

And finally, obviously it'd require a lot of experimentation to figure out how best to have the UI work. There's lots of different ways the basic idea could be done. Hopefully there would be one that is workable and which would make the task quicker and easier to perform.

No comments:

Post a Comment