Loopy is my first iPhone app, a loop-based performance/musical scratchpad app based on looping audio equipment and inspired by, equally, the fantastic and free “Freewheeling” application, and an a capella performance by Imogen Heap.

It’s development was a whirlwind of obsessive coding, near-vertical learning curves, impatience, excitement and occasional burnout and writers block.

I thought I’d share some facts and lessons learned from the process, in a several-part article. For part 1, read on.

Beginnings

After using Freewheeling while I was a Linux user, I missed it quite badly. I made several attempts to get it going under Mac OS X, but failed each time. I could never find anything quite like it, and so I made do without it.

Then, after deciding to jump on the iPhone app development bandwagon, I thought that pursuing this passion would be a good place to start.

This, of course, was entirely wrong – as Daniel Jalkut and Manton Reece said a while ago on their podcast Core Intuition, it’s a very good idea to start small for your first project, and work out the kinks before trying something more adventurous. Loopy was huge and ambitious, and thus risky – the emotional investment alone was significant, and if it was a flop, it would’ve been heartbreaking, aside from a waste of quite a lot of time.

While that’s lesson number one right there, I’m still not entirely sure I could’ve done it differently – I’m the type to get very swept up in an idea.

So, there that is.

Sketching Interfaces

The first version of the interface mockup emerged fairly quickly. The primary goal was a physical-feeling interface, and so naturally it was made up of LEDs and push buttons, inspired by studio equipment. As is the case with all such things, it had to be fairly simple to understand at a glance. What better path to simplicity by following in Apple’s footsteps: One button to do absolutely everything. Thus, loops consisted of just a button – press to start, press to stop.

The interface needed to quickly get across the concept of the loop, which is where the circle of LEDs came from (my laziness made it a circle that filled up, instead of a ‘chase’ sequence. I got over that fairly quickly). We all like audio meters, so they went in, too – mostly as a mechanism to identify which track was making which sounds.

Unfortunately it looked fairly amateurish and busy, so I needed an alternative. I’d recently bought a Logitech diNovo Mini keyboard for our Mac Mini-based entertainment system, and one day it caught my eye.

The diNovo Mini has a round touch pad, which functions as both a mouse, and a five-way control (arrows and enter). Depending on the mode, it would either light up around the outside in orange, or five symbols on the pad would light up green. It was very stylish, so as all ‘great’ artists do (not that I’m anything resembling an artist), I shamelessly nicked it. Don’t tell anyone.

The ring around the outside became a rotating platter, which conveniently carried many useful connotations for the audio – rotating LPs, in particular. The audio meter was replaced by varying the brightness of the ring, which kept the interface clean – although admittedly at the cost of some of its utility.

And thus, Loopy had its interface:

Control Freak

The tricky thing about this app was all the functionality it needed to offer, while still appearing simple. It wasn’t enough to just offer tracks that one could record, then start and stop, and that’s it. After pouring over Imogen Heap’s performance mentioned at the start of this article, I realised that there was quite a lot going on.

Firstly, she was mixing the looped sound with new audio, as she went. She would sing one part, then immediately sing a harmony, then sing another harmony, adding complexity to the looped sound as she went. That would be just too cumbersome to perform with only a basic recording functionality, so Mix Recording was born.

Towards the end of the performance, something else was happening – she would perform one loop, then immediately sing a harmony to it, before going back to the original tune. At the same time, only the last loop was playing – thus, she was alternating the main phrase with a harmony. Voila, Loop Recording.

The final track function, Merge, came much later. It emerged as a way to free up tracks, while not losing any audio, and was an alternative to adding more track buttons.

Combined with the need to reset a track, suddenly there were four functions a track had to perform: Record, Clear, Mix Record and Loop Record. Combine that with adjustments to the track (mainly volume), and suddenly the necessary control scheme had some serious complexity.

Track Functions

The original prototype implementation involved ‘swipe’ gestures to access the three features other than ‘Record’ (Clear, Mix Record, Loop Record) – one would swipe either left, up, or right to access each feature. This was cumbersome and unreliable: Half the time, one would end up accessing the wrong feature.

A variety of options were thrown around, during a discussion with a close friend and sometime partner in crime, Tim. Most possibilities were based on a radial menu, where one opened the menu, probably by holding down the button, then selected an item that popped up. This appeared to be far more sensible than haphazard swipe gestures.

Rather than radial menus, which involved breaking the physical metaphor of the buttons, and involved some complexity with fitting onscreen, radial ‘selectors’ were chosen instead – lights around the periphery of each button that one selected after holding the button for a moment. This kept the interface uncluttered.

Deciding to stay with the single-button interface was a slightly risky proposition, as it had the potential to alienate users who desired more easily accessible features. In the end, though, this was what I went with. The alternative was to break up tracks into multiple-button interfaces, which immediately cluttered the application, and either reduced the number of tracks that could be simultaneously manipulated, or reduced the size of the controls, making it harder to hit the right button. As I was after something that could be used while performing, for example, this just wasn’t going to work – it would’ve been too cumbersome.

Track Manipulation

The next issue was how to manipulate track volume. This came up after the initial interface plan was devised, once it become obvious that users would want control over track volume, at the least.

One of the options on the table was a landscape-view screen, that included slider controls for each track. One would hold the button down, rotate the device, and the track’s sliders would appear. This option was passed over for now, but is very likely to be revisited to support future track features.

Another option was to hold down the button while rotating the device like a giant volume knob, using the device’s accelerometer to detect the position of the ‘dial’. The sheer awkwardness of this approach made it a bit impractical, although it would’ve been cool.

It was a return to thinking about the original physical metaphor that yielded the final idea – kinda like a DJ pushes a record to speed or slow playback, a ‘swirl’ gesture seemed a reasonable and intuitive way to adjust track parameters like volume.

Tick, Tock

The final interface element, the clock, was almost an afterthought, and remains more-or-less at a prototype stage in the current version of Loopy. The tap-timing feature was one that spontaneously occurred to me during development, and got added in: Being able to pre-define a tempo seemed a useful feature, but not one that was expected to be widely used. As is often the case without performing large-scale user testing, it turns out to be a fairly popular feature. Consequently, future versions of Loopy are going to have a much more sophisticated clock, metronome and tempo management facility.

Interface Lessons

The main lessons which arose from Loopy’s interface design were actually testing and user interaction lessons. Impatience to get the product on the market stopped me from spending a great deal of time on talking to potential users about workflow and interface, but this would have been very useful. This is something I should still do: Find a bunch of musicians, and ask them what they would like to see, and how they work.

One limitation that I encountered along the way was finding an adequately diverse testing community.

Here’s where the iPhone App Store’s limitations were a pain. An increasingly popular trend amongst Mac software developers is to make available a free but time-limited public beta during the final stages of development. Cultured Code did this recently with their app, Things, for example.

Doing this has several big advantages: Firstly, you get free testing and feedback from many users, many more than one could typically get the app in front of during a private beta. Users are engaged with the software, because they are (a) being directly involved in the process, and (b) typically going to end up using the software, so it’s in their best interests to play an active role. Any user interface or workflow choices that users don’t like, you find out about almost immediately, without having to wait and then deal with once customers are paying and have higher expectations (and are leaving ratings!). Secondly, you are immediately building an image, a brand and a community, something that just won’t happen while you’re invisibly developing.

If the iPhone App Store had a facility to provide beta software for free, but with a time limit, and possibly with ratings disabled, this would be a fantastic tool for developers to collaborate with the community to make great software.

Something I needed to do more was to more actively engage beta testers – not everyone can be expected to come up with and communicate insights about software: It’s the developer’s job to start this communication. Short questionnaires and polls would have provided some useful information about the strengths and weaknesses of the interface, and this is the kind of thing I’ll be focusing on more for next time.

Coming up

Seven re-implementations of the user interface, two or three re-implementations of the audio infrastructure, a ridiculous lack of documentation, and timing, timing, timing…

Read on, in Part 2: Implementation.