|
|
|
 |
<< Tuesday, March 30, 2004 >> |
|
Blogs + playlists = collaborative listening
Something wonderful died with Napster: the collaborative discovery and sharing of a wide diversity of music. Lucas Gonze is on a crusade to bring that experience back, legally. On his site, webjay.org, users share playlists -- i.e., lists of URLs that point to MP3s that are posted on artists' websites, or that are otherwise authorized for distribution on the Web.
My first (and so far only) Webjay playlist began as a couple of tunes by Betty Dylan, a Nashville-based duo who played my hometown recently and won me over with their energy and charm. Hunting around for more Betty Dylan tunes, I ran into some other Bettys -- Betty Roche, Betty Sue -- so I included them too.
Yesterday I noticed that the Betty Roche tune had migrated into one of Lucas' playlists, Streak of lean, streak of fat, and the Betty Dylan tunes had found their way into another of Lucas' lists, The Betty Destroyer.
In a recent blog essay, Lucas talks about the collaborative filtering dynamic he hopes to encourage:
There's one song in Treebot from Tofuhut, Yusef Lateef's Strange Lullaby. There's also one song from LargeHeartedBoy, Julie Doiron's mind-blowingly beautiful Pour Toujours, and that song had gone through three generations of filtering. In fact, every song in Treebot made it through multiple cullings, and that's why it's a good playlist.
It took Tofuhut to introduce "Strange Lullaby" into the ecosystem, and if he didn't have both taste and writing ability his recommendation wouldn't have made it through. But it always takes more than one person to do collaborative filtering. I want to make the path from obsessive record collectors to the average iPod as short as possible, and that's what Webjay does for him. [Lucas Gonze, 3/18/04]
And elsewhere:
Here's the business problem: I want to help music businesses sell products, then make my money on affiliate revenues. That way everybody's incentives are lined up in the same direction. The listeners are looking for the best music, I'm trying to find the music they'll like the most. Music businesses are looking for listeners charged up to buy, I'm trying to get the listeners charged up.
So how do I do it? An Amazon search for a song title? Amazon's product database isn't big enough (hard to believe, I know) and the lookup algorithms aren't smart enough -- I need a relevance match, not a keyword search. ISRC identifiers? Good luck getting them for online music, much less matching them to vendors. So help me out here, Music Industry: given a product and a buyer, how do I find a seller? [Lucas Gonze, 3/23/04]
There are a bunch of things that frustrate me about playlists. Competing formats: m3u, smil. Inconsistent behavior: if you want your tunes (and associated images) to render as you expect, you're looking at an insane test matrix. Crappy metadata: missing or incomplete, and often hard to find. Despite all these irritations I find myself returning to Webjay for the same reasons I write this blog and read others. What I know, I want to share with others. What others know, I want to know too.
If it's easy to buy music online, I sometimes will. But first it has to be easy to find, listen to, talk about, and share tunes. The intersection of blogs and playlists isn't yet nearly as smooth an experience it should be, but the ideas that motivate webjay.org are exactly right.
|
|
Human interface guidelines for the Internet
Apple, of course, wrote the book on human interface guidelines by visualizing and documenting a range of interaction scenarios in meticulous detail. Today we have a variety of platform-specific guidelines -- for Windows, for GNOME, for Flash MX. But we lack general guidelines for how Internet applications should behave on all platforms. E-mail programs don't agree on how threading, foldering, and filtering should work. Web browsers don't agree on how drop-down search boxes should work. RSS readers don't agree on how the orange XML icon should work. Media players don't agree on how playlists should work.
We need HCI (human/computer interface) guidelines more than ever. And we need them not only for Windows, OS X, GNOME, and Flash, but for the uber-platform that subsumes them all. We need human interface guidelines for the Internet. [Full story at InfoWorld.com]
The impetus for this column came from this posting on S/MIME signatures, which argued that confusion about whether or how to trust a signature is a problem of UI, not cryptography. Robb Beal violently agreed. He wrote:
Yes! Every technical spec that has user-facing implications should have a corresponding functional spec.
See my functional annotation of Mark Pilgrim's HTTP tests for an example.
Robb pointed me to some other examples as well. Why isn't this done more? Robb thinks it's because developers tend to want platform vendors to do this work for them. But even on a given platform, essential guidance about user interaction is often lacking.
Scanning the responses to my posting on S/MIME signatures, I realize some people took it as a condemnation of S/MIME. Not so. I was trying to illustrate how interactive context affects the implementation of a protocol, and how the nature of that context can be (but rarely is) specified.
I had suggested, for example, that a mail client displaying a signed message should always display the address in the From: header (not just a friendly name), should display a standard signature icon, and should link the icon to a certificate viewer. Outlook 2000 breaks the first guideline. Darrell Dykstra wrote to point out that Outlook 2002 and 2003 comply with all three guidelines, which is great. Except, of course, they aren't guidelines written down anywhere, and that's my point.
The other day, NPR's Day to Day ran a segment on phishing. In this clip, John Dimsdale interviews David Jevans, chairman of the anti-phishing working group, who says:
Typically it's the average consumer, who's quite Internet-savvy, and they get an email in that looks exactly like it came from their bank, with very compelling information -- it will have the logos, it will really try to fake the website.
We have a technical solution: Aunt Tillie could evaluate the site's SSL cert or the email cert of the phisher. But there isn't a snowball's chance in hell that she will. For that, and for the countless other ways that we fail to contextualize protocols in standard and familiar ways, we should be ashamed.
Update: John Patrick on phishing:
The moral of the story is to be increasingly careful. Anti-virus and anti-spam are not enough. Anti-spyware is not enough. Hardware and software firewalls are not enough. All of these are essential but the other ingredient is common sense. Look at your email carefully. Even if the "from" address is one you recognize, look also at the context.
...
Digital ID's are essential to add authentication to email and software downloads. We need to be able to establish that we are who we say we are and to be sure that others (people, links, software) are who they say they are. You can read more about this in the patrickWeb Privacy and Trust series. [John Patrick: Phishing Update]
|
|
|
Recent Entries
|
|
NEWS 
