Last published article
Need for simplicity
Lately I started thinking about design, broadly speaking. Like I said in a previous article, to me good design isn’t necessarily related to being good-looking: you need something more than a pretty face. It’s because of this reasoning that I realized that, for me, a good design is something that effectively combines ease of use, visual pleasantness, and many other factors (e.g. speed, if we talk about websites), and something that carefully evaluates pro’s and con’s.
I started looking at things in a different way, trying to analize what were the strenghts of objects, and where those objects could be improved. One could do that with anything, really: from websites to lamps, from cars to elevators, every object, device or tool that we use every day has passed through a phase when some people got together, thought about its possible uses, and then produced it.
What I like about design is that it’s a never-ending process. You learn from your previous experiences, you learn from other people’s experience, and you strive to create something better.
Design is hard as hell. Creativity can lead to great ideas, but also to miserable failures. I’ve found that failures are often associated with simple things, like you wouldn’t expect that object to fail at such an easy task.
Take my elevator, at work. We have this elevator, that isn’t particularly slow, or small; instead it’s well illuminated, it has a marble floor, and a big mirror. So it’s visually attractive, but it fails at two simple things. The first one it’s the control panel that is placed on every floor of our building: it doesn’t display what level the elevator is currently at, and neither gives you an indication whether it is going up or down. The control panel is only good to summon the lift.
We’re talking about lack of feedback, here. Every user makes an action, and wants a clear signal that the action has produced some kind of effects, otherwise he/she gets confused. A red light that indicates that the elevator will eventually come at your floor simply isn’t enough for me.
The second mistake about my elevator is about the sensors that prevent its sliding door to close, when someone is entering. That’s a needed feature, of course, but what I’m questioning is the implementation — geeky term, I know — of that feature.
Since we stick to the floor when moving, and since we tend to move more the upper part of our bodies than the lower part (legs are supposed to be steady in an elevator), why do we need sensors for all the door’s height and not only the bottom of it? It happens many times that the elevator is crowded, that people is carrying bags and accidentally move their wrists, activating the sensors. The door opens and people mumble.
Those are simple things, right? You could have had both feedback and effectiveness of use at a very low price. Too bad.
The Web side of the Moon
A couple of days ago I happened to think about how could I apply a similar reasoning to my web-related design and development work and so I started thinking about wrong solutions that I’ve found through my experience on the Web.
Deduction number one: the speed thing is confirmed. I work with several kinds of interfaces, and even when I know what’s going on with the app I’m using (gotta love text consoles), I get frustrated too when the system doesn’t give me visual indications about its activity. That’s one of the usability problems that AJAX brings with itself.
Speed and feedback, the two keywords to a successfull interface. But there’s more. JavaScript in general gives you the ability to interact with the DOM, and to associate many kinds of events to the elements that compose your page. Now, with events you can create almost everything, even duplicate the functionality of desktop applications controls. Here lies a subtle threat: not every control is suited for a Web context, and not every control is good in general.
If you use sliding on your touch device, that doesn’t mean that you should find the same kind of control on a Web page too. Sliding with a mouse is a complex motion, that involves a lot of muscles, unlike what happens with touch devices. Still, I’ve encountered this kind of control in wrong situations: who wants to execute a dragging motion to, say, download a file or confirm a choice?
According to my own personal taste, using dragging for those two specific tasks is deeply wrong. Since we’re lucky enough to have alternatives for the problem, as far as downloading/confirming goes, just provide a hypertext link to the download page or the file itself, or simply use a checkbox, respectively.
Banal, right? Well, it may be. But the fact is that links and checkboxes perfectly satisfy the conditions of simplicity, speed and received feedback we’ve talked about earlier. In the end, on the Web, while we must not desist in researching new and better ways to do things, there’s one dogma that shouldn’t be violated: keep it simple, keep it fast and give the user some clues on what’s going on.