The (music) library problem
There's a funny tension in web / software design for libraries of information, e.g., iTunes as a library of music: on one hand is the argument that most people aren't good librarians, and software should make it easier for us to manage info; on the other hand, the software always forces us to be librarians, and we suffer the software to the degree we aren't good librarians in the software's terms.
The ideal, from my perspective, instead would be that we have software that helps us be good librarians in our own terms. In other words: let us define how we think of things, and help us organize in those terms. But, instead, we tend to have software that makes us learn how the software thinks of things, and the best we can strive for is learning "tricks" to work around the way the software does things.
Mainly, the "library" problem is: information in general (and, music specifically) is relational; but most websites and software programs are designed around "objects" rather than "relationships." With iTunes, for example, the music file (mp3) is what the library is really designed to manage.
While iTunes can attempt to make it easier for us to "manage our music," it essentially is forcing us to be librarians of files. This maybe makes sense as an extension of the "album" metaphor, when we used to get songs and albums on physical discs, and we needed to organize our physical LP and CD collections (which, coincidentally, I actually need to do!). But, with digital information, we really should be looking at the files merely as attributes of the information, rather than the other way around.
Continuing with the iTunes example: iTunes sees things like album art and lyrics as attributes of the music file. But, actually—and we see this on the web, the file makes more sense as an attribute of this kind of information. For example, we'd typically create a web page with art and lyrics, and then also link to a music file.
The important thing about the web model is that it's (more) relational than object-centric. A web page is generally a connection of links (relationships), and a website is, almost by definition, a set of relationships between pages. And, without being too absolutist about it, this web model can be said to be the "software that helps us be good librarians in our own terms."
For example, this Wikipedia page on the Answer Song reflects some group's idea about a certain type of song. The page is effectively some group's library of answer songs. Some group of people decided that this was something they wanted to organize, and voilá! This is basically how all of our software should work: you create something like a page for something, and link it to other things; edit, rinse, repeat. . .
In one sense, going forward, we should look to our desktop and device library software to be more web-like. And, in another sense, we should look to this same software to be more of the Web itself. In other words, I should be able to store that Answer Song page in iTunes, and press play.
I've written about this before, from an information perspective, in my post about playing digital music as information. And, I posted some more about this today (more from a music perspective), both in comments on Lucas Gonze's song page manifesto and dedicated page for a song posts, and in my own post on the new music player / library on my Wrong Notes blog.
I think there are a number of information architecture and interaction design challenges associated with moving away from the old file models we're currently stuck with. And, in a big picture way, I think this could be called the ultimate content management challenge—the challenge of "managing" everyone's content everywhere. But, basically, web pages and links are an excellent starting point and, in many ways, the solution to many of these challenges.
Next post: Site Launch: Marti Kheel
Prev post: Site Launch: the Ear Reverends