Images of the Week: Music Apps & Interface Lag

Below are “before” and “after” shots of the interfaces of several excellent sound/music apps for the Apple iPhone and iPod Touch: apps titled Gliss, DopplerPad, and Bloom. The images of these apps’s various screens evidence what has become a norm, perhaps an accepted one, in casual music-making applications: the application you are learning to use will likely change, perhaps radically. Drastic changes can result in what I have personally experienced as “interface lag,” the subtle confusion that results from dealing with frequent iterative changes to familiar software tools.

For the time being, when music apps are a relatively new phenomenon, and when such iterative changes in apps are generally understood to be upgrades, this isn’t a big deal. But as time goes on, issues will arise — tension will occur between end-users and programmers. In some cases, such tension has already arisen — you just have to scan the app reviews in iTunes to read dialogs about disgruntlement following an upgrade.

This is an especially sensitive situation because app developers aren’t merely managing a user’s response to alterations to their own programs; they’re also managing a major cultural shift. Music apps are on the front line of the rapid dissolution of the distinction between cultural production and cultural consumption.

We’re entering a fourth stage in popular music, from (1) pre-rock pop’s distinction between songwriter and performer (think Elvis, the Brill Building system), to (2) rock’s emphasis on musicians writing their own material, to (3) hip-hop’s re-use of existing sonic material, to (4) the current age of audio-games, in which users experience sound by manipulating it — not just with the iPod, but also with games like Rock Band, DJ Hero, and Guitar Hero, and with the audio tools built into the Nintendo DSi, just to name a few examples. (There are similar factors at work in underground and academic music and art cultures, but the focus for me here is on mobile music-making apps, which are significant because of their popularity, because they have made populist numerous activities and approaches to creativity that were previously considered specialized, abstract, experimental, even avant-garde.)

All three apps shown below have implemented significant improvements as a result of upgrades, and each development team has done a good job of making these alterations to pre-existing interfaces in a way that minimizes confusion for users (the Gliss and DopplerPad upgrades just occurred; the Bloom upgrade dates from last year). These upgrades do, however, beg various questions:

”¢ What happens when an upgrade involves the loss of a feature prized by a user? ”¢ How can app developers best plan for future changes, so that an interface can allow for growth? ”¢ What does it mean to the making of music that an app — in effect, an instrument — is not a fixed tool, but an ever-changing thing? ”¢ Will upgrade development always follow a linear trajectory, or will various offshoots head in different directions? ”¢ How can the iTunes Store better help users to make informed decisions about whether or not to upgrade?

These all come down to a singular question:

Ӣ What is the social contract between app users and app developers in regard to questions of continuity, transparency, and general development support?

Here are three examples of app upgrades — what those upgrades consisted of, how they played out in the app’s interface, and what they suggest about the developer’s goals and intentions:

Adding Multiple Screens in Gliss: Gliss is a relatively new music app, launched in December 2009, but quickly showing promise with its emphasis on the gestural aspects of the iPod’s touch interface. The screens below show version 1.0 (top) and 1.1 (bottom) of the main performance interface. The change is the numeral “2.” (Ignore the scraggly lines on the screen — those are the graphics associated with the way touches result in music being played in Gliss. And also ignore the fact that the fifth icon in from the left along the menu bar differs between the two images — those are simply two states of that particular control in Gliss.)

What the single numeral “2” indicates is the major alteration from version 1.0 to 1.1, in that the program now provides what the developer calls “multiple sheets.” These “sheets” allow the user to produce different individual musical segments within a composition, and to then move between those segments. The implementation isn’t perfect (the gesture to move between sheets can result in inadvertently altering a given sheet’s composition), but the interface change suggests the programmers were planning ahead. Note that the “2” appears in a wide space that was previously empty.

Introducing Effects in DopplerPad: When DopplerPad upgraded recently to version 2.0, it really earned its $9.99 price tag. The upgrade included the introduction of a synth editor, various effects, and the ability to edit those effects. The two shots immediately below show the main interface before (top) and after (bottom) the introduction of effects. Note that the placement of the effect button along the bottom required other buttons to decrease in size. And it threw off the symmetry of the menu bar.

This screen below shows the list of effects in DopplerPad 2.0. The empty spot is a bit inelegant, but in the culture of apps, where change is expected, the emptiness serves a purpose: it suggests a promise of new effects in the future. More immediately and practically, it also provides space for user-edited effects to be added to the interface:

And this screen below shows the DopplerPad “Tools” menu. In the previous version, this only had the “AudioCopy” and “WifiSync” buttons; the “Synths” and “Effects” buttons are new. Needless to say, there’s a lot of room on this screen for additions. One thing app developers need to balance is how much room to leave for future additions, and how much that empty space might inadvertently raise the expectations of users:

Reflecting Generational Change in Bloom: Below are the “about” screens for the two most recent versions of the Bloom app, the more recent one (on the right) quietly announcing the upgrade to 2.0 (and, for trainspotters, newly crediting the app’s icon to menu designer Brett Gilbert):

There are numerous changes not only to the Bloom software as a tool, but also to the way that tool’s interface is designed. On one screen, for example, the prominence of the Listen button, relative the Freeze and Clear buttons, has been eliminated. This isn’t a big deal for most users, but for anyone using Bloom in performance, it might require some unexpected adjustment.

Below is a shot of one big boon to Bloom 2.0: the introduction of three additional sounds (or, in Bloom lingo, “moods”), as shown on the right:

The main screen, below, marks the biggest change to the program. In what I’d argue is a major break from the Zen-like casualness of the original Bloom, version 2.0 opens with a potentially confusing variety of choices. (The in-screen advertising for two other apps, Trope and Air, also diminishes the calm of the original.) There are now three modes: Classic, Infinite, and Freestyle. The explanation for “Classic” is of no use to newcomers to Bloom, in that to understand it you need to have experienced Bloom prior to version 2.0:

The name “Classic” seems premature, given that the software isn’t even a year and a half old. It does, however, hint at the tension inherent in iterative software design for casual users, and suggests that it may become a norm that apps will include within them their previous two or three major iterations. That would reflect a certain transparency, in that it allows for hands-on comparison between versions by users, and also allows for users to transition from one version to the next at their own pace, continuing to use the familiar version while experimenting with the revised version.

Rating Ratings Systems: In the short term, one thing that might help address “interface lag” is for the iTunes Store to implement an interface alteration itself. I’d welcome ratings visualization along the lines of what Yelp.com currently does. Below is, on the left, Yelp’s customer “rating distribution” summary chart, which closely resembles the one in iTunes; iTunes actually goes a step further than Yelp, listing the number of reviews next to each distribution (i.e., DopplerPad has as of this writing 27 5-star reviews overall, out of a total of 61 reviews). On the right below, however, is something iTunes has yet to adapt, something that Yelp terms its “rating trend,” which shows how average ratings for a given business have changed over time:

To be fair, iTunes approximates the Yelp “rating trend” by allowing you to separately view ratings for the most recent version of an application, or the combined ratings of all versions of the application.

The Yelp summary above happens to be for an Indian restaurant near my home in San Francisco, and reflects the restaurant’s struggle to reclaim its once stellar reputation following the exit of its chef. But it could just as likely reflect the struggle by an app developer after an inadequate software upgrade.