Jens Alfke writes about the beauty of the $0.99 iPhone Application. I think he makes a reasonable point: when somebody else is taking care of a lot of the overheads of both distribution and payment processing, there are no compelling negatives to developing micro-priced software applications.

What kind of application are you going to sell for $0.99? It doesn’t seem like a lot of revenue for something that you might call “useful” – but I don’t think there’s a lasting market for one-dollar “toy” applications.

I think the interesting market that becomes opened when you apply this kind of thinking to a particular platform – namely, the iPhone/Touch interface – is one of selling interface.

A good way of explaining this is with a currency or unit converter application (bear with me).

As it stands, if you want to convert from, say, imperial weight to metric, you can just fire up the iPhone’s built in Calculator application and bang out some arithmetic – as long as you can remember the conversion ratio.

If you don’t know the conversion ratio, you can go online – for free, because you’ve got an airtime contract, or pervasive wifi – and look it up, perhaps even finding a nifty Javascript conversion tool. But that’s a long way round for such a simple task.

Or, I can sell you my $2 weights-and-measures converter. It doesn’t do anything fancy, because we’ve already established that the maths isn’t beyond any potential iPhone user. So the single thing I can sell you on – and the single reason you’d buy my app over the long way around described above – is because of its interface. How easy is it to use? How satisfying? Does it simply a complex task?

The iPhone exposes “interface” as an obvious criteria for purchasing things. Because the interface is so hands-on, so direct, users can easily spot when an interface stinks, or when it’s as easy to use as Apple’s own applications. Given that: let’s make an application where the interface is the primary feature, and the functionality is essentially trivial.

Here’s what my hypothetical weights-and-measures conversion application might look like. You choose what you want to convert to and from via a pair of drop-down boxes at the top of the screen. The drop-down highlights which things on the right-hand side are similar types of measurement to those on the left – so that when you select “metres” on the left-hand side, the units of length on the right-hand side are highlighted. And then, underneath, are two vertical, gradated rules – much like on a slide rule. Above them is the exact value readout; at the centre of the screen is a red marker line. You flick one “ruler” up and down with your thumb, and the other moves in accordance to display the converted value. You can then read exact values out at the top of the screen. If you want to slide horizontally, tip the phone on its side and the accelerometer will tell the software to rotate the screen.

The really neat thing isn’t the conversion at all – it’s just two big rules that you can flick about with your finger. But when you’re out shopping and have only got one hand free, maybe that’s exactly the interface you need. The app is a basic, trivial task, that’s enlivened by a useful interface.

Now, obviously I can’t charge you $10 for this. If I asked for $10, most people would either keep guesstimating weight when they go out shopping, or just use the calculator like they’ve always done. But for $2… it becomes much more of an impulse purchase. You’re not purchasing functionality; you’ve got that already. Instead, you’re putting down $2 for the interface I’ve built.

I’m not saying that interface alone isn’t worth a lot, or that it’s worth $2. Far from it. But taking a task that the user could already do and designing an appropriate, specific interface for it, that makes it pleasurable and immediate to use – that’s worth more than nothing. $1, $2 – as long as it’s less than a coffee, but more than nothing, that’s fine. That’s a business model. Not a complete one, or one to base an entire company off, but a business model nontheless.

The iPhone and iPod touch are devices that thrust their interface and interactions front and foremost. They’ve established within a market full of – in places – terrible interaction design, that it’s OK to pay a premium for devices that work well. People who’ve bought an iPhone or an iPod Touch have already made that premium decision. The iPhone Application Store tells us that it’s OK to pay a smaller sum for software that works well. It doesn’t matter that it’s not premium software, or that the software isn’t sophisticated; what matters is that we’re make money from genuine interaction design, rather than a list of features. That feels like another tiny watershed moment.

The other night, Matt was showing me his newly unlocked iPod Touch. I was playing with the shell application – just poking around, running top, etc – and rotated the iPod onto its side, just to see if the screen-rotation stuff worked in the third-party application.

After a while, Matt picked up what I was doing – as I poked around, when I found an app that felt like it should have a horizontal view, I would tip the iPod over, wait a second, and then tip it back.

It reminds me of a running joke my parents had with me ever since I was little. I used to pick up Christmas presents and shake them, and if they rattled, I’d assume that they were Lego (Lego, at the time, being the only kind of present I got that rattled). Ever since, we’ve always joked that rattling presents are Lego. And just like I rattled presents to see if they had the potential to be Lego, so you “rattle” the iPod to see if an application has the potential to be rotated.

You don’t necessarily need a visual signpost (an icon or alert) that such functionality is available; you just rotate the device, wait a second, and then flip it back. As a user, you’re interrogating the user to see if that particular interaction is possible. Is that good design? In some kinds of interaction, I don’t think so; you don’t want to poke every button or crawl through every menu just to find out what is or isn’t possible.

With the iPod/iPhone, though, we’re not crawling menus; we’re just interrogating the device to see if it supports a single kind of interaction. We only want a true or false back from it. Couple that boolean response with the simplicity of the accelerometer interface, and these “rattling” interactions come at a much lower cost.

I like rattling as a metaphor for this kind of interaction; it’s the equivalent of responds_to? in Ruby, I guess. What are other good examples of rattling-type interactions I’m missing? And how good are the implementations of it in software or on the web?