Beacon Blog: Interactive | St. Louis Public Radio

Beacon Blog: Interactive

Jan 17, 2011

This article first appeared in the St. Louis Beacon, Jan. 17, 2011 - I previously posted about the difference between "visual" and "interactive" after the election. A very good New York Times graphic making the rounds was being called a great example of interactive storytelling. It had a next button.

By that standard, I said, a book or a newspaper is interactive because you need to turn the page. Something that's interactive can show different levels of complexity, but often requires the viewer to dig out the information he's interested in.

At the time I said, "And there's the double-edged quality of an interactive feature: It can contain a lot of information and display it in innovative, customizable ways, but the user must figure out how to get at that information himself."

Basically, the user must understand what he's supposed to do or he runs the risk of missing something.

I was reminded of this by news that the next software version of Apple's iOS (which drives iPads, iPod Touches and iPhones) has a few new gestures that will let users navigate those devices in new ways, and subsequent speculation that Apple will then drop the single button that now graces the front of each of its devices.

The tech blog Boy Genius Report has a post saying that may be the case: "Our source said Apple employees are already testing iPads and iPhones with no home buttons on the Apple campus, and it's possible we will see this new change materialize with the next-generation iPad and iPhone devices set to launch this year."

Technology commentator John Gruber at Daring Fireball disagrees: "These gestures do mean that you don't have to use the Home button. But there's a serious discoverability problem with them."

I'd tend to agree with Gruber. It's handy that designers often provide many ways to accomplish something. To scroll a Web page, I can click the up and down arrows on the scroll bar, grab and drag the "bubbled" part of the scroll bar itself, click in the "empty" part of the scrollbar, use my mouse's scroll ball, use the up and down cursor arrows on the keyboard, use the pageUp and pageDown buttons on the keyboard, or use the spacebar and Shift+spacebar. Those options are convenient in their own ways based on where my focus currently is (keyboard or mouse, if mouse, where's the pointer?) and what my goal is (scroll a few lines, a complete page or to the extremes of a very long page?).

But the point is that a few of those options are very self-evident that they'll scroll the page. The up and down arrows on the scroll bar only do that one thing. That's also the function of the pageUp and pageDown buttons. You might easily guess that the up and down keyboard arrows will accomplish the same thing. Providing these simple, apparent ways of accomplishing the goal accommodates people who aren't and don't want to be keyboard shortcut experts.

Especially when using a new method of interacting with something, like a touchscreen, people progress through stages of learning about it. It's important that the process facilitates that learning without being frustrating.

"Discoverability," as Gruber puts it, is key. If someone wants to accomplish a goal like scrolling a page or going to a certain screen, is the way to accomplish that goal immediately apparent? If it's not, is it likely the user can discover how to accomplish that goal based on normal usage?

For example, the Beacon has many categories. You can choose to see all of our region stories at once, or all the visual arts stories. One way to do this is by clicking the "tab" that appears above each of the featured stories (below the top stories) on the front page. If there's a story in the "visual arts" category on the front page, you can click on the "visual arts" label and be taken to a listing of all those stories. This is a nice shortcut, but we don't assume people will know to click on those labels, so we provide a more traditional menu navigation system at the top of the page. If we removed the menu completely, it's my guess some readers would be lost.

Designers must make assumptions as to how much the audience knows already and how much they're willing to experiment to discover new things. One way to widen the usability to novices and experts alike is to have very obvious ways of accomplishing goals even if they aren't usually efficient (e.g. a menu item to "Cut" text) and to have very efficient ways of accomplishing goals even if they aren't usually obvious (e.g. the CTRL- or CMD-X keyboard shortcut).

But I think the key is to have both. If the design is obvious but inefficient, it will eventually become frustrating to use when users want to accomplish more, more quickly. If the design is efficient but unobvious, users will be frustrated from the beginning and may not put in the time necessary to learn how to use the design.

The efficient but unobvious four-finger swipe gesture will switch between active apps on an iPad or iPhone. I think, for the sake of usability, the less efficient but infinitely more obvious method -- press home button, choose app -- will remain.