playlist about winter in a climate without real seasons

for Cloudy Days is a really good playlist that just appeared in the wild. Compare it to what you could do using any XSPF-based method like XSPF Musicplayer, JW player, and EasyListener, using any all-in-one solution like Muxtape, Mixwit, Playlist.com, Myspace Music, Rhapsody, or iMeem, or using an iTunes playlist.

Here is that page within an iframe for easy inspection:

There’s a big piece of artwork splashed across the top of the page, and this playlister takes advantage of that big expanse of pixels with a landscape photo. Imagine the 640 x 450 pixels of that peaceful open landscape crammed into the 64 x 64 square for album art in any Flash widget — it wouldn’t be on the same level.

Underneath the art is a long text annotation about the playlist, 265 words in all:

This past weekend reminded me why I love the winter months coming up ahead; however, here in California there’s not really a true winter season. To me winter is just a reminder of those calendars in elementary school with the image of the snowman and leaves being swirled up with a bunch of lines symbolizing the cold wind.

It’s only after that big piece of art and expansive explanation that the songs start. At that point the capabilities of all the other playlisting providers kick in. I bring this up because it a really great example of why it is that the HTML-based playlisting solution in goose (which he uses in that page) is better than any Flash-based one. This is a new and better generation of playlisting technology.

attribution and reuse

Play the Web is a blog with the premise of exploring technical hurdles for making chains of derivative works:

On this blog we want to talk about media reuse on the Internet and enabling reuse in a responsible way. Media companies’ reactionary response of restricting all use is throwing the baby out with the bathwater but conversely doing away with copyright on the Internet altogether is no better. There’s a middle way and we need to build tools to facilitate that path. Tools to recognise media and enable reuse.

They’re assuming that the end result of their work will be part of The microformats.org Initiative:

Our immediate challenge is discovering what licensing and ownership attributes are associated with a given piece of media. There are millions of discrete pieces of media on the Internet, how can software tell which are reusable, which are licensed, which are public domain, etc.? A simple solution to this problem is offered by microformats. By embedding meta-data with media in a standardised, machine-readable way we open the door to all kinds of applications that rely on this knowledge.

And they already have an excellent post on how to do attribution for a reused photograph:

I’m now kind of concerned with what to call “Attribution”. In the Creative Commons attribution is a legal term, but what I really want to relate is:

  1. From where did I find the content: Miss 604’s blog. (The Copied Source)
  2. From where did the original content come from: Squeaky Marmot (The Original Source or at least the source Miss 604 found)

Do you reuse content? Do others reuse your content? If so, what do you think? How would you like to see the “attribution”?

I have a couple data points to offer.

One, non-commercial users don’t care about copyright. They know zero about it, they don’t know of any reason to care, and they aren’t going to change. (Software developers, who deal with free and open source software, are an exception to this rule). Commercial users may care, but can’t use content under a non-commercial license. So in practice the issue of attribution only has a real-world impact for derived works created by commercial entities. Source works which are licensed to allow both derivative works and commercial use are the ones we’re talking about.

Two, in XSPF there is an element for giving attribution to the sources of derived works. The idea is that one person would incorporate another person’s playlist into their own, and would use this element to give credit. It is defined as a chronologically-ordered stack:

An ordered list of URIs. The purpose is to satisfy licenses allowing modification but requiring attribution. If you modify such a playlist, move its //playlist/location or //playlist/identifier element to the top of the items in the //playlist/attribution element. xspf:playlist elements MAY contain exactly one xspf:attribution element.

Such a list can grow without limit, so as a practical matter we suggest deleting ancestors more than ten generations back.

<attribution>
  <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
  <identifier>somescheme:original_playlist.xspf</identifier>
</attribution>

The stack framework is a pretty elegant tool for handling this requirement, and I’m happy about how we did it. However this element is rarely if ever used because no current playlist sharing sites that I know of both expect playlists to cross site boundaries and expect users to make new playlists out of old ones.

Vess Ossman playlist on Soup Greens

Over on Soup Greens I have posted a playlist of pre-1923 recordings by a banjo player named Vess Ossman.

The playlist is a standalone page of hand-coded HTML. The design is influenced by Muxtape. The blog post over there is a stub to enable comments and channel blog visitors into the playlist.

The blog post is at http://soupgreens.com/2008/05/14/vess-ossman-playlist/. The playlist is at http://www.soupgreens.com/vessossman/.

My goals in terms of my own music were to provide context and to keep the flow of fresh content up. Context gives notes a back story and cultural kick. Fresh content creates momentum.

My technology goal was to explore playlists as a form of album packaging. I wanted to do such a tight job on the page that it would give the same kind of experience as opening a new CD and listening while you read the liner notes and look at the pictures, so I really sweated the graphics, writing, song selection, outbound links, and usability. I don’t want people to download the MP3s; I do want them to listen with the page open, and ideally to return to the page when they want to hear the music again.

I couldn’t figure out how to give the playlist social liveliness of the kind that Greg Borenstein articulated in his comment on the Jon Udell piece. Ideas are welcome.