21.8.08

Interface design

Nobody doubts that the interface of a shiny new iPhone or macbook were thoroughly thought through. Most of the tangible things we use have a thought process behind them that reflect that there were people thinking about how these things were to be used. Ranging from kitchen tools to a car dashboard, it's evident that this interface design is present.

Lately, as the web evolves, the same concepts are ported into new disciplines: interface design becomes a crucial component of any respectable web site or application. I can't say that most interfaces have been thought through, but the concept is there.

Unfortunately, when it comes to programming interfaces, one can sadly see that they have not been thought through at all.

I'm taking a break from my first attempt at a GWT application to give you an example:

1. To create an Eclipse project:
projectCreator -eclipse MyProject
2. Then, you need to create the application skeleton:
applicationCreator -eclipse MyProject com.mycompany.client.MyApplication

Looks super simple, but:
- Why do I need to repeat -eclipse MyProject? Can't the applicationCreator detect an existing eclipse project? Apparently not
- From the example, it seems like i should be able to create com.failcorp.something.MyTestApplication right? No. I get a warning:
Please use 'client' as the final package, as in 'com.example.foo.client.MyApp'.It isn't technically necessary, but this tool enforces the best practice.

Uh, if you're going to enforce it, can you not give an example where you can change anything but client on it? Yeah, you can change com, example, foo and MyApp but not client. That's a bit obtuse.

No disrespect. GWT is the product of very hard work and deserves lots of props. This example does not in any way represent the quality of GWT but it does portray a problem that the vast majority of software tools and web applications have: their interfaces are designed by people familiar with the solution --and sometimes not even familiar with the problem, as I point out below--. The result? People familiar with the problem and unfamiliar with the solution spend an unacceptable amount of time trying to learn how to use the tools. It so pervades our programming culture, that nobody makes a public stink about it. Once you learn it, it's not a problem; and if you haven't learned it yet then you should probably feel stupid until you do.

The issue is becoming more obvious in web applications: the features are driven by CEOs, managers, sales people, etc. People that "know" the landscape. How come programmers often end up not implementing what clients most often ask for? Who is the product for? What's worse is that these product designers often don't even use the product and are unfamiliar with the problems it attempts to solve. This is why the dogfood concept is so important: if you don't use it, you'll never know if it's useful or not.

I mentioned before the hardware design of Apple products: it might not be perfect, but it's superior to the average. Here's an example for the software world: jQuery. This tiny library does about the same as many others. Maybe it's faster, maybe it's smaller, maybe it's hotly debated. But what is really different is that it was designed to be easy to use, and it really is. The difference is so vast, that it's actually difficult to express how different it is to someone who is used to clunky APIs.

Ultimately, is a tool designed only to solve a problem or does it keep in mind its users? Writing an API or command-line tool should NOT be like slapping buttons on a box.

No comments: