Reprocessed, by Matt Patterson

Something approaching a weblog

The unadaptive iPod

I've only had an iPod for a few months, but that's been long enough to realise a few things about it, good and bad. My department's boss, Dan Hill, wrote a very good critique of the iPod's physical design, pointing out the disjunct between the appearance of impenetrable perfection and the reality of constrained manufactured product, and praised the adaptability of the software.

I'm not so sure about the adaptability of the iPod's software, myself. I think that the level at which the iPod's adapative nature really comes into play is an interesting one. It's pitched somewhere between the BIOS/firmware level, that bit which actually lets the device boot and use its hardware, and the user prefs level, where users can affect their device without resorting to oscilloscopes and soldering irons.

There are layers of adaptability (this is the point at which we return to Stewart Brand's How buildings learn) in computing devices like the iPod: the hardware level (Changing batteries, replacing components), this strange intermediate level of software below the level of the UI, and the UI itself.

Adapatability at the intermediate layer is good for the user, because is means that their device can be made to do new things with ease, but I think that it's better for the device maker. By this I mean that the intermediate layer is very good for ameliorating hardware problems and fixing software problems. This makes it possible for manufacturers to ship things that don't quite work and fix them after the fact (PC games are renowned for using this approach). This is also known as having your cake and eating it too.

If you ship your product and its hardware doesn't quite work properly then you can compensate for the problems in software and ship this out and get people to patch their devices, maybe before they even realise there was a problem. In the same way, problems with the software (even at the UI layer) can be corrected. (Note that this doesn't automatically make the UI layer adaptable, because corrections of this kind are effectively ripping out the UI and replacing it with a new one: being able to buy a new car doesn't make your old one adaptable.)

The axis of iTunes

In much the same way as the different layers of a building need different tools to operate on (you can't knock through a wall with a tack hammer, and you can't hang a picture with a sledgehammer), so to do the different layers of the iPod. To adapt the intermediate layer I would need to know how to write (probably) C, a C compiler, and a knowledge of how new software is downloaded to the iPod. To adapt the UI layer I need there to be tools built into the device. In fact, aside from the ability to switch certain menu items on and off, I need iTunes. iTunes handles all of the nasty requirements for a sensible UI where I can get lots of info about my music collection (i.e. it provides a keyboard, mouse, and twenty times the screen space).

Essentially, there isn't very much to adapt once you get to the UI. You can alter what menu items appear at the top level, but when it comes to changes which impact the way that music is played - the device's primary function - things aren't much different.

I can choose from a playlist which I've created in iTunes, or I can use random play, and that's it.

Of course, that's not entirely fair. iTunes can't simply be dismissed since it is the primary interface for adapting the iPod to play music how you want it. iTunes gives you normal playlists, through which you can curate your listening. It also, and more interestingly, gives you 'Smart playlists'. For my money, these are what could really give the iPod a good run at being adaptable, but they're also its biggest lost opportunity.

Not so smart after all

Smart playlists are simply queries directed at the iTunes library ('is it Rock?') which allows you extract lists of music based on your query. The interface for Smart Playlists is based around additive criteria ('select if "Is it rock?" is true and if "played it already this week" is false'). You build a list of criteria for inclusion (or exclusion) in your playlist and iTunes figures out which of your tracks should be in the list.

You can transfer a smart playlist to your iPod, but it ceases to be smart. If you have a smart playlist of tracks which haven't been played for at least a week then when tracks in the list are played they won't disappear from the list like they should (playing them would mean they had been played in the last week and thus be ineligible for inclusion in the list anymore).

This loss of smartness, that iPod smart playlists are a only snapshot of their iTunes parent, is a shame, but it's not why smart playlists are such a lost opportunity.

Smart playlists are a lost opportunity because there's no programmatic access to their criteria. I can't attach an Applescript to a criteria (neither the computationally expensive 'if this applescript returns true', which would require every track in the library to have the script evaluated against it, or the easier option of using a return value from a script as an argument, 'does the artist name match the return value of this script?'). That would be fab. I could have a playlist based on the weather, linking track genre to changes in atmospheric pressure. Hell, I could even have a playlist which vetoed playing Morrissey except on cold wet sunday afternoons.

I can't do this through the Applescript interface to iTunes either. I could do it the hard way, querying the iTunes library through applescript to construct a new playlist, but I'd just be left with a snapshot of the results of my query and iTunes wouldn't know that the weather had taken a turn.

Not forgetting:

This page is: