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).

Questions

• 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?

Notes

• 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.

iPhone app idea: "battlechat"

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.

"battlechat"

An app for a kind of verbal battle amongst friends.

I'm thinking of like the verbal battles rappers do. I'm also drawing on my own experience when I used to be bored at work I used to have a lot of email conversations with a friend that basically came down to creative ways of insulting each other.

So this'd be an app that was like a mix between real-time (textual) chat between a bunch of friends, but with some competitive elements thrown in, to make it a bit game-like.

There'd be lots of different ways you could do this kind of thing, and getting it right would probably involve a lot of experimentation.

Here's one possibility.

The game is played in rounds. Each round lasts a set amount of time (e.g. 15 seconds). Players can type in whatever they want to say. And obviously they can make comments on what the others say.

At the end of the round, the players anonymously vote on who said the 'best' stuff.

The more 'votes' you get, the more "ammunition" you can use and you can choose who to expend it on. Players would start off with some amount of health and when they're 'fired on' they loose health. They get knocked out when their health reaches zero, and have to sit on the sidelines, so to speak.

Last person standing wins.

-

I can imagine the players being represented by their twitter or facebook picture, but with cartoon facial expressions and arms and legs attached to them (the facial expressions wouldn't have to be matched up with the face in the picture, or wouldn't even require a face in the picture, for the effect to work, I suspect... the idea is to do it for comic effect). Then when they're hit with some ammo, the cartoony facial expression shows an expression of pain, falls over, etc.

---

After thinking of this idea I came across Turntable.fm which while very different also works on the idea of adding game-like elements to more socially-oriented activities. That's a general area that could be explored.

iPhone app idea: 'ground control' side-scrolling car game

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.

'ground control' 2D side-scrolling car game

In this game the player doesn't control the car, but the ground level. Sliding their finger up raises the height of the ground at that point, and also increases the slope of the ground leading up to that point. Sliding their finger down lowers the ground level.

The screen is constantly scrolling across with the car always moving forwards. The car might always sit about 1/3 in from the left of the screen.

Steeper uphill makes the car move slower. Steeper downhill makes it go faster. A small uphil can be used as a jump, making the car fly through the air.

These techniques could be used to make the car avoid static and moving obstacles, jump over crevices, etc.

---

update, 02 Aug 2011: I just heard about the game 'Bumpy Road' which works using this kind of mechanic (see the video on the linked page). It seems to use the mechanic in a different way, though. It seems it as effectively like an alternative to having a 'jump' button. I was thinking more of it as a way of changing the landscape ahead of the car, to speed it up or slow it down or to create ramp-like jumps.

update, 10 May 2012: The iOS game Contre Jour involves a mechanic where you raise and lower the ground-level.