In a comment to my final post on gel buttons, the orginality and creativity of my design was, shall we say, called into question. Obviously, I have miscommunicated my intentions here, as evidenced by the tone and directness of the feedback.
I am not a designer. I am not trained to be one, nor do I have any focussed inate talent in that domain. Therefore, my purpose was not to propose the notion of a gel button as being an exciting new design innovation. This is not a new design recommendation for implementing buttons from either me or my employer.
What is the point, then, of demonstrating how to create buttons that look like this, if I am not recommending that you create buttons that look like this?
I am not attempting to recommend a solution to a UI design problem, but instead to convey some approaches to implementing a solution to a UI design problem that somebody has provided. I believe that being able to represent, with great fidelity, the designs created by those who actually do have design talent will become an important part of the software engineering discipline. Often, implementation of an application is determined by what can be created quickly in the development tool's form designer, with the majority of the engineering effort devoted to implementing the functionality behind this UI. In many cases, this is completely appropriate. However, as application complexity continues to increase, it becomes more and more important to faithfully represent the intentions of the designers who mock up the application, as these designs will explicity target making the application either easier or more enjoyable to use. Close enough is becoming more and more insufficient as complexity, as well as the quality and quantity of competition, increases.
This is not limited to "bling" applications, such as Windows Media Player, or any number of other consumer-focussed applications. My tax software, for example, renders its own buttons. (It uses the increasingly popular "two-tone" buttons.) It increases the feel of quality. Even for non-commercial line-of-business appications, there are many problems where the approximations provided by the built-in controls are not quite accurate enough, and could be enhanced with both design and engineering talent. Usability should not be an afterthought.
Applications hopefully provide a solution to a particular problem domain. The challenge to the designer is to understand the core concepts that define the solution space, and present UI that provide a solution for this problem domain in the most intuitive way possible. The challenge to the engineer is to implement the designed solution with the maximum fidelity possible.
Brad Weed, the Product Design Manager of the Office Design Group, describes the relationship between the design displine and the engineering discipline in the Office team (he was a guest writer on Jensen Harris' fabulous An Office User Interface Blog):
We have an amazingly talented set of designers that spend inordinate amounts of time camped out with passionate developers devising clever ways to pull off these beautiful visual designs. And every decision intended to make the product more desirable impacts the usability and utility of the product in some crazy unpredictable way. This only complicates the process, yielding even bigger collaborations.
So, essentially, my point is that making great designs come to life is important to maximize the usability and experience of your applications. This is a valuable engineering discipline. My example of gel buttons was somewhat arbitrary (coming directly from a link I read in another blog) and implemented just to start giving a taste of how to approach these problems from an engineering perspective.
Of course, that's not the only reason I delve into the implementation of user interface and experience.
I love pixels.
In the end, it's all about raw pixels. If there is one component of my computer that I am going to over-spend on, it is the monitor. Why? That's what I have to look at all day. It feels better to me to use something that has a sense of being well designed, and I want to deliver that sense of satisfaction to people who use the software that I create or help my customers create. (Incidentally, while the initial Beta 1 release of Office 2007 was "neat", the design of the Beta 1 refresh makes it finally feel satisfying. I love good design.)
I am hoping to share my joy of pixels, and to hopefully incite some respect for investment in faithfully reproducing design. In the end, the engineering goal is to bring static images and interactive prototypes to life, honoring both the intent of the design and the limitations of the real world. Design is finally coming to prominence at Microsoft. Windows Vista and Office 2007 are two products that, to me, clearly demonstrate the value of excellent design, and they are just the beginning. Coming soon, we also have the Windows Presentation Foundation, comlete with tools for designers to implement this UI code. However, even with the power provided by the Expression Interactive Designer ("Sparkle"), engineering talent for implementing fantastic UI was still required. (Check out the dynamic SmoothMove control custom implemented for the Flickr Browser.) These new products will emphasize the workflow between designer and developer, so we will no longer be limited to passing Photoshop images and Flash animations back and forth - we can finally collaborate.
Working in concert with great designers, we can create some fantastic user experiences on top of powerful products. I'll leave the design work to those more talented than I am, and stay behind the scenes writing the code to push pixels around.