Tuesday, January 2, 2007

UI Refactoring

There has been a bit of discussion on the topic of simplicity lately. Joel has talked about simplicity in terms of features and the simplicity of not having too many choices to make when taking/making a simple action in a user interface (or at the very least taking/making what on the surface 'seems' like a simple action). This topic of Joel's touched off a response in the form of an explanation from the MS camp that he was lambasting. He also recently expounded on elegance and what makes something elegant. I believe that these two things are intertwined and have some serious impact on certain people when it comes down to what makes up a good user interface design.

Programming as we already know is hard but the user interface should be easy right? I mean seriously we all use them every single day and we know what doesn't work from what does right? One might take those questions to mean that I personally think that every single person who has ever touched a program in their life should be able to design an effective interface from the ground up. Most programmers know from experience that this is not the case. However - back to our original topics of simplicity and elegance.

Joel rightly points out the interfaces should be simple. This means easy - or almost intuitive to use. This does not mean that the interface should not contain as many useful features as it can support. What it means instead is that when you go to do something with your whizzbang new toy, gadget, program, computer thing... it should work in a straight forward and intuitive manner. NOW - it is that last bit "intuitive" that is the hard part about software UI design. This is even more true when you consider that UI design, like software programming, suffers from some of the very same problems. The Overall UI design picture can get bit rot and get old over time. So the original SIMPLE and ELEGANT design (i.e. it just works and it does just what it is supposed to do) can become cluttered, annoying, and just plain bad the longer it sits out there. This "bit rot" effect can be exacerbated by not giving the design and new features of the UI a good thought process when a group of programmers is attempting to add new features.

In the programming world we combat this problem by continuously refactoring the code. This is not the one liner spot refactoring that can be done from within your typical IDE. Nor is this the type of program refactoring that consists of variable renaming for the readers sake - THIS type of refactoring is a critical look at what a program was for, what it is for now, and what it will be for a few days/weeks/months from now. This allows the programmer to mold the program like clay to match the needs as they expand. What appears to be missing in most software shops is a similar process for the user interface. User interface deserves the same attention as "does the code do what it is supposed to" - why you might ask? the answer should be simple, the interface is what people see first - it is the first impression, the first experience with what and who you are if your job is creating a user interface to ANYTHING that has to drive underlying software processes. More importantly the simplicity and elegance of solution need to be inbred into both the software and its user interface and while a single design may have been just fine when you started it always deserves to be revisited. UI design like software should be ever changing or at the very least being continuously reviewed to make sure that it still meets the needs, is simple and elegant to perform the job at hand. IF the UI you have now is neither of those things - you may be missing, at the very least, half of the software development equation.

No comments: