On Windows Controls

Why is it that many Windows applications look unattractive and feel less enjoyable when compared to modern Web applications? And, most important, does it affect usability and customer acceptance?

This is an article I started to write early in 2003. With the advent of Avalon, the new rendering engine in Windows Longhorn, it seems Microsoft has come to the same conclusions. – February 2006

Windows UI Design

Traditional Windows UI design is focused on absolute positioning of Windows controls on the individual windows. Visual Basic and Delphi as the most important RAD tools make this very easy, but do not truly transcend the approach taken initially by Visual Studio and, thus, Microsoft’s products.

Microsoft’s way

What is this approach?

• The main application window is heavily custom drawn with a border of standard menus, toolbars, status bars, and the like.
• Data entry windows, that is, most dialog windows, are designed in Windows resources with a static layout. Dynamic deviations from this static layout are fairly hard to achieve.
• As a sort of middle ground, every now and then Microsoft introduces new control classes into their applications that are custom drawn and reusable. The toolbar and status bar are a classic examples.

Working this way is non-trivial when compared to how you work in Visual Basic, Microsoft’s tool for the technically not so savvy application programmer, and it takes considerable manpower.

Visual Basic is great for designing data entry windows using standard components, but underpowered otherwise.

Delphi is on a par with Visual Basic for creating statically designed windows and makes it dramatically easier to create new control classes for use during window design. The latter, however, is still much harder than just using the existing set of controls - in fact, a routine question during job interviews for Delphi positions is to ask if the applicant has created a custom control of non-trivial complexity. Thus, I suspect that most Delphi applications still rely mostly on the standard set of controls.

Static Layout

Having custom controls, however, is not the main issue. It is rather, I suspect, a workaround for a problem introduced by the more fundamental flaw of using a static layout.

The aforementioned toolbar and status bar control classes illustrate this clearly - because they are totally superfluous in an environment that uses a dynamic layout engine, e.g. the Web. And so are the tabbed dialog and tree controls, albeit to a lesser degree.

Noise

On a statically layouted window, hiding irrelevant controls (noise) will simply leave ugly gaps, unless a non-trivial effort is made to improve this - essentially writing a small custom layout engine for this particular window. Hence the concept of disabling rather than hiding inactive fields on a statically layouted form.

Aside: I am well aware that disabling an option that is temporarily unavailable is quite distinct to the user from hiding it. It still conveys the information that it has been built in at all. Currently, however, Windows applications typically don’t give a clue as to why something is disabled – witness the absence of hints on disabled controls – and thus severly limit the usefulness of the information.

Pop-Ups

On the other hand, adding information that is currently relevant is just as hard. Take for example the prevalence of modal messages boxes informing the user of error conditions, hints and the like. The usability of this approach is far inferior to showing the information right where it is needed, and not blocking the user.

Microsoft has recently started to address this issue. Windows XP’s logon screen shows neat, non-modal, focus-preserving balloons when Caps Lock is on or an invalid password has been entered. A similar technique are Office XP’s smart tags. The .NET frameworks error message icon, however, does not fit the bill as it requires the user to use the mouse to see what’s wrong.

Design

A traditional Windows application is a project realized by analysts, programmers, and, in the best of all worlds, requirements and usability engineers. Seldom, however, are visual designers involved - except maybe to create icons and a splash screen.

Development Tools

Now, it is not at all impossible to create a very dynamic Windows UI - every Windows Internet browser is, after all, just another Windows UI application. The problem is that the prevalent UI design model embedded in all of the major application development tools currently on the market makes it too hard for most typical application programmers and thus too costly for most project budgets.

Aside: I suspect that because Visual Studio makes it fairly hard to program even statically designed windows, this leads quite a few programmers to forfeit the visual design altogether. Instead, they create and place all of their controls in code. The step from there to a truly dynamic layout is much smaller than for Delphi and Visual Basic.

Web UI Design

Contrast the Visual Studio style described above with how a modern Web UI works. Fundamental to every such UI is the concept of text flow inherent to HTML. Fundamental, too, is the pre-processing of the layout by application logic.

Dynamic Layout

In particular, only the information that makes sense in the current context is presented, the rest is omitted. This is very easy and natural for the programmer to do, either by using a layout template with embedded control sequences that cut out part of the information, and/or by generating the layout entirely in code.

Why is this possible? The concept of text flow allows for structural rather than purely visual rendering of information. Final visual rendering is delegated to the browser. The application’s code is thus relieved from keeping track of which control goes exactly where - a great relief as a layouting engine for a non-trivial layout is non-trivial itself.

Text Flow

The text flow approach makes it easy and natural to provide hints and help texts inlined with the information itself. This is a great help to users in less heavily used and/or complex parts of the application.

What’s more, inlining links, images and controls into the text, and formatting individual text snippets is a snap. This is in sharp contrast to typical Windows GUI design.

Textual Specification

The specification of the layout and elements in text makes it natural to use template-based approaches. Standardized template processors abound because they can work like sophisticated macro processors - they don’t have to understand the content they are manipulating. Text is an ideal medium for black-box store and forward systems.

Aside: This is one reason why XML and SOAP are so interesting. They allow you to integrate foreign data and functionality into your application using the same template-driven approach.

Design

Web applications are typically much more visually pleasing than traditional applications. Why?

The first web applications were targeted not at a company’s own employees, but at customers worldwide. The presented the face of the company to the world. So they had to be appealingly designed.

Now the typical web developer has the skill set necessary to create good looking sites. It just comes natural. And they compare their work with a lot of great looking work, too, so the intrinsic motivation for good design is strong.

Limitations

So what’s wrong with Web UIs? In short, it is the following list. Each item will be addressed in detail in my proposal for a synthesis of the Windows and Web UI design approach.

• Programming model – Programming rich client-side web application logic requires the use of JavaScript or a mixture of JavaScript and applets.
• Printing, filing – Interaction with the surrounding environment (your computer) is severly restricted and, where it exists, cumbersome to use.
• Auto-complete, incremental search – Highly interactive features are hard to do. Simple things like demand-loading lookup lists is non-trivial.
• Custom controls – Doing custom controls (where they are truly beneficial, not a poor man’s replacement for a layout engine) is very hard. You have to write Java applets or – god forbid – ActiveX controls. | Tab key handling, hotkeys – Focus control and keyboard navigation are typically insufficient for maximum user efficiency. This is annoying but not crucial for typical internet applications. It is essential for line of business applications. Modern applications targeted at, for instance, Internet Explorer only, seem to overcome this.
• Splitter bars – Resizing of areas by the user is typically not supported, because it is hard to do.
• Drag and drop – Drag and drop is practically never done, except in Flash items.
• Syndication – Integrating foreign functionality into your own application is easy as long as the foreign functionality is just a web link. It would be much more interesting to be able to place a SOAP call from a link, and to integrate sub-areas returned by foreign providers (like with portlets).

New techniques, like calling web services from within JavaScript code to to demand load data and then modifying the DOM in place, are addressing a few of these problems.

A New Rich Client

I believe the Web approach is fundamentally better than the traditional one. The challenge is to overcome its limitations in an augmented UI design framework.

I propose using the traditional basic Windows controls as the building blocks for a layout engine based, web-like UI framework. Thus, all the benefits of Windows UI controls stay with us, while we gain the additional power of a layouted environment.

Avalon is a prime example of this. XUL comes close. – February 2006