User friendly

A Brief History of User Interface

That is a great video, and nothing here is meant as criticism of it. After all, it is meant to be brief.

It always bothers me a bit, though, when the fact that there was user friendly software before the windows/mouse GUI gets glossed over. The GUI was undeniably a big paradigm shift. (Being graphical by default, discouraging modes, being more event-driven, being more consistent, &c.) But there were plenty of people who wanted to—and did—make computers more accessible before it.

Ramblings about skeuomorphs

Amid the revealing of iOS 7, I started using a new app call Do It Tomorrow. This app is very skeuomorphrific. It not only looks like hand-written notes in a paper notebook, it also includes the desk, pen, coffee, coffee stains, &c.

During the WWDC keynote, Apple suggested that the most important thing about a product is “How it will make someone feel.” I argue that skeuomorphs are not about usability but about how they make some users feel. Indeed, I don’t think the skeuomorphs in Do It Tomorrow make the app more usable, but they do make it—for me—more enjoyable.

Rene Ritchie says iOS 7 is most skeuomorphic iOS yet.

One of the key aspects of Apple’s iOS devices is that they become each app.† The app takes up the full screen. The screen is how the user interacts with the app. The hardware beyond the touch-screen is designed to not distract from the app. In iOS 7, there are system things that can temporarily intrude—notification center from above and control center from below—but these are translucent overlays that emphasize the the device is still primarily the app. Well, Apple is actually emphasizing content now, but sometimes the app itself is content. Skeuomorphs can be content.

Speaking of notification center and control center in iOS 7, they appear glass and plastic, respectively, to me.

Guitar effects apps are an area where skeuomorphs are common. While I’d certainly like to see some more entries in that category that take a skeuomorphless approach, the look of guitar gear can be an important part of the feel.

So, despite Apple’s move away from skeuomorphs, I hope that some apps will still provide skeuomorphic options for those users who enjoy them.

†It occurs to me that this works directly against the sort of split-screen mode I have always wanted in iOS.

In the days before WIMP

You can look at the changes on Twitter similarly to the advent of a graphical user interface that made its debut in early-1980s computers. The design was called WIMP and stood for “windows, icons, menus and pointers.” Before WIMP, the only way to use a computer was by writing code, something most people couldn’t even comprehend.

—Nick Bilton, The New York Times

This isn't just oversimplification. It is just wrong. Before windows or pointers there was “user friendly” software. There was quite a lot of it.

Pause

The number one thing I want most from any iPhone app that plays audio (or video). In particular: Apple’s iPod app, Apple’s YouTube app, Matthew Gallagher’s Stream To Me, and Bottle Rocket’s NPR News app.

The biggest button on the app should be the pause button. The pause button should be separated from other buttons by as much space as possible. I should never go to hit pause and instead find only a spinner. I need to be able to pause even during the time between hitting play and when playback actually begins. (Or, as in the NPR News app, between entries in my playlist.)

The iOS home button

I think I understand why Apple choose to go with the single home button for iOS devices. I think the argument for it is much stronger than the single button mouse. The problem is that they once again didn't live with the limitation they set for themselves. They added double-clicks.

Double-click are much worse than a second button. We’ve known this for years. A number of users have trouble executing double-clicks, so it should only be used as a short-cut. Many other users have trouble understanding the difference between single-clicks and double-clicks. So many users have been mistakenly trained to always double-click. So, we have to program defensively to recognize and ignore double-clicks even when they don’t do anything. Not to mention that some developers fail to understand how to properly use double-clicks, which just leads to more confusion among users.

I like the “recent apps” UI in iOS 4, along with its audio and other controls. What I don’t like is having to double-click to get to it. Worse, double-clicking is the only way to get to it. Though I suppose you could argue there is (almost) nothing the user could do through it they couldn’t do another way.

I think what I’d really like would be three buttons: Home, Spotlight (search), and Recent Apps. Without two more buttons, though, perhaps there’s another way to make it work better.

Consider this: When you are in an app, pressing the home button takes you to the last home screen you were on. Pressing the home button again takes you to the first home screen. Pressing home again takes you to Spotlight. These are not time-based double- or triple-clicks. These are just sequential uses of the home button in different contexts. Given a single button, I think I’d like my first press of it to take me to the recent apps. Pressing the home button again would then take me to Spotlight. A third press would take me to the home screen.

Although, I’m not entirely sure about the order of the last two. Since the recent apps only takes up a strip at the bottom of the screen, perhaps an on-screen Spotlight and Home buttons could be added to allow the user quick access to both. Then the home button becomes simply a “recent apps” button.

Sony’s Google TV controller

Sony’s Google TV controller outed on ABC’s Nightline

Gruber says: “Seems like a lot of buttons.”

Most of them, however, are a QWERTY keyboard. That’s a configuration of buttons that is familiar. It’s not intimidating. In fact, I think this remote is a lot less intimidating that a U-verse or DirecTV remote.

The Apple Remote, on the other hand, has always had too few buttons.

That said, I’m not convinced this Google TV remote is a win, but I’m not convinced it’s a fail either.

Ui faux pas

“User Interface of the Week: Max Magic Microtuner”

I’m all for lambasting a company like Adobe for its user interface sins. A little company, however, could use constructive criticism rather than being held up for humiliation.

In fact, Gruber’s “Ronco Spray-On Usability” contains such advice. To paraphrase: Usability isn’t something you can add later. You need to start with it.

Streaming AV UI

Audio/video players can be playing or paused. Streaming AV players, however, have a third state: Waiting. Waiting is like paused in that the content isn’t being played. In the wait state, however, playing will begin as soon as possible. Unfortunately, this third state isn’t directly exposed to the user.

Often the user can’t definitively distinguish this state. If the player is waiting and the user activates the play/pause control, what should the player do? Often the user can’t move the player between the paused and waiting states, and I know at least one user who often wants to.

There’s another wrinkle. Most players don’t switch from waiting to playing as soon as possible. Instead, they use heuristics to try to ensure that they have enough content buffered to prevent having to fall back into waiting. This is a good thing, but it means that waiting is actually two new states: Waiting and buffering. When the heuristics fail, it is reasonable to allow the user to override them, forcing a transition from buffering to playing. Some players give the user this ability, while others do not.

That’s the basics of the situation. Maybe sometime I’ll put together a chart of the states and figure out what should be communicated to the user and what controls should be provided to the user.

Nielsen and Norman on Gestures

Gestural interfaces: A step backwards in usability...

Yes, new technologies require new methods, but the refusal to follow well-tested, well-established principles leads to usability disaster.

I completely agree. Most of this article covers this and covers it well. There’s been too much abandoning of important user-interface principals with the iPhone and iPad. Apple ought to know better.

Bold explorations should remain inside the company and university research laboratories and not be inflicted on any customers until those recruited to participate in user research have validated the approach.

Following known principles is important. User testing is important. You cannot, however, fully vet an UI in the lab. Lab testing only goes so far. Then you’re going to learn a lot more a lot faster by releasing it into the wild.

Apple’s mistakes

From the iPhone OS 4 SDK, section 3.3.1 of the iPhone Developer Program License Agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This is one of the ways that Apple is keeping Flash off iDevices. It—intentionally—keeps more than Flash off of them. (See “Thoughts on Flash”.)

It is, unfortunately true, that cross-platform frameworks often have lousy user experiences. Not merely “un-Mac-like” but just plain bad. It’s true that they often only end up supporting the lowest common denominator. It doesn’t have to be like that, however. Cross platform frameworks can support platform-specific features. I’ve worked on ones that have. It is all too rare though.

There’s also the fact that some apps—especially some games—don’t really need standard user interface elements. Flash (and other options) can work well for these things. If anyone chooses to use Flash for another sort of app, they’ll quickly lose to non-Flash apps. I’m glad not to have Flash in Safari on my iPhone or my iPad, but I don’t mind Flash apps.

Section 3.3.1, however, doesn’t only ban cross-platform frameworks. It bans writing honest-to-goodness Cocoa Touch apps written in any but the specified languages. (“Platform Control” by Mark Bernstein.)

It has been suggested that a compromise might be to require any frameworks to be open source. (“A reconciling proposal” by Michel Fortin.) That way, any developer that needs access to a specific feature can add it to the framework. That’s a good idea. Yet, the truth is that such extensions to a framework can be a lot of work—especially for someone who normally only uses the framework.

Ian Bogost has written that “Flash is not a Right”. He is right, I suppose.

Putting aside rights, however, I have to wonder if this is really in Apple’s best interest. I have to wonder if this is really in the best interest of Apple’s customers. Apple’s biggest mistakes, I believe, are when they try to compete via the law. Whether through intellectual property or license agreements. They compete and win in the market. They don’t need to play the legal games.

Scoring the iPad without having used it

In iPad About, Stephen Fry writes:

There are many issues you could have with the iPad. No multitasking, still no Flash. No camera, no GPS. They all fall away the minute you use it. I cannot emphasise enough this point: “Hold your judgment until you’ve spent five minutes with it”. No YouTube film, no promotional video, no keynote address, no list of features can even hint at the extraordinary feeling you get from actually using and interacting with one of these magical objects. You know how everyone who has ever done Who Wants To Be A Millionaire? always says, “It’s not the same when you’re actually here. So different from when you’re sitting at home watching.”? You know how often you’ve heard that? Well, you’ll hear the same from anyone who’s handled an iPad. The moment you experience it in your hands you know this is class. This is a different order of experience. The speed, the responsiveness, the smooth glide of it, the richness and detail of the display, the heft in your hand, the rightness of the actions and gestures that you employ, untutored and instinctively, it’s not just a scaled up iPhone or a scaled-down multitouch enhanced laptop – it is a whole new kind of device.

It’s not about the extra features. It’s about doing the basic features right. It isn’t about what it does; it is about how it does it. It isn’t about the number of features; it’s about the user experience.

Yes, you can browse the web and do e-mail on a laptop, a “smart phone”, or a netbook. Yes, the iPad doesn’t have other features that those devices have. What Apple is claiming is that the iPad handles these basic features—like the web and e-mail—better than those other devices.

Here are the tasks Apple touted as what the iPad needs to do better than a “smart phone” or a laptop. I’m guessing at how well it will do in each category.

By the by, I’m not a laptop person. I’ve used laptops, so I can do some comparison, but—for me—the comparison against my iMac tends to stand in for the laptop.

Web browsing: I’ve surfed the web on desktop computers, laptops, “smart phones”, and on my TV. There is a time and a place for using the web from all those devices. Most of the time, however, I’d prefer to be doing it the way it looks in the iPad demo.

E-mail: Pretty much the same story as web browsing. (Except I don’t think I’ve ever done e-mail on my TV.) I still want to access my e-mail from my iPhone and my iMac, but I expect the iPad will become my preferred e-mail access.

Viewing and sharing photos: Yes. Hands down. The iPhone will still be preferable for taking photos simply because it can and the iPad can’t. The iMac will still be preferable for organizing and sharing online. Still, viewing and sharing in person is an important thing that the iPad does look better suited for.

Video: Having watched movies on both a laptop and my iPhone (and my iMac), I think the iPad will be preferable. Of course, I expect my HDTV will still be preferable to the iPad, but perhaps not my standard-definition TV.

Music: I don’t see how the iPad adds significantly to this. Better browsing but that isn’t much. My iPhone will still be my preference.

Games: It depends on the game. Some games are going to be better on my iPhone; some on my iMac; some on the iPad.

E-books: It depends. For some books—like most fiction—I think I’ll still prefer my iPhone. For other books—like PDF RPG manuals—I think I’ll prefer the iPad.

Flatland, 10/GUI, and SEO

A trio of interesting things found today. (All thanks to Daring Fireball, I believe.)

In “Flatland”, Lukas Mathis presents a very good rebuttal to some of Tog’s viewpoint. I think I may agree with everything Lukas says there.

Lukas’s blog then pointed me to 10/GUI. I think they hit the nail on the head with the idea that the next step in GUIs is not from two-dimensions to three but to fewer dimensions. I don’t know if they have the answer, but I know that the answer involves the user spending less time managing windows.

In “Spammers, Evildoers, and Opportunists”, Derek Powazek says that “search engine optimization” is a racket, which has been my gut feeling about it. Although, I suspect that the things he calls “obvious” are—sadly enough—not obvious to a lot of people. Those things, however, aren’t really about SEO. They’re just about making a good web site.

Mac file types and creators

Mac OS X 10.6, a.k.a. Snow Leopard, no longer uses an old Mac method of deciding which application to launch when you open a document. The upshot of it is that, by the old method, a document would usually be opened by the application that created it. With the new system, all documents of the same type will be opened by the same application regardless of which application created the document.

Also, the system will ignore the older way of marking the type of the file in favor of filename extensions. (Which are the “.html”, “.txt”, “.doc”, &c. at the end of a file’s name.)

There is still a way to tell the system to open a specific file with a specific application, but this can only be done “by hand” through the Finder. Other programs cannot safely do this.

“Metadata madness” by John Siracusa does a good job of explaining it all in more detail.

Personally, I avoid letting the system choose what app to open files with unless I am very sure of what it’s going to do. I can’t disagree with those who say that the functionality of creator codes ought to be restored, whether in the old form or a newer one. I won’t personally miss it, though.

I think something like Quicksilver is the future. Quicksilver is an application that allows you to quickly find documents and specify what you want to do with them. Even better, it learned from the user and was expandable. Google Quick Search Box seems to be the successor to Quicksilver, though it hasn’t caught up with all of Quicksilver’s features yet.

The biggest problem with the old Mac creator and type codes is that there was never a user-friendly way to manage them. Users could easily get into a situation in which they needed to set or modify the type code for a document, but the system didn’t give them a way to do it. There were utilities to do it, but they typically exposed the codes directly rather than providing the good user-interface you’d expect on the Mac.

UTIs are fine upgrade for type codes. Although, I’m ambivalent about UTI’s depending upon filename extensions. Filename extensions are an awful way to store file type metadata. Yet, I can’t argue with their practicality.

Examining the contents of a file to determine its type is often better than any type of metadata, though there are times when metadata is better. (Mac OS X actually comes with a Unix command-line utility that determines file type by contents.) I think a combination is probably the best choice.

Putting aside the issue that the system doesn’t use bundle identifiers in the same way, they are a fine upgrade for creator codes.

The spinner lie

To make software user-friendly, we added progress meters whenever the computer performed a lengthy task. Often, this was more work than you might think. It’s usually easier to just start doing the work and notice when the work has run out than to calculate how much work there is to do so that you can report the “percent done” as you go.

Sometimes, though, we’d run into something where we really didn’t have any way to know how much work there was to do. So, we’d use some type of spinner or throbber. The user didn’t have any idea as to how long the operation would take or how far along it was, but at least they could see that progress was being made and if progress stopped.

Then we’d get lazy. Even when we could calculate how much work there was to do, we’d not bother and just throw up a spinner instead of a progress meter.

Then came the lie. The spinner became an animation that continued whether progress was being made or not.

Mac/PC apps = trouble; iPhone apps = fun

Bruce Tognazzini—Apple employee #66—developed the first version of the Apple User Interface Guidelines. In “Restoring Spring to iPhone Springboard” he writes:

Unlike the Finder or Desktop, rather than giving access to as many apps as you could possibly want, the current Springboard limits you to 180 apps. Paradoxically, this would not be a bad upper limit on a Mac or PC, as apps tend to equal trouble and the more you have, the more trouble you’ll encounter. On the iPhone/iPod Touch, however, 180 apps is terribly limiting as iPhone/iPod Touch apps translate to fun, not trouble, and the more apps you have, the more fun you can have.

It’s funny because it’s true!

Ever since I bought a Pilot (the first name of the Palm PDAs), I have thought that it presented a pretty good model for how the “next Mac” should work. Besides a lot of legacy stuff that the Mac has naturally accumulated, even it has always forced the user to deal with some concepts users shouldn’t even have to know about. For me, while the iPhone has made some advances, it has also made some steps backwards from the Palm OS.

That’s another post, however, that is sitting around amongst my blog drafts.

You can argue that the user-interface for a PDA or phone is too simplistic for a general-purpose computer, but I’m not convinced. Both my Palm devices and my iPhone come awfully close to being general-purpose computers, and I think that for a great many people, their user-interfaces would be more than adequate on a desktop or laptop machine. (We already have plenty of options for geeks like me.)

Back to Tog’s article: He proposes some changes to the iPhone “home screen” app—internally called Springboard. While I like Tog’s proposal, I think he’s too quick to dismiss search. While I’m not a fan of ditching “browsing” interfaces, I’m seeing search becoming more and more primary.

With maybe a dozen exceptions, I’m more likely to google for a web page rather than go looking for it in my bookmarks. Even back c. 1995, I was more likely to use the Finder’s search to locate files than by browsing. Now, it’s Spotlight. Amongst all the brouhaha around Mac OS X 10.6 (Snow Leopard) no longer supporting creator codes, I’m thinking more than ever that something like Quicksilver is the future.

Of course, I’ll be the first to admit that I’m not the average user, but I think Google’s success shows that average users—when given a really good search capability—will use it.

Time spent improving the app search on the iPhone would give more bang-for-the-buck than Tog’s proposal. So, that’s what I’d do first if I were Apple.

And one mistake Tog made: Using dots to indicate vertical scroll position. This should use the standard iPhone scroll “thumb”.

Input

Can you touch type? Do you remember how long it took to learn? All those hours of AAAA SSSS DDDD FFFF. Was it worth it?

It’s funny to me how so many people seem so quick to disregard a new input device after less than a day of use. Efficient input requires not only a good device design but also practice by the user. Heck, even voice recognition systems can take some practice to learn to use well.

I used to always tell people that, if they tried using a trackball instead of a mouse, they really needed to try it for a few weeks before they could be sure that they didn’t like it.

When you first try Grafitti, you’re likely to be frustrated. After a few weeks, however, it’s fine. It’s certainly better than any attempt at full handwriting recognition would have been on the Pilot.

The iPhone’s software keyboard may not seem like a great alternative to a hardware palmtop keyboard. After a few weeks, however, most people will be fine with it. The advantages of the software keyboard are numerous.

I don’t know that our laptop and desktop keyboards will be replaced by dynamic, multi-touch surfaces á la Star Trek The Next Generation anytime soon. I do think, however, that palmtop hardware keyboards will soon be in decline.

I really would like a fold-up Dvorak keyboard that would work with my iPhone, though.

A good thing about “full page zoom”

I really didn’t see any need for web browsers to implement “full-page zoom”. Pretty much the only times I’ve wanted to zoom-in on a web page it has been because it used too small of font in too wide of a layout. Making the text larger while keeping everything else the same size was exactly what I wanted. Thankfully, Safari (at least) has keep text-only zoom as an option.

Today, though, I realized a use for “full-page zoom”: To make an overly wide web page narrow enough to fit in my browser window by zooming out.

Of course, I wouldn’t need either use of zooming if people did a better job of designing web sites. Yeah, and I realize my idea of “better” is different than some other people’s. But they’re wrong, and I’m right. (At least, here on my blog.) (^_^)

Now if I could only use “full-page” zoom-out and text-only zoom-in together!

The new command line

Coding Horror had an article called: The Web Browser Address Bar is the New Command Line

I once developed the “perfect” search GUI. It had all the power and flexibility you’d want, and it was all visible.

My boss and mentor said even he found it intimidating. Intimidating the user was not what I was going for.

So, I went about applying progressive disclosure. The power wouldn’t hit you all at once, but would be made visible in little pieces. I hoped in a natural way that wouldn’t prevent people from finding the power when they needed it.

(Aside: Progressive disclosure is in direct conflict with visibility. Too many times these days visibility is being sacrificed. Users either don’t know about a feature or get frustrated trying to find it. Progressive disclosure is a good tool, but it needs to be used carefully.)

My boss’s answer? The same one Google would come up with. A simple field and search button backed by an engine that would just return the answer the user wanted without the user having to figure out how to properly form the query. No GUI for forming the query. No special syntax for forming the query. Just a box and a button (and a smart engine). He was right.

I loved a to-do list application I used that had a simple text field for deadline. I could type “today”, “tomorrow”, “Friday”, or any number of other simple and direct ways of expressing it and the application would figure out the appropriate date. I was disappointed when the “upgraded” it to a fancy calendar control.

Something similar came up at work recently: Do we give the user a multi-select box full of choices or just a text field to list choices separated by commas? In this case, the text field really was the better choice.

I started this post before I’d seen it, but I am now reminded of Guy Kawasaki’s interview with the author of In Pursuit of Elegance: Why the Best Ideas Have Something Missing.

Double-click

Back when the Macintosh was first being designed, user testing suggested that many people had a hard time remembering what more than one button on a mouse was used for. So, they put one button on the Mac mouse.

They really seemed to feel the need for more functionality, though, so they added double-clicks as a short-cut to some extended actions. Of course, double-clicks were hard for some people.

So the cardinal rules of double-clicks were:

• Double-clicks should never be the only way to do something; they should simply be short-cuts
• A double-click action should be a natural extension of the single-click action

Of course, one of the big problems was that users ended up learning to always double-click. I’ve run into people who were genuinely surprised to learn that a single-click did anything. Even more people didn’t realize that there were other ways to accomplish double-click actions.

It’ll be interesting to see how Apple’s choice to have some functions on the new iPod shuffle only accessible through double- and triple-clicks and holding works out.

Mac menu bar + multiple monitors

Yes, Fitts’s Law justifies the Mac menu bar being anchored to the top of the screen.

But then I find myself doing this dance:

1. Move mouse onto secondary monitor to active a window.
2. Move the mouse back to the primary monitor to get to the File menu. (Of course, my second monitor is on the right and the File menu is on the left.)
3. Move the mouse back to the second monitor to choose options in the print dialog box that slid out of the active window’s title bar.