Our most important client wanted to draw attention to a major new feature in the next version of their successful commercial software product with a "flashing red button". We tried to explain that this would be irritating, and our task should be to enable the user to quickly LOCATE and understand HOW TO USE features, not to impose our own idea of what their individual workflow should be. I asked the client's marketing reps to imagine a word processor featuring a blinking "SPELLCHECK... SPELLCHECK... SPELLCHECK..." button. They insisted... We resisted... Several weeks later, one of the marketing reps called to say that they now completely agreed that a flashing red button had been terrible idea... but could we add a "cycling button", which would endlessly transition through a set of colorful images? We eventually delivered the product, free of any "throbbing" UI elements, to rave reviews -- and a Software Publishers Association "Codie" award.
Effective UI development requires attention to many different areas...
Buy-in: Attention to UI is still an afterthought at many organizations ("our customers pay for FEATURES!"), and it sometimes takes a competing (possibly technically inferior) product, that wins over reviewers with its intuitive design and polished graphics, to change this. Until you can overcome the attitude that developers can just use MS Paint to generate artwork for the shipping product, you'll be very limited in what you can accomplish in terms of design.
Interactive Design: Guidance on principles and practices considered to contribute to "good UI" has long been available in published references from a number of notable industry authors (see the list below). In addition to making the effort to actually STUDY the subject, it helps to be able to mentally "block out" your deep understanding of the underlying technical issues, and see interaction requirements from a user's non-technical perspective. Common UI sins include exposing far too many options in the top-level UI, failing to group associated features or define interactions for similar tasks in a consistent way, failing to create a visual hierarchy to promote feature "discovery", creating deeply nesting submenus under submenus or dialog buttons that pop up more dialogs, and many others.
Aesthetics: This is what most managers and marketing people tend to think of when they hear the term "UI design", with managers justifiably skeptical that the company should invest time and money just to "make things pretty", while marketing department representatives are envisioning how the application will look, projected on the JumboTron, at the next trade show. A general consensus on the definition of "good enough" is important when considering changes that are purely aesthetic -- but much less so when it comes to issues of usability. Aesthetics are almost completely subjective: "It's too round, the borders need to be thicker/darker, it 'feels' too crowded, the animation isn't smooth enough, it's too blue...". A subtopic which is less subjective involves "color theory", and developers can dramatically improve their designs by relying on resources like Adobe's "Kuler" to help them select a limited set of colors that are guaranteed to look good together.
Engineering Effort: Developers who focus exclusively on server-side/infrastructure/business logic issues, HUGELY underestimate the engineering effort required to produce an intuitive and compelling UI. Speakers at dev. training events will often wave their hands in front of a thinly populated data grid near the end of a presentation on the latest data access/remote communications mini-framework, and make some offhand remark to the effect that "someone" can hang a pretty UI on all of this later... In reality, I don't think I've ever seen a project where the time and effort required to implement a non-trivial user interface didn't turn out to be many times greater than what was required to pound out the underlying business logic and support layers, where implementation of the UI didn't require the attention of the teams's best developers, or where there weren't significant benefits to refactoring lower layers to present information in a form more convenient to the UI.
Design Extremes: More than one member of the Windows developer community has warned about WPF's potential to inflict interfaces consisting of dancing 3D teapots pouring colored streams of text onto virtual curling pages... At the other extreme, some developers will continue to simply glom together 3rd party controls, and rob their projects of the benefits of the DESIGN capabilities built into the framework.
Designer-Developer Interop: Some people have been mislead to believe that designers can essentially make indiscriminate changes in Blend, while developers make indiscriminate changes to the shared project source in Visual Studio, and that as long as everything works in one environment, it will work in the other... and that designers and developers can work in harmony while remaining largely ignorant of each other's area of concern. Many teams, including some inside Microsoft, are finding that this is simply not true.
UI Testing: The process of writing unit tests for business logic generally results in better code, converting methods that were formerly "private" into testable "public" methods in new classes with more narrowly-defined responsibilities, for example. The structure of "good" UI code, on the other hand, is dictated by the UI development framework being used (Windows Forms, WPF etc.), and trying to unit test the presentation layer often requires conforming to a dramatically different coding style, which is not inherently better, but required by the test framework (implementing all control handlers as empty stubs that call into new "presenter" classes, for example -- although there are arguably other benefits to this particular technique that extend beyond testing). Unit tests are also completely unable to test effects that are purely visual, which make up a HUGE proportion of UI bugs (scrolling is not smooth, controls don't line up, layout doesn't conform to UI guidelines, X is misspelled, quickly dragging the window causes the video image to dissappear while audio continues to play...), while much of what CAN be detected would rarely have escaped notice, even without unit tests (verify that clicking buttonX launches featureX...). The cost-benefit trade off for trying to unit test the presentation layer becomes even more questionable with WPF, since the majority of UI behavior in a well-designed WPF application will be defined in Xaml and, even if you could test the markup, you would essentially be testing Microsoft's Xaml parser and data binding implementations.
A less common type of UI testing consists of formal "usability" testing. On the project mentioned earlier, our development team got to spend a week in an actual usability lab and (once we got over the fun of zooming the hidden cameras in and out on the test subject's bald spot), we found it to be a very humbling experience to watch user after user struggle with features we "knew" were completely intuitive, while we jumped around behind the one-way mirror begging the user to "Just click the Toolbar button!" Formal usability testing is very valuable if you can justify the expense, but interpreting test results can be tricky -- thinking that maybe the user would have noticed that Toolbar option IF ONLY WE'D USED A FLASHING RED BUTTON!
Recommended UI Design Resources:
The fact that the Blend tool was used to design the non-trivial UI of Blend itself, is pretty convincing evidence that the first release version is probably already suitable for use on many real-world projects, but there are a few practical concerns that always seem to be glossed over in Blend-related discussions.
How exactly is this new designer-developer coordination supposed to work? An interesting Channel9 interview with members of Microsoft's User Experience Team in the UK details some valuable lessons learned through trying to apply this developer-designer collaboration on actual projects (jump to minute 16:00 to skip intro material). The team discovered that designers needed some level of understanding of Windows development and WPF, in order to avoid problems such as designers creating image elements where they should have restyled control templates, or designers breaking links to underlying business logic by "replacing" controls with restyled versions. The developers also found the auto-generated Xaml provided by the designers to be difficult to read and edit in those inevitable situations where it became necessary or beneficial to do so. The UK team finally settled on the very interesting approach of having the designers generate a "wire frame" DRAWING of the overall UI, which the developers use as a guide in beginning the actual project, while the designers go on to create separate resource library projects, featuring the production quality UI elements that the developers plug into their own carefully-crafted production code. Other development teams have reported success using a single set of shared project files, but its helpful to be aware of a full range of real-world proven alternatives before rushing to apply Blend on your company's next mission critical project.
Realistically, what are the chances that your company will hire professional desigers, or approve funds to hire one of the few consulting firms with experience in this area, like Vertigo? I recently worked at a chemical equipment manufacturer, which contracted with a professional industrial design firm for their complete line of hardware enclosures, while relying on the artistic talents of internal developers using MS Paint for their accompanying software, and a marketing manager at a different company once asked why I couldn't just use clip art throughout the UI for the "commercial quality" digital video capture and editing application they'd hired me to write (using DirectShow, to accompany one of the first generation 1394 Host Bus Adapters). For many organizations, this attitude is likely to continue -- at least until that first trade show where a competitor demonstrates a professionally-designed product that takes full advantage of new WPF graphics capabilities. Even if a company is willing to allocate the funds, there is still the issue of trying to FIND designers who have the combination of skills described in the UK group video. This is not a situation where you can simply retask your company's web developer or marcom person, which still leaves it up to the DEVELOPERS to acquire expertise with Blend, at least in the near term.
On the architecture front, Blend promises to enable designers to "reskin" an application at will, but this separation of UI from business logic occurs at a much higher level than what is currently supported through code-level frameworks such as CAB and SCSF. Whereas these code-level frameworks often attempt to create extra abstraction layers (presenters, controllers, etc.) to decouple UI "views" from the underlying business logic, they still assume that developers will be required to "code" the UI. Microsoft has already announced that CAB/SCSF will be replaced by Acropolis, which will offer some degree of support for Blend (currently, limited to the ability to open "PartViews"), but is not expected to ship "for quite some time".
Finally, Blend is specific to building WPF applications, and WPF is a brand new technology, with a steep learning curve, which will not even enjoy a significant degree of Visual Studio designer support until the release of Visual Studio 2008 at the end of this year. Some corporate managers may feel it is safer to hold off on any commitment to Blend, or designers, or possibly even WPF, until things sort themselves out. I disagree, in cases where a change in technology clearly represents a major advance that will need to be adopted eventually anyway, and I'll have more about THAT attitude in a future post. A beta of Blend 2.0 is already available and, as the tool continues to mature, and the practical issues I've mentioned are resolved, we can expect Blend-based development to become the standard for a significant percentage of Windows dev. projects in the not-too-distant future. I recently decided to check out an online course in Blend at the local junior college, and the text we are using, "Microsoft Expression Blend Bible", seems to be a pretty good introduction to its features
A few hours of playing around with one of the earliest CTP builds of "Sparkle" (now, "Blend") got me very excited at its potential to address some familiar UI design PROCESS issues...
1) Our client's team of marketing product managers had flown in from corporate headquarters for the annual project kickoff meeting. After reminding us that we had to deliver in ten months in order to meet Christmas store deadlines, they proudly announced that it had been decided that EVERYTHING in this year's version of the product would be designed around the concept of a "concierge". If the user wanted some information, they would consult the "concierge". We said, "Fine," would this take the form of some kind of animated assistant, or were they envisioning a special screen that the user would navigate to in the application? Would the feature involve recorded or synthesized speech? Would it have an online component?" We were told that focus groups were already hard at work, considering such questions as "If you were to invite the concierge to dinner, what would he look like?". Four months later, a group of us flew East to participate in formal usability lab studies on the product shell, and I took aside one of the PMs, to try to pin down this still-undefined concept of "concierge". He told me the design consultants were still busy, finalizing the product color scheme, and he was shocked when I told him they could safely delay a decision on the final RGB color values almost to the end of the project (this was MFC, so I simply #defined place-holder color codes in a header file), whereas implementing the "concierge" might require significant effort. Six months later, we shipped a product (to good reviews) whose only reference to "Concierge" consisted of a single modal dialog.
2) In preparation for a major revamp of the company's flagship product UI, myself and several other developers in US and German engineering departments spent several months separately implementing a number of interactive mockups using Windows Forms, while I used PhotoShop to generate over 200 additional static "screen shots" of UI alternatives that would have been too time consuming to code...
3) I've almost always had a major role in defining the UI of the products I've worked on, writing many custom UI elements (in Windows Forms and, previously, with MFC), and working with end users or user proxies (ie: Marketing) to design the overall UI experience. This is one of my favorite parts of the development process, and I've read most of the popular design references (Cooper, Krug, Nielsen, Spolsky, Tufte...), so I've always been surprised at the number of developers with good technical skills who seem to have no affinity for, or interest in, user interface design. In some cases, the developers simply seem unable to envision how complex and unintuitive their proposed application workflow will appear to the target (non-technical) end user. In other cases, it's pretty clear that they consider any amount of attention to aesthetics or design to be completely irrelevant to the task of engineering an application, even to the extent of failing to size and line up controls properly, or to follow basic Windows UI design guidelines.
For those who have been busy with existing projects, and may still be unaware, Microsoft's Expression Blend is a UI layout tool (and much more) for WPF applications, that enables designers to generate the actual production UI for an application themselves, rather than having to settle for the developers' distortion of some carefully-rendered initial design. Because they share the same project file format, developers can load a Blend project in Visual Studio to add business logic to the designer's work, and designers can load a Visual Studio project in Blend to professionally "style" basic control layouts stubbed out by the developers. Blend's capabilities extend far beyond mere layout however. Without leaving the design environment, designers can bind controls to XML data, or to class instances defined in code-behind files, or bind property values between controls. Designers can hook up events, create and trigger animations (defined in WPF as any change in the UI over time, including the appearance and location of controls -- as opposed to the more traditional definition, which was specific to image animation), completely restyle the appearance of system controls, or implement entirely new controls.
Sound a little too good to be true? A little skeptical that your same company management which ships products featuring artwork created by developers using MS Paint will suddenly approve funds to hire "interaction design professionals" -- and just where do you find these strange, half-programmer, half-artist, creatures anyway? More about all that in my next post.
|