User Centered

At the sake of making this a site dedicated to Apple's podcast UI management, I'd like to point out yet another change that came about with the 3.0 iPhone software update, but first, see the history of this topic on the site to get up to speed, also, Kenneth Maage's thoughts in the comments here are pretty insightful as well for a "how it should work" argument.

The scrubber (left-to-right slider) is very difficult to use with podcasts, and was a poor design decision.

...The fact that Apple added the 30 second rewind and the following scrubber fixes is enough evidence in the "user centered" court of law to state the above.

Well, 3.0 has another kludge up its sleeve that I stumbled upon. Now, when you place your finger on the scrubber a contextual message appears instructing you to pull your finger down to adjust the rate at which the scrubber will move through the track- the further you move your finger down, the slower it moves through the track. Let me paint you picture: You put your finger on the scrubber button, the message pops up, you drag your finger down and as you, the rate of movement through the podcast will slow down. You then move your finger left of right to move as normal, all this without picking up your finger.

There's a couple points of discussion here:

1. As I've said in the past- you have a dynamic, touchscreen UI, take advantage of that! They tried this with the gesturing, two dimensional scrubbing maneuver, but they still tie it to the traditional left/right scrubber!
   
2. ...which is the silly design decision here- we're moving an object at the top of the screen but our finger is positioned (in the case of "fine") nowhere near it! I think "kludge" is the kindest word I can come up with for how this interaction works. I'm all for having advanced features that are "value add" as long as they don't detract from the functionality of the product for those unaware (ex: Opera's mouse gestures); this attempts to be one of those, but considering the original functionality can hardly be called functional for anyone (advance or not) really makes me scratch my head.
   
3. Maybe I just need practice- but in actual use, I'm not sure this is all that useful. I found myself moving my finger up and down, left and right and losing the context of what I wanted to hear,...okay, this one is an anecdote, I retract it
   
4. ...but it's probably because they start out "fastest" and have you move your finger farther down the screen to get to the "slowest/finest" granularity. Of course, we're humans, and we can't move our limbs in precise, linear motions. The result is that as I'm moving my finger down to more finer granularity, there are slight movements to the left and right which cause the audio to jump around quite a bit (since they're higher speeds) and I'm "lost" before I finally get to the slower speeds. Keep in mind, the reason this was added was because the faster scrubs are worthless. It seems to me, that excusing all the previous points (ie- I wouldn't design it this way to begin with), it would make more sense to start out "fine" and drag your finger down to get higher speed scrubbing (the zoom out metaphor), but given the established UI expectations, this wouldn't make sense, you'd have to have a default fine scrub first.
   

I think I'll find some use of this feature, but I think it's mostly because I'm into these features much more than (I expect) the general population. I'll add it up to one more band-aid on an interface that is really starting to show it could use a "rethinking." It would be more useful if they ditched the "scrubber" widget on the screen and put something up that really conveyed this functionality. I'd suggest looking at kmaage's comments on the previous post for ideas on how to make these functions actually useful.

Way back in 2002, I found a little web browser called Opera that had this feature that just blew me out of the water...mouse gestures.

Since I've become to rely on them for browsing, I'm also looking at all the other plugins and extensions that extend this functionality to other pieces of software and interfaces.

Phones now have accelerometers that detect 3D movement, so it seems natural to use movement and gestures to perform functions on the phone.

I've just viewed the video for this phonepoint pen project by Duke students that uses the movement to translate and do OCR on captured movement to text. I think this is interesting, but not very practical. Instead, I'd like to capture the movement and translate them directly to commands. Keeping with the Opera browser mindset, I'm picturing a handful of easy to perform gestures that are one or two linear movements that can be turned into key phone functionality. Apple is tapping into this idea, they just announced "voice control" and they have a handful of physical based gestures- but they are just on the tip of the iceberg: they have "shake to undo" or "shake to refresh" functionality, but this can be extended...

• Speed Dialing a phone number (one gesture for each favorite contact)
  
• Launching a browser
  
• Initiate a desktop-to-mobile sync/handshake
  
• Move data from phone to desktop
  
• Copy, paste, delete, add...
  
• Refreshing the current view (existing)
  
• Shake to undo (exsiting)
  
• launch maps and use current location (ideal for auto based "where am I?" queries)
  

But mainly things you'd be likely to in an automobile or need to get at frequently and quickly...what I like about gestures, is that you can do them without paying attention to the interface- there's no mental/cognitive cycles spent doing mundane interface manipulation. You're using muscle memory. Like my browser mouse gestures, I can still be in the middle of finishing up scanning the text of the page and close the page without any movement to the "x" button (or any real thought). at the sake of going off on my mouse gesture tangent, I'll leave it at "if you get it, you get it, if not, you don't" and just press on: On the mobile device, this opportunity is greater. I think this is easier to use than even physical speed dial buttons since you'll have to orient your hand to the phone and find the right button. With a physical gesture, you can find a single "activate" button (which would be consistent for all gestures of course) and then just let your muscle memory do the flailing!

I can think of some contexts & settings where voice controlling would be more appropriate, and I can certainly think of times when it would be more discrete to swipe your phone quietly through the air.

Anyway, I'm almost certain that someone already has some form of this out that goes beyond the "shake to X" functionality, so I suppose I should just wait patiently for someone to point it out in the comments. I've seen the speed dialer app that lets you make a gesture on the screen of the iPhone to dial someone, but that has none of the advantages of abstracted UI that I mentioned.

It's taken a few years and many revisions, but iTunes has blossomed into a product that answers most of the issues addressed in earlier postings regarding podcast management/use. I'm still interested in podcasts and making the experience better- so I'm going to keep on keepin' on and focus on some of the finer details of the iPhone's UI when dealing with podcasts.


Look at these two pictures. The first is a podcast being played with the phone unlocked, the second is the same with the phone locked and the iPod functions activated (you can double tap the home button to turn on iPod controls while locked)

The most interesting design decision is the location of the volume function. While unlocked, it's the slider along the bottom of the screen, and the slider on the top part of the screen is for seeking into the track being played. When it's locked, however, the volume slider moves up to the top, in pretty much the same location as the seek function. Result? Annoyance...when I first started using the iPhone, I would try to seek the last part of a podcast and end up blasting my ears instead. It doesn't help that the controls look exactly the same.

Another design decision of note is actually using the slider for podcasts. I know I just used the last paragraph to knock the iPhone for being inconsistent, but music and podcasts are different. This slider makes pretty good sense for a 3-4 minute song, but podcasts are hour long tracks. A slight tick of the slider can be a minute or so- and spoken word is more difficult than music to seek, since you don't have a melody/context to place what you're currently hearing. Result? A useless slider function. (unless you're trying to get to "the halfway point" or "2/3rds" of the way through)

Finally, (and this is more hardware related) the modal next/previous tracks- because the track slider is almost useless to me when I want to "rehear" an interesting part of a podcast, I have to hold down the "previous" button to rewind. I wouldn't have a terribly big problem with this if the software/hardware for these particular functions weren't so finicky. It turns out, when I hold the button down, a significant (daily) number of times the hardware isn't registering a touch at all, and because the buttons is modal (hold or press), that slight 1 second delay before anything happens is always frustrating because I'm not sure if the phone has registered my finger press, or if I have to try it again. I look down at the buttons to see if it has the white "glow" indicating it's activated. And you guessed it...this battle often ends up in me pressing, instead of holding the button and restarting the track and having to seek into it (see first paragraph)

So, what can be done? Here's some thoughts:

• First, why not keep the volume in the same place throughout the UI? In the first screenshot, it seems more reasonable to locate the seek/track slider with the next/previous buttons anyway since the functions are related,and the volume could go on top.
  
• Next, why not offer a more precise control for moving through long tracks? I missed the iPod scroll wheel, but how about a zoomed (ala the OS X dock) slider?
  
• I know simplicity is a religion at Apple (that's an upcoming post btw), but you have a dynamic interface which you fully control, why so much ambiguity and modal controls on a virtual interface? (see:"bad idea for a software interface" for more thoughts) Would it be detrimental to the UI to add a seperate seek button?
  
• In both the previous bullets, I'd even accept a gesture interface to seek- maybe the number of fingers you use to swipe could indicate the time increments you seek by- one finger is seconds, two fingers is 10 seconds and three seconds could be minutes or something.