Silke and I have an old Archos DVR. I’ve never been extremely happy with this device, but it gets the job done. Last night I recorded the Lost season premiere. Instead of scheduling a recording, like I usually do, I just started a recording immediately, expecting it to keep recording until I hit Stop. Instead, it stopped on its own after an hour and fifteen minutes.
Wanting to know why, I checked the built-in manual. The Archos manual is a 79-page PDF file that you view on-screen. You can view about half a page at once, and the scrolling is slow. It doesn’t automatically advance to the next page when you scroll past the bottom; it takes three button presses to do that. And it takes it about three seconds to render a page.
No matter how good the content is (and, to their credit, I did find the answer), this is a complete failure of a delivery mechanism. This got me thinking in general about best practices for help embedded in set-top boxes, appliances, mobile devices, and other systems with limited interaction or screen space.
I’m sure it’s no surprise that I think the best thing in this case would be topic-oriented help. A device like this almost certainly needs a printed setup manual, but beyond that, people are mostly going to look for specific answers. And they’ll lose any printed material you give them, so the best place to put the help is on the device.
Devices like this present some unique challenges. Things we take for granted in the desktop world aren’t necessarily so elsewhere. Any UX people with experience in mobile or embedded devices could probably talk my ear off about this. (Please do, by the way.) So what kinds of problems are there?
- Disk space is often limited. My Archos has a hefty 80GB hard drive. That’s huge by embedded standards, but tiny by desktop standards. Help files take up space, especially once you start adding figures and screenshots.
- Screen space is limited. Applications usually run fullscreen, and that would include your help viewer. The fact that you can’t view the help and the helped application side by side can really affect the way you write.
- Another effect of limited screen space is that there often isn’t enough space to put lots of context-sensitive help buttons in the UI.
- Interaction is cumbersome. Mobile devices almost always use a touch interface these days, and for a lot of things that’s very powerful. But set-top devices that use your TV usually just use a rocker on a remote. That’s a terrible substitute for a mouse. And text entry without a keyboard is never fun.
I don’t buy into the notion that desktop systems as we know them today will die any time soon. But it’s clear we’re going to see more and more of these sorts of devices in our daily lives. So I’m very interested in how we can provide better user assistance in this area.
It looks like there are a couple of related talks at the upcoming WritersUA Conference. Unfortunately, I won’t be able to attend one of them because I’ll be presenting Mallard in the peer showcase.
I don’t even look on my device for help … not even when it can browse the web like my G1. I just deal with the problem until I get to a computer.
So +1 to the idea that something needs to change.
So, why did it stop after an hour and fifteen minutes?
There’s a setting to automatically stop recordings after a set amount of time. It was set to an hour and fifteen minutes. The help indicated that the setting is pre-set to two hours (which would have been great). I have no idea how or when it got changed (could have been me futzing around at some point). But at least I know in the future.
From the title, I thought you were going to talk about help that’s embedded in the application. That may be a partial solution for limited devices, to give help about the settings on a particular screen, right there on the same screen. But it won’t cover this use case, of not knowing what the relevant setting is, or where it is. As you say, search would be difficult to manage without a keyboard. Seems like one solution would be really, really good (human-generated) index, so you could browse it for likely topics (in the user’s terms, not the writer’s or engineer’s).