'Ugly' + 'confusing' doesn't equal 'smart'

[caption id="attachment_7884" align="alignright" width="300"] Peter Coffee[/caption]

It was probably the least expected message that I’ll ever get from the Society of Automotive Enginers. (Actually, they now call themselves “SAE International”—and address aerospace and other disciplines—but I’ll always think of them by their legacy name.) In SAE’s December 3 Type & Technology eNewsletter, the first article’s title was “Why Fonts Matter in Vehicle Displays” – with subsequent item titles including 'What Makes It Legible?' and 'Font Technology: Making Type Work.'

I found myself thinking, 'About time.' (In my mind, there may have been an emphatic adjective in the middle.) At this year’s Los Angeles Auto Show, one of the things I noticed was how ugly (which is bad enough) or confusing (which is much worse) are the latest-generation “soft” displays—or the attempts at classically retro-themed gauges—in any number of vehicles. This is, I suggest, only the merest hint of the challenges we’ll face in building a world of smarter and more helpful devices – and it means we have a lot of work to do.

The in-car environment is, I’d suggest, the fastest-changing place where we routinely spend so much time – but innovation in our cars is not going well, in terms of telling people what they want to know or enabling the actions they need to perform. The global quality-assessment experts at J.D. Power have even noted a correlation between declining owner satisfaction and the introduction of new in-car technology – summarized by the comment of their VP David Sargent that “almost all automakers are struggling…with some consumers indicating that the technology is hard to understand, difficult to use, or simply does not always work as designed.”

Not just in the car

The problems noted by J.D. Power are not limited to simple readability, but I ask you to let me stay on that subject for just a few more moments – because the problem of 'Can I read it? Can I understand it?' is not limited to automobiles.

How many times have you been walking through an airport, or a hotel lobby, or any other place where formerly static information signs have been replaced in the last few years by great big flat-panel displays – only to see one of those elaborate displays made useless by technology that they’re supposed to hide?

How many times have you seen one of those signs disfigured by some silly error dialog, or even completely wiped by a bootup or screen-of-death dump that looks like something from the 1980s?

How perverse is it that just when you really need to know what’s gone wrong, the system abandons all effort to communicate in a readable way? Here we are, more than thirty years after the first Apple Macintosh computers put font design and choice in the hands of mere mortals: that’s twenty Moore’s-Law cycles, in theory more than a millionfold improvement in many measures of performance, but we’re still limited by what we can quickly and accurately read on a display – because designers don’t make it their responsibility to deliver a superior experience in every situation.

Any idiot can make something understandable when everything is working correctly, but the moment when greatest clarity is needed is when something is broken and needs to be understood before it can be fixed. “Complex systems usually operate in failure mode,” correctly observed John Gall in his subversively accurate Systemantics – by which he meant, not total failure but something significantly less than all-systems-go.

Too often, though, it seems as if the defining difference between analog and digital systems is the difference between a degraded but useful partial failure, and a brittle collapse. We’re surrounded by systems that give up, when even partially broken, on making themselves understood – as the first step of degradation, when it ought to be the last.

According to Steve Jobs

To widen the field of comment beyond the displayed word, the next thing that came to mind as I looked at the SAE newsletter was Steve Jobs’ most savage criticism (in 1996) of a much larger Apple competitor:

They just have no taste.

If I may be allowed to interpolate, I believe he was saying that if something is going to become widely used—for any number of utilitarian or economic reasons—doesn’t that almost obligate the creator to make its use a pleasing experience?

Apple’s products are not the only example of things that are loved by users, and priced well above functionally comparable competitors, simply because people like the way they look and behave. Struggling to read a label or understand a readout is a trivial problem, compared to becoming fatigued and sloppy because something fits poorly in the hand, or being distracted because something doesn’t make its operations apparent through touch or sound (so that we can keep eyes on the task, not the tool).

The need to go beyond mere function, and add a huge fraction of total value with superior design, is going to be a critical component of the so-called Internet of Things. Obsession with the idea that “everyone needs to learn to code” is only useful up to a point: beyond that point, it’s like improving students’ handwriting while failing to teach them logic or inspiring them to attempt poetry.

Skills issues

That brings me to my third point here, having started with text and broadened the discussion to a more general concern with design. The final point is the tripartite question of skills: how to recognize them, how to develop them, and how to manage and apply them.

There’s constant debate, of late, about the reality or the myth of a skills gap: a mismatch of what adds value in today’s economy, versus the things that most people are trained or are natively able to do.

Whether real or perceived, this phenomenon is clearly driving programmer salaries and prerequisites into the stratosphere while general wage levels stagnate (or even decline). Simple generalizations, like 'we need more maths in the curriculum to build a pipeline of more programmers', may be a misapplication of resources.

Being able to code is enabling, absolutely, but it’s no more than that. Coders can’t just say, 'Give us the requirements and we’ll give you the code'.

Ride-alongs with field personnel, work-alongs on the assembly line, sell-alongs with shop-floor workers, sit-alongs with call center operators: these are also crucial aids if we want systems that do more than frustrate and annoy us, better and faster and cheaper and in more environments than they’ve ever frustrated and annoyed us before.