∞: the voice of

Whew, that was hard.

After thirtyfive days of waiting. After countless hours spent tuning the basic interaction of the application. After four solicitation e-mails to Apple and a frantic Saturday evening spent pushing all the big red “PRESS HERE TO LAUNCH” buttons I had prepared for Approval Day and after being incoherent for a whole weekend.

Before I have to go to the dentist tonight (ick).

Er, I was saying — after all of this, Mover’s done.

So, come to the fireside, my readers, and I will tell you its story.

It was a dark and stormy night gray yet sunny morning in Milan when I watched the iPhone OS 3.0 keynote. As usual, I didn’t watch the keynote for the announcements — these are usually very light on information, diluted by endless demos and on-stage handwaving. I instead watch keynotes for what’s left unsaid or for the passing mentions, the tidbits a programmer/designer can pick up that keynote liveblogging sites will not. And one of the things I realized almost immediately was: Bluetooth P2P, and file sharing (in the form of MMS), were both in the OS, but the two were never mentioned together. Knowing Apple well enough, this got my head spinning in a number of directions, providing me with reasonable guesses about what they were doing. In particular, I guessed they wouldn’t be allowing Bluetooth Object Exchange in 3.0, also known as “sending files between cell phones”. (Note that I can’t tell you whether I guessed right or wrong, because I’m bound not to say.)

So, no sending between cell phones, I thought.

No sending.

Heh, too easy, my brain went. Apple likes to astonish. Maybe they haven’t put sending in yet just because it’s not going to be what we expect. How would file sending made by Apple be like?

Uh. Picasso is often quoted with the “good artists copy, great artists steal” line. I think it’s missing a part: decent artists coalesce, where “decent” is somewhat halfway between good and great and “coalesce” means that they don’t really copy ideas, even though they’re not competent enough to steal them by judging them on their merits. “Coalescing” means that ideas simmer and melt and bubble around the decent artist’s head, puzzle pieces immersed into a constantly-shaking snowglobe.

Sometimes you put a random last piece in and the shaking sends it hurling against another one that was already around. For example, it may hurl straight on the continuing thought that iPhone applications don’t have nearly enough direct manipulation, which is the fact that you can touch simulated “things” and move them around like physical objects, even though the interface is ideal for this kind of app.

And, again by way of example, this unholy union could bounce against more pieces, for example the fact that BumpTop uses simulated-physical objects to represent files, or that a certain someone has some ideas on how to implement 2D surfaces containing faux-physical objects for a redesign of his mobile dice-rolling application slash design testbed.

Boom.

(And yes, the above means I consider myself a decent artist. Go figure.)

What followed was a lot of soul-searching, a lot of tech docs reading (both public and NDA’d), a hatching of plans and a photo of a loaf of homemade bread, which was turned turned into the ideal test subject for a mockup:

I started cutting things out of the mockup and writing the initial interaction code that became L0DraggableView in MuiKit. I also started doing two things: enumerating the possible ways things could go wrong from a usability standpoint (e.g.: what if the user flicks a slide offscreen towards a side where no peer is?) and talking around. A lot. Really a lot. Showing people things as they were built, down to sharing the code; gauging their reactions, making educated guesses. When my mother, whose computer literacy is really basic, saw an early demo and said “whoa!” and basically got how to use the app in one go, I knew things were heading the right way.

By the way: the answer to the above usability question question isn’t, “oh, it shows an error alert”. It’s, “it bounces back”. I really really strived to “talk” to the user as unambiguously as possible through the language of physics. Things go “on the table”. Downwards is you, there’s the plus button there, and things you add get on the table from there. Other sides are other people. When a thing arrives on the table, it’s already saved — interacting with the table, even removing things from the table, is safe. Likewise, flicking is never dangerous, but flicking towards a side sends a thing off. It comes back after a moment. I even tried interpreting user intentions rather than mere actions by the use of “attraction points”, a way to turn a “hey I flicked and it almost went off but didn’t” into a successful slide in a transparent, unseen way. And of course, I mimicked the table deletion UI from other iPhone apps in the Edit/Done interaction, with a fade that makes the delete buttons momentarily more evident in order to guide the user’s sight to them.

I tried to make the application basically written language-free, knowing too well users don’t read. But users do experiment, and once I established a few simple rules, a “narrative start” if you will (flick and off it goes!), every effort was spent to make sure whatever could happen would make sense in an intuitive, unsaid way. Yes, that’s exactly what happens when you design a game. It was designed to make me go “Ha!”, and hopefully you, too.

And I think I did a darn good job of doing it.

Of course, not everything could be said by “gesturing”; for example, the user cannot know that everything that comes is saved, or that devices must be on the same Wi-Fi network to see each other. (Not to mention the last-minute, Apple-rejection-avoidance addition of a “You’re disconnected” alert in case the network goes down.) I decided to go for least-effort in that case, providing “tutorial alerts” to the user as things happen for the first time. I was a little verbose in them, methinks, but I really didn’t find a way to cram all the concepts required by such an application in so little space.

Well, that’s mostly it.

Ah, a few answers to pressing questions:

• yes, I did think of clients (desktop, too?) for other platforms; who knows? I might make them in the future. Or you could. The whole thing is open source after all.
• yes, of course I planned the whole thing with OS 3.0 and Bluetooth P2P in mind. It was so nice an idea that I wanted it out ASAP, so I went for 2.x and Wi-Fi first. But I did read the Bluetooth docs as I designed the “transport” part of the application.
• I was seriously torn between having the slide, well, slide out immediately when receiving started with a progress bar/spinner over it, or just going with the name flashing/spinner UI that you see in 1.0. Two factors troubled me: one, the user is implicitly assured that all things on the table are “safe”, saved, and this isn’t the case with such cards; and two, it requires an additional level of complexity in the controller code (it has to distinguish between item views that have an item in them and item views that represent items whose transfer hasn’t finished). So I went for the simpler route in 1.0. But I understand that these two might not make up for the bad impression of not seeing the slide, well, go out from one side and into the other. So I’ll keep thinking. Who knows? I might reach a reasonable compromise, or have another wild idea entirely.