Please Give a Beep! How to Make Streaming Audio Apps Better

In the vein of David Pogue’s crowd-sourcing of technical innovation ideas, and as an homage to his Take Back The Beep campaign, here’s a humble proposal for streaming audio players

Use the audio output to tell me when you are buffering, when you are waiting pointlessly, and when you have given up on the stream.

Links: Take Back The Beep;David Pogue; AT&T Wireless; iPhone; QuickTime; ooTunes; WunderRadio; ESPN Radio on iPhone; Columbia Grand Prix;

Past readers know I use my iPhone for streaming audio all the time. Between AT&T’s mediocre network, Apple’s baroque mobile Safari/QuickTime combination, and the merely average radio in the iPhone, I get a lot of dropouts. And it is really annoying.

All the apps have different methods for dealing with congestion, but they all share one thing: they leave you in the dark when the stream is having trouble. This is merely annoying for laptop/desktop based systems, but is downright dangerous for phone applications, where taking the phone out and looking at it is potentially hazardous while driving.

In many of these cases, something as stupid as closing the app and restarting causes everything to work fine; other times you can successfully wait it out. Apple’s mobile QuickTime player is particularly execrable at this; while using the ‘play in background via Safari’ option with ooTunes, WunderRadio or ESPN Radio’s wonderful new app, it is common for the stream to stop playing. When you unlock the phone and look you find that the QuickTime player has just … stopped. No error message, no info, nothing. You start it again and all is well. WTF? This is Apple’s fabulous consumer engineering?

This weekend I was at a horse show with my wife and two daughters (The Columbia Grand Prix — congrats to Laura Linback!). It was interesting, but the Redskins game was more pressing for me. So I listened (via my iPhone) to the game.

Or I tried.

Five bar 3G signal. Clear day, sunny, nothing going on, not that big a crowd at the show. But I could never keep a stream up for more than 20 minutes. (No jokes please!) And when it went down, it was with no information. Total FAIL. Start the app or the QuickTime player again, works fine. Rinse, lather, repeat.

So could developers of streaming apps add a little audio tone to let me know what the issue is? A proposal:

  1. Steady, low bong-bong-bong for buffering successfully.
  2. Increasing in pitch and tempo bing-bing-bing while the connection is non-progressing and timing out.
  3. Subtle (or not) boom for when the app stops trying and gives up.

(Yes, you could get more creative than this. Spoken word status info, informing as to whether the app thinks the whole network connection is gone, etc. But that would be gravy. Anything would be better than dead air.)

Developers, since your app is literally already talking to me, do me the courtesy of telling me when your app is having trouble. Don’t make me look at the screen for status information when I am already listening!

Explore posts in the same categories: Tech

Tags: , , ,

You can comment below, or link to this permanent URL from your own site.

One Comment on “Please Give a Beep! How to Make Streaming Audio Apps Better”

  1. sedwards Says:

    I have always thought that auditory feedback was way underutilized in application development. This is just one good example. There are many times when I would like to know what an app is doing without having to actually look at it.

    If there is any sound, it is usually associated with a particular event. Nobody ever thinks to associate sounds with the *state* of the program. For instance, as a developer, I would like to know that a long compilation is still running. A “tada” or “crash” sound when it finishes isn’t necessarily sufficient. I might be out of the room for that particular event. Better would be to have a non-intrusive “processing” sound in the background.

    A good analog for this is a clothes dryer. You might not hear the buzz when it finishes, but sooner or later you will notice that it isn’t running anymore. In the meantime, the sound is pretty easy to tune out. That’s what I want for my otherwise silent programs.

    It’s easy to expand on this idea. There might be different sounds for when a program is using too much CPU, progressing too slow, hitting lots of error conditions, or loses connectivity, as in your streaming example.

    Sounds like a job for a new framework!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: