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.
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.
Posted by Hank Williams at 10:43 AM