Category: <span>User Experience</span>

In 1980, my uncle gave me an Apple ][ plus for my birthday. I had been telling any adult who would listen for about a year that I wanted a computer. Most of the time the response was something along the lines of, “Why do you need a computer?” Honestly I didn’t know, but I knew they were cool, and I fantasized daily about owning a Commodore Vic-20 or a Sinclair ZX80. Honestly I thought the Apple ][ was pretty far out of reach for this 11-year-old, but my wealthy uncle thought different.

It didn’t come with a disk drive – he didn’t know any better. It had 16K of RAM, and when I got it, I didn’t have a monitor or even an RF-modulator to hook it to a TV. I could literally do nothing with it on the day I got it. Fortunately my mom had an old B/W monochrome monitor kicking around her lab, and she brought it home so I could use the computer.

It was about 6 months before I got a disk drive, and during that time I wrote many short programs in AppleSoft BASIC, occasionally saving them to audio-cassette, but more often losing my code when the computer was turned off. The one (there was only one) at my middle school had a disk drive, and I owned a single 140KB Verbatim disk at first. I kept all my work on that disk, which still exists in a box in my mom’s basement in Kansas City as far as I know.

The Apple ][ plus was an all upper-case computer with a 40×25 character display. There was a shift key on the keyboard, but that was for punctuation and special characters over the numbers. There was a CTRL key, an ESC key, left and right arrows, and a RESET key. But there were no function keys, no Alt, Option, Fn, Tab, Apple or “cloverleaf” keys, and no numeric keypad. (I have a slightly interesting story about the REPT key for another day.)

Input was super minimal:

Little did I know at the time, that the first spreadsheet program had been developed a year or two earlier. Enter Dan Bricklin’s and Bob Frankston’s VisiCalc. Here’s a screenshot:

I didn’t get my hands on VisiCalc until 1981. The first thing any Apple ][ VisiCalc user had to know was that the ‘/’ (forward-slash) key brings up the menu on the top row of the screen. You used the left and right arrow keys to pick a top-level command, and hit RETURN. At least some of the commands then had a sub-menu which would appear on the second row, and then you’d hit RETURN again to execute the command.

It was a really elegant system for using just four keys to represent a command hierarchy on two lines of all upper-case text, just 40 characters long. That was about 8% of the total available screen real estate, which was otherwise occupied by some status readouts – location, cell contents, formula, etc. Bob Frankston wrote up his experience of Implementing VisiCalc, including a few paragraphs about how the ‘/’ key worked.

In late 1996, 15 years after I first saw VisiCalc, I started my own “online journal” and completely subconsciously copied this idea for my site’s navigation. (I only just now realized that.)

I have no idea if this was an original idea introduced by VisiCalc, but whoever’s idea it was, it stuck. We have today menu hierarchies hanging off the top of screens on the Mac, and at the tops of windows on Windows, at least until Metro broke the paradigm — we’ll see how that goes.

You’re rambling, Jake – what’s your point?

Something else that stuck around, at least in the spreadsheet world is the ‘/’ key. I don’t know if they copied it directly from VisiCalc or if Lotus copied it first. And I’ve never used Lotus, so I don’t know if they used it or not.

But to this very day in Office 2010 on Windows the ‘/’ key puts focus on the “Ribbon” – the 2010 version of those top two 40-character, all upper-case, B/W inverted rows of text on the Apple ][ version of VisiCalc.

Try it for yourself – it’s pretty amazing.

Sadly, the Mac version of Excel doesn’t do anything special with the ‘/’ key. Somewhere along the line, VisiCalc’s religion was lost to the Apple universe, but it still survives over in Microsoft-land.

PS. I also had one of these.

PPS. GuyZero commented over on Metafilter about Lotus 1-2-3’s use of the ‘/’ key, so Lotus did in fact keep the VisiCalc legacy alive too.

PPPS. Bonus link – Dave Winer: What early software was influential?

Seen recently in my Twitter feed:

“No matter how beautiful, no matter how cool your interface, it would be better if there were less of it.”@alancooper #dataviz #UX #UI #ppt

— Edward Tufte (@EdwardTufte) February 12, 2013

I absolutely agree. Software should empower you, not distract you. It’s a tool, and like any good tool it should feel like a part of you. Once you know how to use it, the software itself should fade into your subconscious.

In cognitive psychology, they call this automatization. It’s what happens when you learn to balance and walk, learn to write or type, learn to talk, learn to drink from a water fountain, or learn to play a musical instrument.

Your brain very deftly, and quite without your knowledge, watches as you consciously and intentionally carry out repetitive or pattern-based tasks, often requiring lots of mental effort at first, and it creates little programs that do those same tasks without having burden your conscious mind with the specific moment-to-moment mechanics.

Soon, after some practice, you find yourself doing the same tasks seemingly effortlessly, and with high precision, while your conscious mind is free to direct your activity at a “higher” level.

But Jake, what does this have to do with UI design?

Because humans are so good at automatization – so good in fact that they do it nearly universally without even knowing it – user interfaces that are easier to understand quickly, will be easier to automatize.

By minimizing, focusing first on understanding, nailing key features, and minimizing frills and clever pixel-wrangling, you just might find that people actually like using your software more.

Why? It won’t get in their way. It’ll be quick to learn. It will feel good to use. It’ll probably run faster. And as an extra benefit for you, it’ll be easier to maintain and have fewer bugs.

And once people learn your UI, your software will become another useful tool, by accomplishing the task you designed it for. Just like a water fountain, or a spokeshave, or a musical instrument.

Don’t get me wrong – I’m all for beautiful designs, but for me at least, function comes first.

Apple has done an amazing job in this regard over the last 12-15 years, and not just in the iPhone/iPad world. They’re not the only ones, but at least in the consumer technology world, they’re almost undisputedly the best at it.

Less really is more…

Computers are hard. Software is hard. Many geeks reading this have a propensity for figuring out hard things, and an aptitude for seeing through… um… difficult user interfaces.

But that’s not good enough for most people. You’ve probably invested many hours in your UI and you think it’s great – but most likely it needs to be easier.

Here’s something to try:

Ask a non-geek to use your software for the first time and watch them carefully. It’s probably not nearly as easy to understand as you thought it was.

Where do they get stuck? Where do they ask questions, and what about? When do you see their face light with recognition and understanding? Try not to offer help or explanation. Let them explore and get stuck. You want to know about the problems people will hit when you’re not there with them.

Now before you do anything else, make some quick notes… And then go help your poor test subject.

Now it’s time to fix it. You’ve got your notes right?

One good way to cut through confusion is to make your UI simply… less.

Cut away all but the essential settings and controls, geeky preferences, custom scrolling ballistics, the animated GIF of your cat, and the sound you hear in your first-run walkthrough. (In fact, see if you can get rid of the first-run walkthrough altogether.)

Make your top one or two key interactions dead-easy. Then look again and see what you can do to help people understand your UI as a tool. Just by looking at it.

And then go test it again. Ask the person you showed it to last time. Then ask someone new. (You’re taking notes, right?)

Less really is more… Except when it isn’t

There are of course exceptions – scenarios for which this is exactly the wrong idea. For example, users often automatize clicking the Okay button on two-button dialog boxes.

But if the question you’re asking is:

… then you’re doing it wrong. Less UI isn’t always better UI. Sometimes you need to be “in your face”.

Some things to keep in mind

Here’s a short list, off the top of my head, of some of the things I try to remember when I’m thinking about UI design:

• Form follows function
• Focus on “core scenarios”
• Don’t make me think
• Simplify, simplify, simplify
• Text is really important
• Don’t assume people will read it
• Do you really need another preference?
• Be consistent, in context
• Respect prior art

I’m planning on writing more on these and lots of other UX-related stuff soon.

Stay tuned…