Thomas Williams

My Basic UI Design

I've posted a lot about User Interface (UI) as I am very interested in having a great UI, one which my end-users are able to take advantage of without reading piles of printed documentation and which looks good as well. I thought I'd briefly show the standard UI for Windows Forms applications that I have settled on for my last 3 or 4 projects. Remember, I'm the only "programmer" (my co-workers use mostly Access and Excel along with a little SQL Server, but no "programming" as such) in a department that writes and maintains business intelligence-type applications for a hospital, and I use SQL Server 2000, VB.NET 2003 and Reporting Services for reporting (so I don't have to build reporting into my Windows Forms applications).

The crummy picture below illustrates my current "standard" base UI:

The different elements are:

• Standard Buttons - browser-like "Back", "Forward", and "Home" toolbar buttons (with history drop-down for "Back" and "Forward"), also a toggle button to hide or show the help panel, and an Exit button.
• App-specific Toolbar - toolbar buttons for the most commonly-used screens.
• Application Area - MDI area for the application's screens (called "pages"), navigable using "Back" and "Forward", links on the pages themselves, or buttons on the app-specific toolbar.
• Collapsible Splitter Control - a great splitter that also includes the ability to fully hide, from http://www.codeproject.com/cs/miscctrl/collapsiblesplitter.asp
• Help Panel - this is a web browser control that links to the online documentation. It is context-sensitive in that it tracks page change in the Application Area and displays the correct help in the browser. It can be hidden by the collapsible splitter or the "Help" toolbar toggle button.
• Status Bar - displays status messages. Not too much to say about this.

The Application Area is a "Navigation" control from http://msdn.microsoft.com/vcsharp/using/columns/wonders/default.aspx?pull=/library/en-us/dnforms/html/winforms07202004.asp. Each application screen ("page") is designed for one task only and is intentionally quite simple. One of the design choices that I made out of this principle was to have no sub-toolbars (the only toolbars are the ones in the image above), but use button or link controls on the pages. Link controls generally open other pages while button controls do some work.

The Help Panel displays help for the current page, by linking to my documentation wiki (although page change tracking can be turned off and on by the user). I use the "print" view of the wiki so that none of the standard wiki edit controls are displayed to clutter up the help. The user also has the option to print the current page displayed in the help panel or open it in Internet Explorer. I link each page in the application (which are just VB.NET forms) to the appropriate wiki page using the application's configuration file, so that if the help location changes I avoid a re-compile.

As I have mentioned before, I have had some positive feedback on the UI that's briefly described above. I don't know if that's because everyone is familiar with a browser - a key user for some of my apps is someone who really likes step-by-step processes (I keep telling them that most apps are event-driven: can you imagine a step-by-step MS Word?), but keeping each page simple and for a specific purpose gives the appearance of a step-by-step, logical design. Generally my apps all do the same thing:

1. import a file or set of files
2. process them in some way
3. put the imported & processed data into tables for reporting
4. show the results of an internal consistency audit using specific business rules
5. allow the user to bulk e-mail all applicable staff and tell them that the reports are ready

There is usually one screen for each of these steps, although I use a separate screen for importing and validating new files, and managing previously imported files.

Conclusion

As you can imagine, creating the same basic setup for each project is a lot of repitition - developing an MMC-like shell with plug-in screens for the sub-systems would reduce my development time and save wear and tear on the copy-paste keys considerably, so that's something I'll be working towards in the future.