Beautiful Interfaces

(Notes from Ryan Stewart’s keynote talk at Philly Flash Camp.)

Contextual Applications:

Adobe’s Product Line:

And my example files:
demo.fla
demo.html

[Edit: I forgot to mention that my html file is using the swfobject.js library to embed the Flash object. It may be acquired here.]

I. An interface is a window between two complex systems.

Most of the time, one of those systems is a person.

The interface marks a boundary. It is the place where the human meets the machine.

II. Most software is incredibly complex. Often, it is so complex that not even one developer who built the system can keep the whole of it in her head at the same time.

Information passes from place to place, is modified, recombines, evolves and mutates in a thousand different ways. An interesting program is a highly choreographed dance of a thousand different pieces of data.

To make it even harder, this happens on many levels at once, from the base electrical impulse guided by physical law, all the way up to conceptual objects that contain, modify, and recreate one another.

The fact is, there’s a lot going on.

Meanwhile, on the other side of that boundary, a person is… a person.

Talk about complex.

III. An interface is a window. It is also an adapter.

The user wants to get something done. He has in his mind a model of what he is trying to do.

This model comes from his life experiences, psychology, learned behaviors, things he’s observed in other people, and probably 20 million other subtle factors.

The system also has a model. This model is built up over time, a slow accretion of 20 million small choices made in every line of code, in every aspect of the system design, during every step of the development process.

The odds that this model matches the user’s model are very, very small.

It’s the job of the interface to translate between the user’s model and the system’s model.

It’s the job of the interface to manage and reduce complexity.

(To compliment an interface, call it deceptively simple.)

It’s the job of the interface to bridge, not just 2 worlds, but 2 million — the world within the system, and the personal worlds of 1,999,999 different users.

That’s why making interfaces is hard. That’s also why it is worthwhile and necessary.

Because you could make life frustrating and difficult, but instead you get to make it pleasant and simple. Because you get to bring a small bit of order to a whole lot of chaos. And because you get to make things, in some small way, better or easier or more fun than they were before.

This past Monday I got to attend the Dev Days conference in Washington, DC. While it wasn’t the most useful conference I’ve ever attended — that honor would have to go to The Ajax Experience in 2008 — I still learned a couple of new things. Following are some items that I found interesting enough to share.

“Asking users to confirm something that they are not qualified to confirm is useless.” – Joel Spolsky

This quote was referring to security-related alerts and confirmation messages. Joel argued that 99.9% of users have no real understanding of the consequences either way, so asking them to confirm or approve something is meaningless. He asserts that many times, this pattern is a result of the developer or company trying to avoid responsibility.

The implication I take away from this is that the system should pick the “right” thing and just do it, while giving advanced users an option to override and do something else. I thought that this was a very thought-provoking point.

OPower looks like a really awesome company, and it is very cool what they are doing with psychology and design to encourage folks to conserve energy.

Bruce Eckel, who apparently has been programming forever and written books on every language in existence, gave a really interesting history of programming languages (with digressions into Burning Man, the TED Talks, and how 80% of people hate their jobs).

I was already interested in Python, but thanks to his talk I am now convinced that I actually want to learn it. Perhaps this will be a project for next year. (And after that, a purely functional language, like Haskell, because it is completely different from everything I know.)

Joel is a master of shameless self-promotion. I’m not trying to be snarky when I say that I think it’s what he does best. Throughout the conference he was continually promoting himself, his company, and his product.

Being really good at self-promotion can go a long way toward success, I think. I could learn from this, because I’m not necessarily so good at it myself.

Was Dev Days worth it?

I would go back if they had one in Philly. But overall, I don’t think it was worth the cost of the hotel and the drive time to DC. I would say about 25% of the sessions were useful or interesting to me.

I rate it worth attending only if it’s convenient and nearby.

I’ve missed several posts, but I have a good excuse. I’ve been on vacation in Bermuda, and here’s a picture to prove it:

Bermuda is an island full of rich people, with a strange mix of British/Caribbean culture. But I really enjoyed visiting there, got to swim and snorkel, and I didn’t even get sunburnt that badly.

There seem to be two fundamentally different types of organizations, that have two different ways of dealing with problems.

Process-focused organizations tend to look to formal processes and structures. When a problem occurs or something isn’t working as well as it could, they tend to respond by changing the process, adding more structural checks and balances, adding layers of oversight, or reorganizing groups. When things are going well, the process is seen as a success.

The upside of this is that what works can be recognized, taught, and made repeatable. In the best case, organizations can learn from their failures and create conditions that make it easy for people to succeed.

The downside is that organizations like this can come to view people as interchangeable cogs, ignore personal talent and potential, and in the worst case develop into gigantic, inflexible bureaucracies. They tend to underestimate individual differences, and put more weight on external factors (guidelines, documentation, formal processes) than on internal ones.

Person-focused organizations tend to look to individuals. When a problem occurs, they tend to respond by assigning blame, and the responsibility to fix the problem, to particular people. When things are going well, high-performing or highly visible individuals get the credit for it.

The upside of this is that talented people can be highly rewarded and make a big difference. In the best case, the organization is flexible and agile, members are much more productive without layers of red tape and approvals, and people are able to develop to the full extent of their abilities.

The downside is that individuals can be unfairly blamed or scapegoated when problems do occur; individuals that are more outgoing or who “talk big” can steal credit from quieter individuals; and in the worst case it can lead to a culture that rewards last-dash heroic effort over consistent work and good planning. These organizations may underestimate the impact that environment has on a person, and put more weight on internal factors (talent, work ethic, willingness to schmooze) than on external ones.

In my mind, the ideal case is somewhere in the middle, leaning more toward the person-focused side, but with a lightweight, flexible process that is revisited at least once a year. (I also think that the bigger your organization is, the more it tends to go toward one extreme or the other; but I don’t have any real evidence to back that up, just anecdotal observations.)

Where does your organization fall along this spectrum? Where do your personal preferences fall? Is there a mismatch between the two, and does that mismatch cause you any problems?

Over lunch today, I was watching this excellent overview of HTML5 by Brad Neuberg. One of the topics he goes over, along with Canvas, SVG, and native video, is the new app cache + client-side SQL storage, which together make it easy to create full-featured web apps that work just as well without an Internet connection. (It’s like Google Gears, but native.)

My thought was, could this do for web apps what the cell phone has done for telephony in developing countries?

Let me explain what I mean. In developing countries, such as most of Africa and parts of Asia and South America, cell phones have quickly overtaken land-lines as a means of voice communication. According to this source, Africa has more than twice as many cell phones as land lines, for example. The reason, of course, is that less infrastructure is required, so the barrier to entry is much, much lower. You still need a cell tower, but you don’t need to string phone lines everywhere. (Jan Chipchase, who has the really cool job of studying this sort of thing for Nokia, has a lot of interesting things to say on the topic of cell phones in developing countries.)

The same places in developing countries are likely to have Internet connections that are sporadic at best, lower-bandwidth, and probably with a lot more people sharing one connection. (According to this source, 13% of people in developing countries overall had Internet access in 2007.) Could these new features from HTML5 promote the development of relevant web apps that make life easier for someone who can connect to the Internet only once a day? Once a week? Even less often than that?

I have trouble imagining what such an app might be, because I don’t live in that context. Broadly, one category might be applications that pull down a large amount of information and store it for the person to use later, when they don’t have Internet access. Another might be allowing the person to create and store a lot of blog posts or other ‘pushes’ of information, and then upload them all later when given access.

While greater access to information and communications technologies is not a panacea by any means, it sure can do some interesting things.

Could offline web apps be the next tech phenomenon in developing countries? Or are even the smallest netbooks still too big, too expensive, too power-hungry, or too fragile to reach the level of usefulness that cell phones have achieved?

Every fall, I get really introverted for a couple of weeks. There’s something about the time of year — when it’s suddenly dark a lot earlier, and you have to put on a jacket to go outside, and the trees are starting to go bare — that makes me feel inclined to stay home and avoid being around people in large groups.

This usually passes by mid-November, and I go back to being a more balanced, sociable introvert in time for the holidays. But this week I find myself taking it slow, feeling sleepy a lot, and not getting as much done overall. (Unfortunately that’s a problem, because next week I’ve got a conference presentation to prepare, a website to release, and a vacation to plan.)

It’s got me thinking, though, about how our society in general is designed to completely ignore the seasons. Most people work in buildings that are climate-controlled and artificially lit; it’s possible for many people to get from home to the garage to the car to work without once having to set foot on the actual ground.

There are good reasons for this, of course; being cold and wet sucks, and office cultures demand a style of dress that doesn’t really work for spending time outside. But I wonder if we aren’t losing something important at the same time.

The seasons determine every single thing that happens in the ‘natural world’. They used to determine pretty much every single thing about human life as well, but in the past 100 years we’ve gotten to the point where outwardly they don’t make much difference at all in people’s day-to-day routines.

On the one hand this totally rocks for us, because being warm and well-fed beats being cold and hungry any day. On the other hand, just because we’ve conquered the seasons outwardly, doesn’t mean that we’ve conquered them inwardly as well. Could the year-round, unchanging demands of modern life actually be detrimental to us, when they conflict with some deeper, inherited rhythms and needs that do cause us to change with the seasons? Could people actually be worse off because we are expected to have the same range of moods, same levels of energy and creativity, year round? Or because we expect ourselves to be so?

I wonder if we could somehow arrive at a happy medium, a way to design our buildings and cities and schedules and lives such that they gracefully acknowledge the changing seasons, while continuing to modulate the worst extremes?

For a long time I agonized over whether I was “really” a designer or “really” a developer. First I wanted to be a developer, then I wanted to be a designer, then I was a designer who wanted to be a developer, and then a developer with an interest in design.

At this point, I’ve come to the conclusion that it is completely possible to do both — just not at the same time.

Differences

Design mind and developer mind are like two different lenses or frames. They hold different concerns, have different sets of tools, and can be very different ways of seeing the world.

Design tends to be holistic, looking at all facets and angles of a thing and trying to make them harmonize. Development tends to be analytical, breaking down a problem into smaller and smaller steps that can be individually tackled and solved.

Many types of design are quite spatial, concerned with relationships between objects within a field of view. Development is often more temporal; it is concerned with changing relationships between objects over time, and with passing information through a series of transformational steps.

Design is always about ‘what’: what is the right thing to build, what does the client want, what is the pleasing solution to the problem at hand. Development is more about ‘how’: how to create a capability, and make it flexible and fast and robust and concise.

Both are important, and both are quite difficult, and both can be so rewarding when you get something right.

(Of course, these are all generalizations, with plenty of counterexamples to be found.)

Doing Both

I think the key to successfully doing both is building up your ability to switch between the two. To look at a problem as a designer, as a developer, and as a designer again. To know how to switch perspectives, and when.

Doing this can be jarring. Things that design mind really really wants might prove frustrating or impossible to actually build. Developer mind might want to do things in a logical way that compromises design mind’s vision. In fact, all of the conflicts that occur between designers and developers come up, inside of your own head! But the trick is just to keep doing it, and to focus on creating something beautiful.

When I’m working on a project where I’m doing both roles, I keep separate to-do lists for development and design. I’ll tend to work through one list at a time, perhaps design in the morning and develop after lunch. I might need to match my surroundings to my task, get away from my computer and my desk, and go someplace where design mind can make itself heard. (There are some great suggestions about how to do this in the book Pragmatic Thinking and Learning.)

It’s definitely not for everyone. You do trade away some depth for breadth, and maintaining the different skillsets can take up a lot of time. Employers may not ‘get’ you; it can be hard to find a role that exercises both minds, in a heavily specialized world. And your job title is guaranteed to always be wrong.

On the other hand, you get to have a foot in two fascinating worlds; you get to translate between two important domains; and you get to have conversations with two completely different sets of awesome folks. And sometimes, if it all works out, you might find that there’s a huge strength in being in-between, and that it lets you really impact your world.

“Designevelopers” of the world, unite!

(Here’s an example from the world of automobile design.)

(In case anyone outside the US reads this: the DMV is the Department of Motor Vehicles, the place where you have to go to get your drivers license renewed or replaced, get an ID card, and other such licensing requirements for vehicles.)

The DMV sucks. Every one that I know hates it, hates going there, hates standing in line for hours and sitting on the floor and being grumped at by unlikeable government serfs. I have a bad habit of losing my wallet (the current record is twice in one year), and every time I have to go to the DMV to get my license replaced, I get a feeling of dread. It is a thoroughly unpleasant experience, and one that people hold up regularly as an example of government incompetence.

So what could be done to change that? Just for fun, I’d like to invite you to join me in brainstorming how you would change the DMV to make it more effective and less miserable. (Leave a comment with your ideas!)

I think I would start by listing the common reasons that people go to the DMV, and then I would run some time studies on each category of task, to gain a thorough understanding of the time required to complete each type of task. For example, taking your initial drivers test is going to take a lot more time than getting your address changed.

I would use the findings of these studies to create an online reservation system with a pleasant, simple interface, where people could indicate what they needed to do and sign up for a specific time slot to come in. The system would allocate appointments to workers, based on the length of time needed for each task (with some extra built in). And — this is the key part — I would build into the system a feedback mechanism where the DMV employees could indicate when they finished each appointment.

This way, if things started to back up and run late the system could a) reallocate appointments to other workers who might have extra time, and b) send people text/email notifications, like airlines do when a flight is delayed. There could even be an iPhone app where you could check your place in the queue, find out whether your appointment was likely to be delayed, and reschedule if necessary.

My motivation with this redesign is to tackle what I see as the biggest point of pain, which is the interminable waiting (often measured in hours) and the powerlessness of not knowing what time you’re going to be seen. My system would provide better feedback to the user, allowing them to make better use of their time; and it would benefit the employees too, because they wouldn’t be dealing with huge backups and angry, disgruntled customers all of the time. (And of course the scheduling algorithm would take into account lunch hours, breaks, and vacation days.)

In order to accommodate the constituency that doesn’t have internet access, there could be scheduling kiosks in the DMV lobby, where people could come in and make their appointment. That way at least they could leave and do other things while waiting.

Of course, the real-life DMV is a government monopoly and therefore has no incentive to change. But it’s fun to think about how much better things could be, if they decided to leap into the 21st century.

[Update: Hey, it looks like California and Florida actually have online scheduling systems. Good for them! Although they still don't provide the granular level of feedback that I think would be ideal.]

Meta: I’m going to be posting these redesign exercises occasionally in this blog. Sometimes it’s fun to brainstorm without real-life constraints, and to look at a broken system and think about how it could be improved.

I would like to invite you to participate along with me, in the comments. What do you hate most about the DMV? How would you change the experience, if you could?