IUIs and Web-Style Navigation in Windows Forms, Part 1

  • Article

 

Michael Weinhardt
www.mikedub.net

July 20, 2004

Summary: The concept of the inductive user interface is one that can be employed to save users from having to invest time repeatedly learning infrequently used UIs. In the first of a two part series, we examine the inductive user interface, discuss when it is and isn't useful, and then start building our own by leveraging a Web-style navigation implementation for .NET (built by Jan Miksovsky, Microsoft, Longhorn User Experience Team), which is nicely suited to building IUIs. (11 printed pages)

Download the winforms07202004_sample.msi file.

Introduction

Humans do stuff.

Humans use computers to help them do stuff.

Operating systems like Windows XP help users do that stuff.

By stuff, I mean tasks. The fundamental Windows user experience is a task-driven one, and can encompass a wide variety of activities, including:

  • Reading and sending mail
  • Browsing the Web
  • Creating user accounts
  • Formatting hard drives
  • Writing articles
  • Managing a company's product import/export database

The ability for users to complete tasks quickly and correctly is a function of general windowing experience and specific task experience. General windowing experience is the ability to use a contemporary windows-based graphical user interface (GUI), including:

  • Finding, launching, and navigating applications
  • Using standard windowing features such as the mouse, icons, menu bars, tool bars, and so on
  • Managing the file system

Specific task experience comprises the user's understanding of a particular activity and how to use an appropriate application to do so. For example, creating a user account requires knowledge of user names, access privileges, password rules, and user profiles. Another example is using a custom-built application to manage a business activity; beyond knowing how to navigate the application, users need to understand the business rules of the organization, how to execute them using the application, and any potential side effects of activities. In terms of experience, users can range anywhere from newbie to power user. No matter what level of experience a user possesses, each and every user must initially invest time to learn each and every task they perform. However, unless users are power users, they are unlikely to have the time and/or expertise they need to invest in these tasks.

User Experience Economics

When people make an investment, ideally there should be a return on that investment (ROI). This basic economic principle can and should be applied to the user experience. How? Once you understand a task and its anticipated user base, you can begin figuring out how to ensure that users achieve the most benefit by considering the frequency with which it is performed. Generally speaking, the more frequently a user performs a task, the less time they'll spend relearning that task the next time they perform it, increasing the ROI. Conversely, the less frequently a user performs a task, the more time they'll spend relearning that task the next time the perform it, detracting from the potential ROI. Figure 1 illustrates how the potential for ROI increases with the frequency of application usage.

Figure 1. Increasing frequency means increasing ROI

Other factors may also affect the potential ROI, including task complexity and user base experience. As task complexity increases, users may need to relearn more with each subsequent task execution, potentially detracting further from ROI. Figure 2 illustrates this idea.

Figure 2. Decreasing ROI in the face of increasing complexity

On the other hand, as expertise of the user base increases, with regard to general windowing and specific task skills, users may need to relearn less with each subsequent task execution, thereby potentially increasing the ROI further, as shown in Figure 3.

Figure 3. Increasing ROI in the face of increasing user expertise

Identifying Infrequent Tasks

While complexity and user expertise are considerations, frequency is the key factor that determines which tasks have the potential for offering lower ROI. Let's consider the SQL Server Northwind database to see how we can employ this idea. Northwind is a sample database designed to represent the data used by import/export business of exotic foreign goods, and deals with orders, products, customers, employees, employee territories, and associated supporting data. Using a broad brushstroke, I've identified major tasks likely to be conducted by Northwind and graded them with an anticipated frequency:

  • Very frequent: tasks relating to order management and customer and shipper updates are likely to occur often, potentially hourly or daily.
  • Frequent: tasks associated with product list management, supplier and category updates, and employee management are likely to occur less often, potentially weekly.
  • Infrequent: tasks associated with territory and region management may be performed monthly, quarterly, or even yearly.

Deductive vs. Inductive UIs

Having identified that region management is likely to be infrequent, let's look at the specific set of tasks that region management might encompass:

  • Adding a new region
  • Renaming an existing region
  • Deleting an existing region
  • Combining one region with another
  • Moving territories from one region to another

Let's see how these might be incorporated into a classical style of application UI like Figure 5.

Figure 4. Northwind Region Manager

The identified tasks have been implemented as application commands, accessible from the menu bar, shortcut keys, and the tool bar. While this UI does incorporate UI elements you would expect, it doesn't actually go very far in helping improve ROI in the face of infrequent usage. First, it is not immediately obvious exactly what tasks can be performed, something users may not remember by themselves one year to the next. Second, do items in the list need to be selected prior to initiating a task? Third, users of limited windowing experience may have to spend time working out how to actually initiate one of the several possible tasks, either by digging around the menu bar or trying to work out which tool bar button relates to which task. Finally, once they do find the set of tasks, the tasks aren't as refined as they would like. For example, they find "Combine" when what they are actually after is something more like "Move Territories."

Admittedly, some of these issues are minor but some are more important, and all of them require the user to experiment with the UI to deduce the appropriate task and what it actually does. As such, this is said to be a deductive UI and, for infrequent tasks, is a style of UI that can detract from ROI because it requires users to take on the burden of learning things they will likely forget before they use the same set of tasks next time. A better way to approach this would be to design a UI that relieves the user from the burden of learning a UI by guiding them through a set of tasks in a highly instructive or inductive fashion. This concept is also known as the Inductive User Interface (IUI), which has been formalized into a set of guidelines (Inductive UI Guidelines), written by Jan Miksovsky (Microsoft, Longhorn User Experience Team). The IUI version of the Northwind Region Manager might look something like Figure 5.

Figure 5. Alternate version of Northwind Region Manager

As you can see, the UI is simplified and clearly articulates the possible tasks and how to initiate them. The IUI guidelines extend this concept with a set of techniques you can draw on to break down each task into one or more distinct, informative steps as needed, each of which uses adequately informative language and visual cues to clearly articulate the purpose of a particular step within the context of the task being performed.

Dialog-Style vs. Web-Style

You may have noticed that the IUI Northwind Region Manager is presented through a Web-style user experience, instead of a more traditional windows dialog-style of experience. The IUI guidelines are a paradigm independent of the physical implementation used to implement them. As such, you could actually use the same techniques to build an IUI in using either a Web-style or dialog-style approach. The Web-style approach does have an interesting advantage over the Windows Forms-style, particularly if your users have lower windowing style expertise. It is likely that most users have had some type of experience browsing the Web, using one of the many browser applications available today. As such, their familiarity with hyperlinks and navigating backwards and forwards through navigation history, as well as returning to a home page, potentially reduces the learning investment required. Navigation in particular works well, for example, when a user is performing a task and needs to revisit a previous step. Another, perhaps not obvious, advantage is that your Web-style application executes on the local machine, taking advantage of local resources and processing performance.

When Do I Build an IUI?

Deciding whether or not an IUI is suitable depends on whether you think a specific task and anticipated user base will benefit, which is generally guided by frequency of usage. Of course, IUI is a tool you should use on the right occasion, and not for every occasion. If a task needs to be repeated very frequently, or an entire user base is considerably experienced, using a step-based approach may actually prevent users from complete tasks quickly. For example, network support staff who are highly experienced with user account management would likely prefer the deductive Windows 2000 UI in Figure 6 for adding new users, while home users would probably prefer the inductive, dramatically simpler, version from Windows XP in the default workgroup mode, shown in Figure 7.

Figure 6. XP Domain-Mode User Account Management

Figure 7. XP Workgroup-Mode User Account Management

Sometimes, either completely deductive or completely inductive is best, as in the case of the Windows 2000 and Windows XP workgroup mode user account management UI respectively. Other times, however, a combination of both within the same application can also be useful. For example, Microsoft Word 2003 implements a primarily deductive UI for the basic document editing experience. Microsoft Word 2003 also uses an inductive UI known as the task pane to help users assist other users through a variety of infrequent tasks, such as creating new documents, mail merging and, my favorite, the thesaurus, shown in Figure 8.

Figure 8. Microsoft Word thesaurus task pane

The task pane IUI also uses a Web-style navigation to take advantage of familiarity with the general user population's Web browsing experience.

How do I Build an IUI?

While using a Web-style user experience is a great way to build an IUI, there is presently no native infrastructure in .NET to support it. However, the idea of Web-style navigation for Windows Forms applications is so compelling that Microsoft is natively incorporating such an infrastructure directly into "Longhorn," specifically into Avalon (https://msdn.microsoft.com/longhorn/understanding/pillars/avalon/). If, like me, you can't wait until Longhorn is released, the very productive Jan Miksovsky (Microsoft, Longhorn User Experience Team) has also written a Web-style navigation library that you can leverage for .NET 1.0/1.1 applications today. The Navigation library exists physically in navigation.dll and logically in the Microsoft.Samples.Windows.Forms.Navigation namespace. Although unsupported, the Navigation library does provide the features you'll need to build Web-style IUIs.

Creating a Browser Host

To build a Web-style IUI, you'll need two fundamental pieces, a Web-style browser host and pages to browse. At the very least, a browser host needs a single frame to host its pages, home page support and support for loading pages requested when hyperlinks are clicked, and back and forwards navigation history. As it turns out, the Navigation library supports these features in the guise of the Explorer form, shown in Figure 9.

Figure 9. Microsoft.Samples.Windows.Forms.Navigation.Explorer

This is a simple feature set and may be adequate for your requirements. If you need more features from your browser host, however, you have two options to choose from. First, because the Explorer form derives from System.Windows.Forms.Form, you can derive from the Explorer form and use visual inheritance to extend it, which is what I did to spruce up the Northwind Region Manager with a custom region-oriented icon, shown in Figure 10.

Figure 10. Using visual inheritance to customize Explorer

While visual inheritance is fine for customizations that extended Explorer form, it isn't suitable if you need to construct a fundamentally different browser host (if you need multiple frames or richer navigation support, for example). Explorer is built from a set of types, also implemented by the Navigation library that you can also use to construct a custom browser host. The most important of these is the Frame type, which actually implements the basic page hosting and navigation functionality provided by Explorer, which is simply a lightweight UI built around Frame. Frame uses other types you might encounter to make it all happen. First, the entire infrastructure operates on the fundamental unit of any browsing experience, the page, built as a Page type. The Navigation library wraps Page up with the ViewState type into a composite NavigationContext type, designed to represent a page and its state when it was last browsed. Back and forwards navigation are both built from the NavigationStack type, which is basically a collection of NavigationContexts. The home page is simply implemented as the HomePage property of type Page. Figure 11 shows the relationship between Explorer and Frame, and the internal workings of the Frame type itself.

Figure 11. Explorer internals

When you have some variation of a browser host completed, you need to provide the actual application pages, each of which derive from Page to hook into the browser infrastructure.

Accompanying Sample

This installment comes complete with the Navigation library, plus a complete sample client that utilizes it, both being written by Jan Miksovsky. The next installment explores the details of building a complete Northwind Region Manager, so stay tuned for both the discussion and a complete sample.

Where Are We?

We started off by examining how return on investment (ROI) is an important consideration to make with regard to an application's user experience. Generally speaking, higher ROI is achieved as a result of performing tasks more frequently and, consequently, less relearning between task executions. Conversely, lower ROI results from less frequent tasks that users need to relearn with each task execution. We saw that we can transfer the burden of learning a UI into the UI itself, and reduce the user experience to being guided through an application. This concept is the heart of the inductive user interface and an associated set of guidelines written by Jan Miksovsky. The IUI should be a part of your UI development toolkit. The Web-style experience turns out to be a great way to implement an IUI and, in lieu of native .NET infrastructure to help do that, this installment comes with a Navigation library, also written by Jan Miksovsky. The Navigation library provides a pre-built browser host, Explorer, or the pieces you need to build one yourself. It also provides a Page type that you derive from to construct your application's pages. In the next installment, we complete the Northwind Region Manager by building those pages, and discuss the features that the Navigation library provides to help you do so.

References

Acknowledgements

This piece is my understanding of IUI, inspired by Jan Miksovsky's work in this area, which includes both formalization and implementation amongst quite a few other things, and I appreciate his generous provision of time to this piece and consistently detailed discussion.

I'd like to dedicate this installment to my Nagypapa (grandfather). He never worked in IT but he did grow A-Grade chilies, had an uncanny card playing ability, was generally quite cheeky and, lucky for me, made the journey to Australia all those years ago.

Michael Weinhardt is currently working full-time on various .NET writing commitments that include co-authoring Windows Forms Programming in C#, 2nd Edition (Addison Wesley) with Chris Sells and writing this column. Michael loves .NET in general, Windows Forms specifically, and watches 80s television shows when he can. Visit www.mikedub.net for further information.