Thursday, November 10, 2011

The death and rebirth of useful interface affordances

Mainstream interface design, as a discipline, was born during the era of the early Macintosh circa 1984, and died during the early era of the Web. In some quarters, Flash helped bring a bit of real interface design back, but now with HTML5 and iOS and Android I think people are starting again to really focus on and understand what real interface is about again.

Let me explain.

For those of you not steeped in the language of design, an “affordance” is a characteristic of an interface element that leads one, through its nature, to understand what to do. This is a little more subtle than it seems. For example a button in a user interface has a “perceived affordance” in that when we see the button we know that we can click on it and something will happen.

During the early days of the graphical user interface, we had a beautiful collection of new affordances provided by the operating system. Windows that had draggable headers, buttons that were clickable and did something, dialog boxes that could be modal, meaning that they had to be dismissed before further action could be taken, etc.

This allowed for lots of innovation. But because we also, as developers, had access to low level graphical primitives, we could make new interface objects that had new perceivable affordances. For example, in the first drawing programs I ever saw, LisaDraw and MacDraw back in 1983 and 1984, clicking on an object caused “handles” to appear around the sides of the object. These handles told you that the object was selected, but they also made it clear that the given object could be resized. This was an incredibly intuitive and obvious affordance. We, as software developers, had the capacity to create new objects with new affordances like this that could be incredibly powerful.

Make no mistake, this could be abused, and was, by software developers that had more programming chops than taste, but the best and most important software during these golden years of graphical interfaces always created new interface objects and introduced new perceivable affordances.

This was important not for the sheer act of adding new interface widgets to the built-in palette of operating system widgets, but because it allowed us to do something which for the most part was, in the ensuing years, almost entirely lost from software design. It was the act of creating software that allowed users to understand the data model of the application and to interact with it in an intuitive way.

In an ideal world you want an application to expose its nature, its data model, to you through its objects. This means that without having someone describe what it is you need to do or provide menus of options, that you understand what to do by the nature of how the data model is exposed.

As a counter example, coming back to MacDraw, imagine if drawing programs required you to create a new web page for each object you wanted to add to your canvas. A “new” button would allow you to create a new circle or square or line, and then a new page would come up that would ask you to enter the coordinates of the object. Then imagine when you wanted to see your creation, you would press the “render” button and your canvas would be rendered on the screen in some “under glass” manner that would not allow any direct manipulation.

In a drawing program, the data model is a list of objects with types such as line, circle and square, where each such drawing has characteristics such as color and dimensions. So there is no reason the web page model could not be used to represent the data model.

Except that it would suck.

The point is that good interface objects and metaphors and perceivable affordances make software vastly more useable.

But what happened is as the web browser ascended to the preferred software platform is that software developers lost their palette. Not only did web browsers not have the ability to express rich interfaces in the way that applications did, but a whole generation of user interface designers for the web have no idea about most of these subjects, or if they do, it is as some long lost art, and not a part of their actual toolbox.

Interface and interaction designers today tend to think in terms of pages and flow where the user is a mouse that must be guided through a maze. This is fine for certain categories of applications, for example content management. Web browsers were intended for display of text anyway so the web browser never proved to be an impediment for that class of application. No new affordances are needed, people just need to be guided to their content.

But as I see it, many application categories could benefit from a bit more creativity. A good interface designer is someone that can think without the constraints of a limited palette. This is, more often than not, a programmer (these days this includes CSS3), because a programmer is much more likely to understand what is possible that may never have been done, and how to make it happen.

This whole subject came up because, in the last year I have had a variety of people lecture me about user interface as if I somehow “didn’t get it.” As we have been iterating Kloudco I have been working inside out, and art has really not, for most of that time, been a focus. I always listen politely, but most of these folks were barely even born when the first Mac’s came out and we were trying to explore what the real potential of man/machine interface and design really was. So such lectures have never sat well with me, but I haven’t been able to put my finger on what the deeper problem was. I finally realized that that the majority of newly minted design professionals don’t realize that they are being asked to create Rembrand style art with house painting rollers. (Do they even require reading Don Norman?- serious question).

The primary design palette is a series of pretty screens (or pages) that walk you through choices. But this just doesn’t work (or isn’t best) for apps that aspire to the level of problem solving of the early days of the graphical interface.

To be clear, there are lots of websites for which a limited set of objects is totally fine. You really don’t need anything beyond links and text to create a e-commerce site. But when we think about applications that allow us to more deeply understand our data models and interact with those data models in an intuitive way, we need the flexibility of a canvas with which we can cook up fresh new interface widgets and affordances that speak to the user without yelling at her. Applications like drawing, or calendars, or text editing, or collaboration or a myriad of potential applications that don’t fit the web page model demand this type of fresh thinking.

Another area where design options can and often should be more constrained is with smart phones. Most smart phones apps provide sequences of menus to navigate the data and the command sets (our mouse in the maze). This is necessary because not only are they on-the-go devices, but smartphones have limited screen real estate and input resolution. So creating a drag-and-drop calendar or drawing program might not be a very good idea on a phone. But if you have the input resolution and screen real estate of a laptop or a tablet, I would much rather drag an appointment to change its date than to click on the appointment, then click on the date and flick a roller.

What is exciting to see now is that HTML5 is going mainstream and is an acceptable platform for making web applications, so we are back to having rich tools with which to build. Still, the Mac Toolbox from the 80’s is vastly more powerful (though admittedly not easier) than today’s web browser. But Apple’s iOS and Google’s Android have an almost totally unlimited design palette. And while the potential for interfaces on phones is more limited because of the i/o issues, on tablets I see a vast potential to create intuitive and yet powerful experiences. One early example of this is Apple’s iPad GarageBand.

So the point of all this is that I would really like to see application designers today looking back at the history of the art of interface design. The golden era was only from 1984 to 1994. There are things that were pioneered that are as relevant today as they were then. With the right design, it is not necessary to sacrifice all power in an attempt to achieve simplicity. New affordances can make hard things easy. With the new tools available my hope is that we can win back some of the ground lost in the last 15 years of the web revolution and its unnecessarily dumbed down interfaces.


  1. In recent years graphic design and application design have become conflated.

    I know some amazing graphic designers who are terrible interface designers. Their apps look beautiful. Functionally, the bones are not good though. I also know a lot of great application designers who are really weak graphic designers.

    The two disciplines are very different. It is like the difference between an architect and a finish carpenter.

    Norman is great (also read his "The Things That Make us Smart"). Also Bruce Tognazinni had a great book out in about 1992 (it's name escapes me right now).

  2. This is a very important post, I think. The relative spareness of Web UI is a topic that deserves to get hashed out more than it has been.

    But if you'll allow me to play devil's advocate for a moment -- isn't it possible that the spareness of the Web's UI part of the reason why it ended up surpassing native applications in the first place? New affordances create new interaction possibilities, but they also impose a cognitive burden on the user, who has to figure out what they mean and how they work. The best ones, as you rightly note, are so well designed that they reduce this burden to the absolute possible minimum. But even then, it's still there; the user who sees handles on a selected image for the first time has to look at them and figure out what they mean. That's a burden that falls especially hard on non-technical users, who haven't learned how to quickly interpret an affordance's visual cues.

    The Web removed the possibility of creating new affordances, and cut down the number of built-in ones to the bare minimum: links, forms, and buttons. To the designer this is frustrating, because it means forcing all sorts of applications into models they don't necessarily fit into. But to the user it's liberating, because it means they don't have to deal with the cognitive burden of learning new affordances for new applications. Even better, of the three built-in types I listed above, only one, links, was something truly new to most users -- forms and buttons were already familiar to anyone who'd used a GUI application. So that's really only one new thing you have to learn to become fluent in the Web's design language.

    I personally don't think this negates your point -- as Web applications have gotten more complex the constraints of the Web's limited UI palette have definitely become more, well, constraining -- I'm just not sure the case for new affordances is necessarily as slam-dunk as you make it sound.

  3. Jason,

    Your point is well taken and I don't think I would ever argue that new affordances are always a good thing. In fact they were often *horrible* back in the day.

    But I do think that the difference between decent and awesome is often being able to do exactly what is needed instead of just what your toolset limits you to.


Note: Only a member of this blog may post a comment.