Thursday, July 24, 2008

Language-Based Interfaces, part 1: The Problem

The linguistic UI ...

"UI Design Fundamentals

What would the web be like if you could tell it what you want to do as easily as you currently tell it where you want to go?

Mozilla Labs is starting to experiment with linguistic interfaces. That is, we’re playing around with interfaces where you type commands and stuff happens — in much the same way that you can type a location into the address bar in order to go somewhere.

I think this is cool because, for one thing, I think language-based interfaces are seriously under-explored compared to pointing-based interfaces. For another thing, I used to work on a project called Enso. Enso’s a language-based interface, where you type commands in and stuff happens. I think we got certain things right and certain things wrong in Enso’s UI design, so I want to take another crack at doing it better.
What makes a good linguistic UI?

Here’s my current theory.

1. It’s easy to learn.
2. It’s efficient.
3. It’s expressive.

Those are the three “E”s. Let’s unpack ‘em a little.

“Easy to learn” should be self-explanatory. Even if a tool is super-efficient and incredibly powerful, if it’s too hard to learn, it’ll be relegated to the “experts only” ghetto. Yeah, that’s right, I’m talking about you, Unix shell. (ahem, Unix/Linux/Posix/BSD/etc.) The original language-based UI, the oldest UI still in common use, and the one which has given the whole concept of “type what you want to do” a bad name for the last thirty years, serves as an excellent counter-example. For a linguistic UI to be easy to learn, it should strive to avoid all of the following misfeatures of the shell:

* Not discoverable: There’s no guidance given to a first-time user. You type some letters and nothing happens: it feels like shouting into a void. If you don’t already have the basic commands memorized, there’s no way to figure out what they are.
* Cryptic names: Whether for historical reasons or for brevity, the standard names of commands, programs, and locations are all called stuff like ‘tar’ and ‘mkdir’ and ‘/usr/local/bin’. Because these names are unnatural and unfamiliar, they have to be learned by rote.
* No feedback: I just entered a command and all I got back was a blank line! It worked, but what did I just do?
* Options are hard to remember: Does the ln command take the source file first or the destination file first? What does the -z option on tar do again?
* Really easy to make mistakes: One wrong character and your innocent command is transformed into a ruthless file murderer. And there’s no undo!

But the CLI isn’t all bad. Obviously, if it was all bad, there wouldn’t be so many people still using it! I’m a programmer. I live on the command line. The learning curve was years ago and now it’s second-nature. I couldn’t live without it. So what are the good points?

The first good point is that you can get a whole lot done with just a few keystrokes, thanks to the very short names, the tab-based autocompletion, and the command history that lets you easily repeat or modify earlier commands. This makes it a very efficient interface. You can learn more about the precise (quantitative) definition of information-theoretic efficiency in Aza’s article, Know When to Stop Designing — Quantitatively. There are logarithms involved. If you don’t feel like doing math, all you need to know for now is this extremely simple concept: the fewer keys you have to hit to get the computer to understand what you want, the less wasted effort, the more efficient the interface."    (Continued via Humanized, Jono DiCarlo)    [Usability Resources]

0 Comments:

Post a Comment

<< Home

<< Home
.