Mapping Feature Functionality to the User Experience 

This topic considers how the user experience elements of the MMC 3.0 architecture can be composed into a great management experience for the users of the feature. The tool designer can use the information in this topic to establish the level of detail (granularity) of the elements.

When programming to the MMC 3.0 Managed Code Framework, the developer should create snap-in code that is structured along node/view/actions/properties boundaries. These boundaries map logically to the main visual components of the MMC user interface framework, and they represent the granularity of the snap-in functionality exposed to MMC. This topic describes how to build an object navigation model for the tree pane and an activity navigation model for the results pane.

Figure 1 The three major areas of a snap-in.

Feature functionality should be designed with object types in the tree pane, list views and activities in the results pane, and actions in the Actions pane. Typically, a user will navigate to an object container in the navigation tree, which will show a list of objects in the results pane. Note that the tree pane and the Actions pane can each be turned on or off by the user, or they can be controlled by the console file. Thus the developer needs to allow an effective activity navigation experience completely in the results pane.

Navigating to Objects in the Tree

Only two types of nodes should appear in the MMC tree: container nodes or resource nodes. A container node is used to organize the tree information in a hierarchical manner to facilitate navigation. A resource node is a leaf node in the tree for a specific navigation path. For example, the tree could have a container node called User that contains two resource nodes called Domain 1 and Domain 2.

Guideline 1 Create a hierarchical tree view with containers for each object type.

The MMC tree control is designed to provide easy access to objects. The tree has container nodes that allow objects to be grouped together in meaningful ways so that users can quickly locate desired objects. MMC 3.0 supports a single hierarchical tree view of resource nodes and container nodes. Regardless of whether the tree is displayed by default, a tree must be constructed for every MMC snap-in.

The tree should not be used to display activities or actions. The guidelines will describe the appropriate ways to organize object containers as nodes in the tree.

The Contents of the Tree

Keep the tree structure as static as possible, particularly in the upper levels of the tree. A dynamic set of nodes in the tree that changes unpredictably will make the navigation experience unpredictable for the user. Use the following techniques:

• When part of the functionality of the snap-in is to provide the user with a choice to create custom folders of objects or views, ensure that there is a static parent node under which the user-created folders are created.
• Each container node should contain only one type of object.
• Containers in the tree should be organized and grouped in logical ways. Select the best model for your tree and test with users. Some models include:
  • Established standard order. When users look for items in a list, they depend on their experience with the same item in other lists. Always consider precedent and consistency when you design your tree.
  • Alphabetical order. This method is good for lists of objects, such as names in an address book or files and folders. However, this is probably the worst method for ordering items in a tree because it relies on users knowing exactly what you have decided to call something.

What Not to Show in the Tree

Do not show activities or object instances in the tree.

Rationale:

• There is limited space in the tree.
• Displaying activities in the tree means that an object could appear in the tree in multiple places with different actions.
• Placing activities into the start pages and objects containers in the tree means that users will clearly know where to expect different types of content to appear.
• Adding activities in the tree can add an extra level in the tree hierarchy that expert users do not need. This means they will always have to click down an extra level to get to the objects they want.

Choosing the Scaling Points

Do not represent configuration objects that typically exist in large numbers in the tree. Always show large numbers of objects in the results pane in a list view and provide sort/filter/search capabilities to match typical usage scenarios. Consider the following layout designs.

• When the type of object has no sub-hierarchy of configuration information, use a simple list with optional browse pane (see Results Pane: Design Guidelines).
• When an object type (at a leaf node) can be further organized into subtypes, you should create a Form View rather than use the List View. You cannot use the List View to create the required object structure. The Form View approach should be used only when you are at a leaf node of the tree.

Guideline 2 Every container node has a list view in the results pane, and the Actions pane displays the applicable actions.

Console Files

Each Windows Server feature should be distributed with one single primary console (.msc) file that can access all of the feature functionality. Although the next section discusses the use of multiple management tools and snap-ins, these secondary tools should all be accessed from the one primary console, which should be easily discoverable. For example, the feature could install a shortcut to the primary console in the Administrative Tools folder for all users.

The best practice for creating .msc files is to start MMC from the command line, add the primary snap-in to the console, select the primary snap-in node, click the root node, and select New Window from Here. Then, delete the first window, maximize the remaining window, add other options, add other nodes, and size as described in the topic on console sizing. Finally, save the console with the user-recognizable name of the feature. This console will then be the user-recognized way to access the feature. Make sure that every object type and every action identified in the data collection process can be easily located in the tree pane. The best way to do this is to create a very shallow tree view with containers that name the single object type that is found in the container. A deep hierarchy of containers can make it hard for users to find the object that they want to manage. The best way to handle a rich structure of objects is to use a custom view control in the results pane.

Understanding Stand-alone Snap-ins and Extensions

There are two types of snap-ins and two usage models for snap-ins. The two types are stand-alone snap-ins (commonly just called a “snap-in”) and extension snap-ins (also called an “extension”). The reasons for creating an extension are (1) the primary snap-in exposes functionality that is needed by the extension; (2) the extension should inherit the context of the primary; or (3) the extension has to share data with other snap-ins.

The two usage models for snap-ins are as the root node of the console and as a subnode under the root node in a console file. It is possible to build a snap-in that can operate as either a stand-alone or an extension snap-in. Use the following rules to decide whether an extension snap-in model is desired. If you do not need to create an extension model, you can skip the rest of this topic.

Simple designs are usually best, so extension snap-ins should be used only in special cases, such as those outlined below.

MMC as the user interface framework provides composition of functionality from multiple snap-ins into a single environment. This composition is exposed to the user through the console authoring process.

Guideline 3 Create a single snap-in for your feature if it is not complex and if its functionality is not to be shared with other snap-ins.

Before looking beyond the first model, consider if it is possible to organize functionality by using Wizards and property pages in saved consoles before deciding to create multiple snap-ins for your feature. Objects typically have a list of attributes that can be best managed with a property page.

Storing User Data

Although the installation process can be presumed to require administrative privilege, the user could have started the administrative tool or MMC console with least privilege. For this reason, and to handle the case where more than a single user accesses the feature management tools, all run-time configuration information should be stored in a user-accessible location (for example, in the registry under key HKCU or in the file system under the user’s profile).

It is also possible for an MMC snap-in to store data in the console (.msc) file, but this will have the effect of asking the user for permission and setting the next snap-in configuration information to whatever the current state of the console as set by the user. For these reasons, most developers choose to prevent the user from editing or saving the console file by setting Author Mode to off in the .msc file.

Specific site-wide configuration information can be written by the installer in the local machine (HKLM) store.

Deciding When to Use Multiple Snap-ins versus Snap-in Extensions

Users usually want to be able to access all the functionality of a feature from a single entry point, so a single tool will often provide the necessary combination of activities for all user types. If that approach does not lead to a good user experience, consider a finer granularity of design.

Guideline 4 Create multiple snap-ins or extensions if your feature is complex with very distinct user types and scenarios.

Here are some of the things to consider when making a decision about the complexity of your feature:

• Is there a natural separation of activities and objects so that different user types will interact with one set and not another?
• Will users want to construct their own consoles by using the granularity provided by separate snap-ins?
• Will users always be able to find the objects that they need when they start from the main console?

These are some things to consider when making a decision about distinct uses of your features by different user types:

• Do some activities require different security privileges than others?
• Are some activity groups optional (they should not be exposed to all users)?
• Will some of the activities have to be exposed in multiple products?
• Do you want other products to extend your snap-in?

Take the full list of user scenarios and separate them into the snap-ins that are appropriate to them. After that, make sure that all objects and activities that support those scenarios are in the tree pane, results pane, or Actions pane of each snap-in. Occasionally, an object or activity will appear in more than one snap-in when a complete separation is not possible.

Create one main feature snap-in in which all the other snap-ins can be accessed through both the tree view and the start page as needed.

The feature should install a single console (.msc) file that can be added to the Administrative Tools folder for all users. Most extension snap-ins will also be accessible as stand-alone snap-ins for use by the specialist administrator. Therefore, it is important to understand the different use cases and how the design of the snap-in needs to work when it is used in a standalone mode versus an extension mode.

Extension Types

• A property page extension adds property pages to a property sheet (which is associated with an object) in the stand-alone snap-in.
• A namespace extension adds functionality to a stand-alone snap-in by adding additional nodes to the snap-in’s tree. The namespace extension provides all the data, views, and actions associated with these nodes. When you separate functionality, the stand-alone snap-in determines which of its nodes can be extended. A namespace extension can add nodes (and trees) beneath the snap-in's nodes. One snap-in node can have multiple extensions.
  A namespace extension can also allow its nodes to be extended by other extensions, which permits multiple levels of nesting. By default, all snap-in extensions available on a computer are enabled unless the snap-in console author has explicitly restricted the set.