Developer

Structure the user experience with User Interface Process Application Block

The User Interface Process Application Block (UIPAB) introduces a new task-based design pattern to help .NET developers create more intuitive interfaces. This article discusses the new flexibility--and complexity--inherent in the UIPAB.


Designing a clean, intuitive user interface for your .NET applications is as much art as science, but with the User Interface Process Application Block (UIPAB), Microsoft is providing some help. The UIPAB is one of a series of eight components available for download for free use in Microsoft .NET applications.

To use the software, the projects must be compiled with the provided Solution files. The DLL—Microsoft.ApplicationBlocks.UIProcess.dll—needs to be referenced with the Add Reference menu item in the context menu of the Solution Explorer. One other thing: The UIPAB, as with six of the eight blocks, is not supported by the 1.0 version of the Framework, only 1.1. Visual Studio .NET 2003 is needed to even open the solutions. This might explain why six of the blocks were announced at once, 18 months after the launch of the last block.

A sophisticated solution
The UIPAB is sophisticated software that forces developers to genuinely plan software around the use of the block. It defies easy description, so bear with me while I attempt a clear explanation.

The UIPAB is a user platform-independent component that provides integrated and important parts of the user experience, navigation, and state management. The stated goal of the block is to allow for the abstraction of the user experience from the actual forms that make up the interface. This has many obvious benefits, not the least of which is that you can avoid coding navigation into a form, which would negate the ability to reuse the form in a different form factor.

In the world of Web application programming, many developers use HTML-style INCLUDE statements (or .NET user controls) for page headers, footers, and navigation. Because we can handle details like showing and hiding parts of the navigation system in these files, they abstract not only the physical instance of the common imagery and text, but the logic too.

The UIPAB takes this to a new extreme. Using a task-based design pattern called the model-view-controller, the UIPAB provides the actual physical navigation through the ControllerBase class and management of state through the State class. Essentially, this covers the model (state) and controller (navigation) aspects of the pattern.

Using the MVC pattern
Most of us use the MVC pattern without even knowing it. The MVC pattern describes three objects that control the user experience, each specifically suited to its task. These objects are the controller, view, and model. The controller interprets commands from the user. The view gives feedback to the user based on said commands. The model manages the logic surrounding both of these and, most specifically, the state of the application as it relates to the navigation.

In the Windows world, this is often described best by considering a wizard—a common logical structure. There are separate screens, each with its own functionality. These are views. The forward, back, and cancel buttons represent the control. The most important and least visible of the parts is the model, which remembers which screen the user is on, determines what screen is next, and decides what to do if, say, the user quits in the middle.

You can see that the navigation and state components of the UIPAB are intrinsically linked. This makes for a sophisticated deployment. In this short article, I'll give you enough of the basics to decide whether the UIPAB could be useful in your applications.

Designing for the UIPAB
To get started using the UIPAB, we first need to define tasks in our application. Assuming the use cases are well defined in the requirements documentation, an excellent step would be a statechart diagram. A statechart is a description of a use case or class that documents events and transitions that occur due to interaction with a user. It is a decomposition diagram for object-oriented systems. For instance, Figure A provides a look at a save operation for Microsoft Word.

Figure A


Essentially a flowchart, the statechart focuses on the state of an application at a given point and how it gets there. From the MVC perspective, the "create new file" state requires a view, which would be the Save dialog in a Windows environment, while the "save existing file" is without a view. This represents a single task even though there are two states.

Coding for the UIPAB
Let's discuss the steps you follow to put the UIPAB to work. From there, you'll need to examine the examples provided by the Microsoft Patterns and Practices team.
  • Reference the UIPAB in your functional classes:
  • using Microsoft.ApplicationBlocks.UIProcess;
  • Inherit the controller base class and build the constructor. This gives you access to the Navigate method and State object, which are the control and model parts of the MVC pattern. The views are the screens you use to manage your data:
  • public class TheController : ControllerBase
    {
    }
    public TheController(State controllerState) : base(controllerState){}
  • In the class file, define the various tasks described in the statechart:
  • public void Savefile(object file)
    {
     this.State.NavigateValue = "FileName";
     Navigate();
    }
  • Use the provided StartTask method to get to the various screens of your application, be they ASP.NET, mobile screens, or windows forms:
  • UIPManager.StartTask("FileSaveDialog");
  • Within the views, use the methods described in the Controller inherited class created in step 2 above:
  • private LocalController TheController
    {
     get{ return (TheController)this.Controller; }
    }
    LocalController.Savefile(file);

    Not for the timid
    At this point, it should be obvious that this is not a quick-and-dirty navigation solution; it is a large, scalable, comprehensive structure for navigating well-designed applications. There are significant configuration options using XML files, and we didn't even touch on accessing the state object to pause and continue tasks. If you are looking at creating a sophisticated application, with numerous user tasks, security levels, or tiers of views, consider the UIPAB. It might not be less work, but the application will be better for it.

    Editor's Picks