Interface evolution

There's a blog post from the LayerVault folks making the rounds among interaction designers. It's about what they call “progressive reduction”, in which they change their interface over time in response to use, simplifying the way the elements appear.

In a way, this is a moment in which Everything Old Is New Again. Many people don't remember Kai Krause now, but back in the mid-90s, he made a series of graphics tools with exotic interfaces. Check out these screenshots of the Kai's Power Tools Texture Explorer and Sphereoid Designer (ganked from Veerle Pieters):

Crazy, right?

Kai's software was even weirder than it looks in screenshots. Many of those beady little buttons started out with text labels which would then wear off over time, getting fainter and fainter until they disappeared entirely, because Kai figured that eventually you just knew the button by its position rather than by its label. Many of those buttons never had a label at all, they did things to the image that were hard to name; the interface instead provided an abstract, memorable-looking button from the beginning. And in some tools, Kai had bonus features that would only show up after you had used the system for a while. The reasoning was that you wouldn't want the complexity of those functions at first anyway, so it was more fun to have them show up as a surprise bonus reward.

LayerVault describes the principle this way:

As designers, the longer we live with a product, the greater our bias shifts towards the professional user. Alternatively, blindly applying basic usability heuristics results in a bias towards new users. The mistake isn’t biasing your UI towards one type of user, it’s failing to realize that your user’s bias is changing.

How does one guide a new user from on-boarding, to low proficiency, to high proficiency? With progressive reduction, the UI adapts to the user’s proficiency.

I would never do something as garish or abstract as Kai's interfaces in my own UX design work, but this idea of progressive reduction stuck in my mind from back then, and a few times I've proposed versions of the same idea ... though they've always been shot down.

I don't mourn those missed opportunities too much though, because it's a risky, shoot-the-moon design move. If you get it just right, I think there's an opportunity to get some big benefits, but executed sloppily it could easily create more problems than it solves. LayerVault are swinging for the fences; good for them.

I have a hunch that this must be connected with the rise and fall of cursor-hover behaviors. When I doing interaction design for desktop applications at Cooper in the mid- to late-90s, we often tried to convince clients to make better use of tooltips and other cursor-hover behaviors, usually to no avail. The original edition of Alan Cooper's About Face included a lot of discussion about this. Then along came web applications implemented in Flash, which often included a lot of hover behaviors (often frivolously) because early on it was one of the few bits of crafty interaction it could provide easily. As a result, web applications have actually led the way for desktop applications, a reversal of the general pattern that the desktop has provided richer interface idioms than the web.

But just as the world has reached the point at which colleagues understand why I'm proposing extensive use of mouseover behaviors, they've started resisting them for a different, better reason. We need to accommodate tablets which cost us the use of this powerful interface idiom. Indeed, the tablet is killing a lot of idioms we used to use because it also doesn't support right-click or compact clickable buttons.

My hunch is that the (re-)emergence of progressive reduction in the LayerVault example reflects a secondary effect of the tablet revolution. Suddenly we are losing some of the idioms which have served well for years, while at the same time we don't think as much about “user expectations” on the new platform, resulting in software development organizations with a greater willingness to experiment with user experience.

You can see another way in which new hardware affects thinking about interaction design in software here. The garish-looking textures of Kai's interfaces and the LayerVaulters' enthusiasm for the opposite support John Gruber's theory that all that stuff was actually crafty technique for compensating for the crummy displays of the old days, and the trend toward “flat” interfaces reflects the emergence of better display technologies.

The trend away from skeuomorphic special effects in UI design is the beginning of the retina-resolution design era. Our designs no longer need to accommodate for crude pixels. Glossy/glassy surfaces, heavy-handed transparency, glaring drop shadows, embossed text, textured material surfaces — these hallmarks of modern UI graphic design style are (almost) never used in good print graphic design. They’re unnecessary in print, and, the higher the quality of the output and more heavy-handed the effect, the sillier such techniques look. They’re the aesthetic equivalent of screen-optimized typefaces like Lucida Grande and Verdana. They work on sub-retina displays because sub-retina displays are so crude. On retina displays, as with high quality print output, these techniques are revealed for what they truly are: an assortment of parlor tricks that fool our eyes into thinking we see something that looks good on a display that is technically incapable of rendering graphic design that truly looks good.