Data, Information, Medium, Message

July 28th, 2009

Being a Small Post on a Large Topic

What you put in your Web app dashboard is different from what you put in your emails, and different from what you put in your SMS messages or mobile app dashboard, and rightly so; if McLuhan had his act at all together, we can be confident that even if you try to make one size fit all you’ll fail. Probably miserably.

But that doesn’t mean that the lessons learned in one medium can’t be applied to another. Our example for the day is a service that I love: Songkick, the folks responsible for an ever-increasing percentage of my discretionary incoming going to live music.

Songkick allows you to track both upcoming gigs by performers that you already listen to and gigs that other Songkick users will be going to; this is great, as it simplifies the process of discovering new music (as human beings are still the best music recommendation mechanism out there), but it leads to a problem for the service.

Right now on Songkick I’m tracking 500+ performers, half a dozen venues, and ten other people, so everything associated with those performers, venues, and people is a part of my Songkick “tracker.”  That means that my tracker includes people going to gigs around the world in addition to the shows happening in my own back yard. The image below is a part of one of Songkick’s email notifications, and there’s a problem hiding there:

Songkick Tracker Email

Songkick Tracker Email

Quick, which of those shows is happening in the New York and which in London? Yeah, I had a hard time figuring it out, too. All of the data is available, but it hasn’t been transformed into easily actionable information.

What’s really interesting, though, is that this is a problem that Songkick has already solved—just in a different medium. Take a look a the Web version of the tracker dashboard, which offers a superset of the information in the email:

Songkick Tracker Dashboard

Songkick Tracker Dashboard

The difference is clear: while the data being displayed is functionally identical, the SK crew saw that they needed to visually distinguish between the different classes of data they were displaying when they were thinking about dashboard design for a Web site: the color coding makes it relatively simple to scan through the data and pull out what you’re interested in…data transformed into information. Because email is a different medium, however, the lesson learned on the Web wasn’t carried through to the emails that contain virtually the same data set.

It’s a relatively minor complaint, but the underlying issue is well worth considering: think about the impact of the medium on your message, but don’t forget that some of what you learn can apply across the board.

design, metadata, miscTech | Comments | Trackback

  • I bet the city name missing in the email was an oversight, not just lost in translation, but point taken. (and what will their tweets look like!)

    The web experience also lends itself to far more interactivity, with rollovers, tooltips, flyouts, and whatever else, whereas with email you almost need to think about it as a printed page: Am I telling people everything they need to know up front, and/or providing a good way for them to find out more.

    I like it when smart people don't have jobs and can write real blog posts... :)
  • You're probably right on the missing city name, though that's one item
    I left out regarding email: more oversights tend to slip through
    because email *feels* more transitory, even if the email is a template
    that you're going to send regularly.

    A new page on a site will go through many, many testing iterations
    because it feels substantial (or even permanent), but something like
    email usually doesn't get the same level of attention, because...well,
    because it's email, you know? Who reads that stuff, anyway? ;-)

    And also: thanks!
blog comments powered by Disqus

Search

Search seamonkeyrodeo

More Quick Links

Categories

The Past Year

Creative Commons License