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.
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?
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! 
[Edit: I took the word "manifesto" out of the title because I decided that it sounded dumb.]
When I think about my career and my interests, this phrase keeps coming back to my mind, and I’ve also made it the title of this blog.
But what do I mean by “beautiful interfaces” in the first place? I think it can be summed up in 3 points.
I’m not saying anything new with all of this, I’m well aware. And these are all aspirational points to me; I definitely don’t have any of this mastered. I’m just an interested beginner who’s really into this stuff.
Life is too short to deal with ugly, tedious, argumentative interfaces. Why shouldn’t the everyday things that we use be beautiful?
You are currently browsing the archives for the development category.