Server Operating System
White Paper
Microsoft® Management Console (MMC) is an ISV-extensible, common-console framework for server and network management applications. MMC will be released as part of the next major release of the Microsoft Windows NT® operating system. This paper provides a set of user interface guidelines that snap-in authors can use to assist in designing their management console-based applications.
MMC is a core part of Microsoft’s future management strategy. Microsoft development groups will use MMC for future management applications.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
ActiveX, BackOffice, BackOffice logo, Microsoft, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0997
This document describes the middle, most visible, step in creating a snap-in—the actual design of the user interface. Before this can take place, however, you must have prepared a good foundation. Perhaps the single most important document that you will read about the Microsoft® Management Console (MMC) is the design process document, Snap-In Design and the Windows NT 5.0 Administration Model. By following the steps outlined in that document, you can ensure that you have an adequate foundation for designing your snap-in. Among the things that the design process document will help you with are the following:
Once you have determined who your users are, what they will be doing with your tool, and what functionality you must provide to allow them to do it, it is time to determine how this functionality will be offered to them. That is where this document comes in. There are a number of design decisions that you need to make, whether you are designing a separate application or an MMC snap-in, and there are also decisions that are specific to the console itself. This document focuses primarily on the latter type—those design decisions that are specific to the Microsoft Management Console.
Writing a snap-in for the common console is similar to writing a stand-alone application. All of the old user interface (UI) guidelines still apply: simplicity, thoughtful organization, easy access to commonly used functions, and careful separation of complicated tasks into simple steps. The major difference is that your application will not run directly on the desktop anymore, but rather will run inside the Microsoft Management Console. This environment requires that your snap-in behave in a predictable manner so that it can exist seamlessly in the same console as snap-ins provided by other manufacturers. This document defines those behaviors from a user interface perspective, but it does not attempt to define the programming interfaces by which these behaviors are achieved.
The Microsoft Windows NT® operating system version 5.0 required that many Microsoft Win32® administrative applications be rewritten to fit into the MMC console framework. In some cases these applications had tree-type controls and some had result view-type lists. In most cases the application facilitated a particular type of task that could be activated for the computer it ran on. This paper builds on that experience.
By the time you have read the other MMC introductory material, you probably have a pretty good idea of whether or not you want to build a Microsoft Management Console snap-in. However, if you still need help in deciding whether to write a snap-in or implement your application in a Web page or as an applet in the Control Panel, review the information in Appendix B.
At first glance, an MMC UI looks and feels much like an MDI version of Explorer. A complete MMC console might look like this:
Figure 1.Prototype of MMC User Interface
The MMC parent frame has a master menu and toolbar. The master menu offers what is typical of an MDI parent: file and window management and Help.
The MDI child windows offer many differing views. Each of these child views includes a command bar, a scope pane, and a result pane. The command bar contains both drop-down menus and buttons. The scope pane (the left pane), is a tree control displaying the tool’s namespace, the tree-formatted listing of all visible nodes, each of which represent a manageable object, task, or view. The scope pane need not be visible in all child windows, it can be hidden if desired.
Each child window’s result pane (the right pane), displays the result of selecting a node in the scope pane. In many cases, the result pane shows a list of the contents of a folder. In other cases, it shows a management-related view, which can be Web- or ActiveX™ control-based.
The next few sections concentrate on stand-alone snap-ins, followed by a discussion of how extension snap-ins should appear. Note that key terms and phrases—including stand-alone and extension snap-ins—are defined in Appendix A. Appendix C provides a guideline checklist. Read the rest of this document to get the full context of snap-in development, then use the checklist throughout your development process.
A stand-alone snap-in is seen by the user as a node in the scope pane tree. One question that you must answer when building a new snap-in is “what nodes will I show in the tree view?” The answer is dictated by the objects and result pane views that your application needs to display.
For some snap-ins, it is particularly easy to decide which nodes to display in the namespace because these snap-ins have well-defined categories of objects, and this component structure easily maps to the namespace organization. Generally, these snap-ins simply place their containers into the tree with the appropriate objects below them. The important point here is that the scope pane tree will generally show objects or object containers, and actions will be taken on those objects using toolbars or context menus.
The main thing that you must decide when laying out the namespace is what nodes will be exposed and whether those nodes should be container nodes, viewable nodes, or leaf nodes.
Use the following simple guidelines when deciding what should go into the namespace:
There are also some fairly clear rules for which nodes should be container nodes, leaf nodes, or viewable nodes:
The third point above means that, in some cases, it is necessary to launch a new instance of the console to permit editing and viewing of objects that should really be containers but that are forced into being leaf nodes by the constraints of the tree control. The relationship of computers in the distributed services (DS) and in the Computer Management snap-in is a prime example of this. For example, from the DS Management snap-in, if you right-click a computer object and choose “Manage…” the Computer Management snap-in starts with the focus on that computer.
Web pages are examples of viewable nodes (addressed in the fourth bullet above). Web pages are, by their very nature, viewable nodes because they must use the results pane to display themselves. Although it is functionally possible, Microsoft does not recommended the use of Web pages as containers to form hierarchies of related pages. This is because some users tend to work with MMC with the scope pane closed; in this case a user may not be aware that the saved console file contains multiple Web pages. If you need to group Web pages together, create an empty folder to hold the Web pages so that a user working without the scope pane can see a view in which all of the Web pages appear.
When a snap-in has result views that contain objects displayed in a manner different than its list views and task pads, the result views are called custom views. In these cases, it is possible for an object in the snap-in's namespace to have a result pane view that shows information other than what children that object has. The danger in implementing a custom view is that users could find it difficult to access the children without using the scope pane to navigate to those children, and other snap-ins might be unable to extend your snap-in via the custom view.
When it is necessary to create a custom view, there are several things to think about. It is critical that you allow other snap-ins to extend yours. Although it is possible that you will decide that context menu, toolbar, and property page extensions are sufficient for your ISV community, there is no way for your snap-in to prevent namespace extensions. Consequently, you must design your snap-in with namespace extensions in mind. This means grouping objects in your namespace such that similar functionality could be added to the namespace later. It also means using the namespace as a primary navigation mechanism rather than depending exclusively on result-pane controls to provide navigation within your snap-in.
The following illustration show a console’s name space containing two calendar controls, one under the other. Since the calendar control uses a custom view in the results pane, you can’t see that it has a child under it except through the scope pane.
Figure 2. Prototype of Namespace with Two Calendar Controls Visible in the Scope Pane
If everyone tells you that you need to offer a task-oriented user interface, does that mean that you should put tasks in the namespace? The answer to this is a resounding “No!” The console can offer a great deal of task orientation, but it does so through well-organized context menus, descriptive results panes, and effective task pads. What belongs in the namespace are objects and object containers. Tasks have no place in the namespace.
A snap-in can have various states. For example a snap-in that represents connectivity through a modem may need a different icon when the error rate of transmission is high or the connection has been dropped. Some snap-ins will never require such icon changes. If your snap-in has any type of security logon that may fail or not be working, you should prepare for this failure. In this failure case, the subnodes should not be expanded and the icon should be set to indicate this. There should be a context menu selection on the main node to allow another logon.
In other cases, there may be child folders that represent machines under the main node, and these machines may require a logon. The same behavior would be appropriate in this case—the machine would appear but not be expandable or have any menu capabilities (for administration and so forth) except logon.
The permanent MMC menus and the main application toolbar may not be extended by snap-ins. It is intended that these menus and the main toolbar be populated only with actions that affect the entire console, rather than actions that pertain to a particular snap-in. The following picture shows the permanent menus (Console, Window, Help) and main application toolbar (directly below the permanent menus):
Figure 3. Prototype of Permanent Windows and Main Toolbar
A particular snap-in may, however, create its own toolbar which will be placed on a band in the rebar control at the top of the child window in which its node is selected. These snap-in created toolbars may also contain “command bar” style drop-down menus that can expose actions appropriate to that snap-in without relying solely on the context menus. Figure 4 illustrates these “command bar” style drop-down menus with the MMC-supplied Action menu selected:
Figure 4. Prototype of Command Bar Style Drop-down Menus
In each child window it is possible to place multiple bands in the rebar control. The bands are separated by small, vertical “grab handles,” like this:
Figure 5. Rebar Control with Grab Handles
In addition to bands placed on the rebar control by snap-ins, there are a couple of bands that are owned by the console itself. The following sections describe these bands.
Not all computer users know about right-click (context) menus, particularly those who have recently migrated from Windows NT 3.51 or Win3x environments that don’t have these context menus. To accommodate these users, the Action menu provides a drop-down list that is an exact replica of the context menu for the currently selected node. Since the console depends so heavily on functionality that is present only in the context menus, the Action menu is quite important in improving the discoverability of key features.
Figure 6 shows this menu in its expanded state focused on a particular object:
Figure 6. Action Menu in its Expanded State
MMC provides the capability to create custom “command bar” style drop-down menus. This feature should be used in with extreme caution. It is always a good idea to minimize the amount of UI that the user can interact with.
The second console-owned toolbar that is displayed on each child window is the common commands band. This band contains the following commands:
Each of these commands can be in one of three states: enabled, disabled, and hidden. If a snap-in will ever use one of the common commands when a particular object is selected then that command should be shown as either enabled or disabled. It should only be hidden if a particular command will never apply to a given object.
Please also note that since these commands appear on the common commands band, your snap-in should not put these buttons on its own band.
This paper has described all of the child window toolbars provided by the console, but what about those provided by the snap-in? As a snap-in author, what can you put in a toolbar? There are several guidelines that you should keep in mind as you create your toolbars:
Always provide the user with a visual indication about which toolbar items can be used. If a button is not applicable or appropriate in a particular context, hide it from the band. Leaving the button visible and then presenting a message box when the user selects the button is a poor method of providing feedback. (Note: for complete message box guidelines, refer to the Win32 SDK.) Disabling (graying) the button instead of hiding is possible, but should be done only when there is some way that a particular toolbar item can be re-enabled by the user. Toolbar buttons that will never apply to a particular object should be hidden rather than disabled.
One of the bands provided by MMC itself is the description band. This is actually not on the rebar control, but is positioned directly above the results pane. The purpose of this band is to provide a place for snap-ins to place status information that requires a higher degree of visibility and persistence than items in the main application status bar. It may also be used for descriptions of the contents of the results pane, such as describing the filter state of a particular listview. It is particularly appropriate for displaying the following:
As implied by their name, context menus are context-specific, that is, they show only the commands available in a particular selection context. For more information, see the section “Disabling Commands Based on Context” in this document.
The console provides structure for the context menus that extends considerably beyond that found in the shell. For any given node in the tree there are three types of commands provided on the context menus:
In addition to specifying which types of snap-ins can place items on the context menus, the console specifies where these items can be placed. The console provides three distinct areas on each of the Task and New branches on the context menu. On each area, primary snap-ins can place items only in the top third, the console in the middle third, and extensions on the bottom third. This arrangement is illustrated in Figure 7.
Figure 7. Context Menu Placement Areas
When building a snap-in’s menus, first divide up all commands for each node into two categories: New and Task. New and Task are cascaded menu items which appear on the top level of the context menu for each node.
The New menu is intended to be filled by any “create new object” actions that can be taken on an object. For instance, if a node in the tree knows how to create a new folder then that would appear in the New menu.
Your snap-in should place any commands that do not create new objects in the Task menu. These should include but are not limited to any wizards that are appropriate for the currently selected object—even if those wizards actually end up taking the user to a different object in the namespace.
After dividing the commands for each node into New and Task, decide which commands from those menus will be used on a regular, or frequent basis. The top one to five most frequently used commands for a particular node should be duplicated on the top level of the context menu (above the New and Task menu items.) Therefore the frequently-used menu commands will appear twice—once at the top level and once under New or Task.
There are a few rules for snap-ins that extend another snap-in’s context menu:
One particular “command bar” style drop-down menu on the Action band is accessible to the primary snap-in. That is the “View” drop down. The views are extensible, but only if explicitly enabled by the primary snap-in. The primary snap-in enabling this will also be responsible for providing a mechanism by which alternative views may be requested.
The primary snap-in also has the opportunity to disable any of the other views above these (and, consequently, hide the menu items). The presence of a view which shows only an OCX in the results pane will not automatically disable the list view or HTML view options. This allows the primary snap-in to use the View menu to supply multiple views of an object.
It is the primary snap-in’s responsibility to persist this view state. When a node is initially selected, the console will ask the primary snap-in what view is selected. More information regarding storage and persistence models can be found in the SDK documentation.
Just as you would for toolbars, always provide the user with a visual indication about which menu items can be applied. If a menu item is never appropriate or applicable in a particular context, hide (remove) it from the menu. Leaving the menu item visible and presenting a message box when the user selects the menu item is a poor method for providing feedback. Disabling (graying) the command instead of hiding it is appropriate only when there is some way that a particular command can be re-enabled by the user.
Only the primary snap-in should provide default actions for an object in its results pane. Extensions cannot specify that their action be the default. There are two steps to specifying that an action is the default:
If a built-in verb is specified as the default action (for example, Properties) the console will bold it automatically.
Note that while you should bold the default action, it is not necessary to move it to the top of the menu. In many cases, it is more effective to improve consistency of command placement on the context menus between several similar objects, and this may dictate that the default action is not the top action on the list. The built-in Properties item is a prime example of this.
Most applications rely on some sort of secondary windows. In most cases, those windows are either modal dialogs or non-modal property pages. MMC allows either of these to be used, but where possible Microsoft suggests that you use non-modal property pages. Modal dialogs should be used only where it is necessary for a decision to be made before proceeding on to anything else because modal dialogs block access to any other tool within that console file.
Property pages in MMC work like they do in the shell, with one difference—property pages in MMC should always use the standard shell large size (252x218 dialog units) for the following reasons:
Property pages should not be placed directly in the results pane to allow users to browse object properties in quick succession. Although individual subsets of properties can be directly altered in particular views on an object, the user should almost always be able to bring up a standard, non-modal property sheet on any object with properties not displayed in the result view. In some cases, result view objects may not have properties other than those already displayed in the view. In this case, it is not necessary to provide a property sheet for those objects.
The title on the property sheet is provided by the primary snap-in that creates it and should be of the form <Object> Properties, where <Object> is replaced by the name of the particular object.
There are some additional, more subtle guidelines that you should observe when creating property sheets:
Just as property pages should be consistent in size, so should all wizard pages. Also like property pages, it is up to the primary snap-in to choose the size for the wizard. It is much less likely that a differently sized wizard will be required than it is that a differently sized property page will be required, but the possibility still exists. When designing wizards, use the following guidelines:
These guidelines are just a subset of the wizard information found in the Windows Interface Design Guide.
For wizards in the Windows NT 5.0 timeframe, Microsoft strongly suggests that you use the new Wizard97 style. However, if your snap-in is shipping prior to Windows NT 5, this option is not available to you. MMC itself does not distribute the new common controls DLL that is needed for Wizard97-style wizards, and this DLL is not currently planned for a service pack prior to Windows NT 5.
The relevant information on the Wizard97 guidelines can be found at the following location on the World Wide Web: http://www.microsoft.com/msdn/sdk/inetsdk/.
MMC will place a command on the Help menu <snap-in> help, where <snap-in> is replaced by the name of the snap-in that currently has focus. When this menu item is selected, the snap-in in focus will receive a MMCN_snap-inHelp notification, and will be responsible for making the correct call to invoke its help engine. For consistency with future versions of MMC, Microsoft recommends that your snap-in launches the HTMLhelp viewer, but the MMCN_snap-inHelp mechanism leaves it open for your snap-in to call help in any way you choose.
There are no particular help topic style guidelines imposed by MMC. Because the HTMLhelp topics are simply Web pages, snap-ins are free to organize them and display them as desired.
Microsoft suggests that the help contents have a single root with the name of the snap-in (or something recognizably similar to that name). In the case where multiple help topics reside in the help contents, this will aid users in locating the help topics they need.
A new concept in the HTMLhelp engine is the idea of hidden information types. In the Windows NT 5.0 timeframe, MMC will use this idea to provide a filtered list of help topics that are relevant to the current selection context. As you are authoring your help topics, you should consider which type of object each topic relates to, and tag that topic with the relevant hidden information type. Snap-ins will be responsible for supplying this information type for filtering to allow F1 help and the context sensitive help window to index the information.
There are two schools of thought with regards to help on property pages. One has the context sensitive help being sufficient. The other finds an advantage in the use of a help overview page on each property sheet. Either approach to dialog help is possible in MMC. If you wish to use the context sensitive help, your snap-in will have to respond to the MMCN_ContextHelp message by calling Winhelp with the appropriate Help ID. Please note that MMC does not participate in either the calling of Winhelp or the assignment of help IDs.
If you wish to provide overview help then it should be in addition to the “what's this” help described above. To do this you must enable the Help button on the property sheet and then handle the button press in your snap-in. Only the primary snap-in will be able to do this. If you are writing a property page extension snap-in you will have to provide your help using the “what's this” help mechanism.
One form of help often overlooked is the creation and display of good error messages. Above all else, users want error messages to give them a specific action to take to resolve the problem. Poorly written error messages can make users feel like ignorant failures. And in any error situation, what the user wants most is to know how to eliminate the error.
When preparing error messages, consider the following guidelines:
As the MMC is nothing without snap-ins. snap-ins are nothing without a saved console file. Just because you create a snap-in and ship it does not mean that customers will be able to find it and use it. In many cases, users may not even know that it is possible to open an empty MMC console and add snap-ins. It would be wise to include in your installation program an MMC console file that has your snap-in added already. You can then have your tree opened as you would like it, and a node selected to show important information. If you have a “getting started” task pad in your tree, you would want that one selected.
The creation of your saved console file does not require any programming.
To create the file:
After the user runs the setup program and installs your snap-in, the user should have a saved console file listed on his or her Administrative Tools menu. This menu selection should be a shortcut to the saved console file, and the icon should be changed as appropriate.
The goal of an extension snap-in is to function in such a way, that the end user will not be able to distinguish its functionality from that of the primary snap-in. Extension snap-ins can be created in varying degrees of complexity. At one end of the spectrum would be a complete full functioning tree node—a node that is inserted into a primary snap-in’s tree. This type of snap-in would be in all practicality just like a stand-alone snap-in. It could open up and reveal sub-containers under its node, populate the results pane, have context menus, property pages and all that a stand-alone snap-in has. The only difference is that it never needs to place a node under the console root in the scope pane, but instead, places itself under some node of an already existing snap-in.
Simpler types of extension snap-ins may only add a property page or menu selection. What ever the type of extension snap-in, you should take extreme care to be as consistent as possible with the primary snap-in.
At first, writing an extension snap-in may seem much easier than writing a stand-alone snap-in. After all, many of your design decisions will already be made for you—you may not need to worry about how your toolbar will look, you may not need to provide property pages, you may not even need to put any nodes in the namespace. However, when writing an extension snap-in there is a greater expectation that you will integrate seamlessly with the snap-in you are extending. The uninformed user should never know which functionality is provided by the primary snap-in and which by the extension.
The following are some of the design decisions you must pay careful attention to when writing an extension to ensure that you integrate smoothly:
The Microsoft Management Console supports two types of snap-in behavior. A stand-alone snap-in can function independently of any other snap-in that may be loaded in the console. An extension snap-in, by contrast, depends on another snap-in to provide it with context information. It is even possible for a snap-in to fulfill both roles.
Many of the same design considerations apply to extension snap-ins as they do to stand-alone snap-ins. The major difference is that an extension snap-in will generally operate on some objects controlled by its parent snap-in and should therefore follow the design decisions made by its parent. The decisions required to build an extension snap-in are a subset of those required to build a stand-alone snap-in.
For example, Figure 8 shows an MMC console with a single stand-alone snap-in in the scope pane. (The stand-alone snap-in shown here is the Computer Management snap-in; for more information about extending this snap-in, see the paper Snap-In Design and the Windows NT 5.0 Administration Model.) This stand-alone snap-in is designed to manage objects that belong to a computer. Notice that the selected node in the tree is currently empty. The System Tools node will be a place that other snap-ins will want to extend and appear under. Any snap-ins that provide administration of system information could appear under that node.
Figure 8. MMC with Single Stand-alone Snap-in
Figure 9 shows a node that appears under the System Tools node. This was placed there by a snap-in that extended the Computer Management snap-in. It is up to the user to add snap-ins to a console, and decide which snap-ins to allow as extensions. In this example the extension snap-in receives its context information from the primary snap-in it extends. In this case, it received a clipboard format that identifies the computer it is to point at. The primary snap-in here could have been set up to look at the local computer or some other remote computer. It would even be possible to pass more specific information to the snap-in extension; for example it could display only SQL Server™ events. All of this is accomplished through the passing of information from the stand-alone snap-in to the extension snap-in via clipboard formats.
Figure 9. Prototype of Extension Snap-in Displaying Information from Clipboard Formats
In some cases, an extension snap-in may begin its design and development as a stand-alone snap-in. The code to turn it into an extension snap-in can then be added later. This would only apply if your snap-in is one that populates nodes in the scope pane and acts like a stand-alone snap-in, except that it lives in the tree of an existing snap-in. An example of this type of snap-in is the Windows NT 5.0 Event Viewer snap-in.
Extension snap-ins can actually provide extension to varying degrees. A particular extension snap-in may never add nodes to a tree, but may just provide a property page to an existing node. In that case you would need to design your snap-in from the start to extend your specific targeted snap-in.
As previously mentioned, an extension snap-in may simply add a property page to its primary snap-in. In most cases, this is just a straight-forward process that needs some careful attention only in the area of UI consistency. You should, however, be aware of the following points:
The previous section should not have given the impression that an extension snap-in is difficult to design. If the primary snap-in has been designed effectively, then many of the decisions you must make will be very obvious. When you design a stand-alone snap-in, it is your job to make the correct and most effective design decisions. Therefore, a stand-alone snap-in is not necessarily easier to design although it has fewer dependencies and your range of choices is much less restricted.
When you write a stand-alone snap-in, the important thing to keep in mind is that not only will your users have to live with the design decisions you make, but so will any snap-ins that may extend your snap-in in the future. (Note that extension snap-ins are not entirely free from these concerns, as it is possible to have an extension snap-in that extends another extension).
This document has given an introduction to some of the issues that you must consider in designing a flexible and consistent snap-in, but it is by no means the definitive last word on snap-in design. There are an infinite variety of situations in which you could be forced to alter (or even reverse) the design guidelines offered in this document. It is for this reason that the iterative design process outlined in the introduction is so important. This process provides an opportunity for peer review of your snap-in and should help you tailor some of these guidelines to your particular situation.
With the above in mind, Microsoft recommends that you do not try to design your snap-in in a vacuum. The quality of your design will improve remarkably if you approach it in small iterations and continually seek outside input from the design and usability resources that you have available to you.
This document provides you the basic information that you need to create a well designed snap-in, but there are some other important sources of information that you may want to reference:
This document provides a general introduction to some important concepts that you will need to know to develop an effective snap-in. This should be the first MMC document you read.
This paper focuses on the new Windows NT 5.0 administration model and how snap-ins can be designed to take advantage of that model.
The vast majority of the design guidelines in this excellent resource are as applicable to a Management Console snap-in as they are to a stand-alone application. This guide is published by MS Press, ISBN #1-55615-679-0. Complete contents are also available on the Web at: http://www.microsoft.com/win32dev/uiguide.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/backoffice or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS). To access information via the World Wide Web, go to http://www.microsoft.com and select Microsoft BackOffice®. For document availability and management-specific information please see http://www.microsoft.com/management. Also check out the news groups microsoft.public.management.*. You can also send mail to manageit@microsoft.com.
Document
See Tool.
Extension Mode snap-in
A snap-in that provides functionality only when invoked by a parent snap-in. Extension snap-ins can add nodes to the namespace or can just extend existing nodes with new menus, toolbars, property pages, wizards, or Help.
.Msc file
A Management Saved Console (.msc) file that constitutes a tool. Once an administrator has assembled a tool using various snap-ins, the administrator can save the tool in an .msc file. The .msc file persists the tool so that it can be opened and used again later. An .msc file can be passed on to another administrator. Any administrator can open the .msc file in MMC, causing the tool to be loaded. See also Tool.
Multiple Document Interface (MDI)
An interface that supports multiple simultaneous views, or windows. SDI, or Single Document Interface (Internet Explorer, for example), does not support multiple views.
Package
A collection of snap-ins collected into a unit for shipment by a software vendor.
MMC
The Microsoft Management Console—Microsoft’s general, ISV-extensible common management console, planned to ship in the next major release of Windows NT. The MMC console itself is a Windows-based multiple document interface (MDI) application. MMC itself provides no management behavior, but instead provides a common environment for the snap-ins, which provide the actual management functionality.
Mode of Extensibility
Behavior that a snap-in provides, extending the console with more functionality. Microsoft has defined several modes of extensibility, and every snap-in must provide at least one of those modes.
Namespace
A tree-formatted, ordered listing of all the nodes available in the current tool. The display of the namespace is similar to a folder and directory structure on a hard drive. See also Node.
Node
Any manageable object, task, or view. Examples of nodes include computers, users, and Web pages.
snap-in
Software that makes up the smallest unit of console extension. One snap-in represents one unit of management behavior (for example, the Windows NT event log viewer is a functional unit of management, and thus a good candidate to become a snap-in). Technically, snap-ins are OLE In-proc servers.
Stand-alone Mode snap-in
A snap-in that provides functionality even if loaded alone in a console that has no other snap-ins.
Task pad
An HTML page plus scripting that provides a novice, occasional, or first-time user (1) an introduction to the tool, and (2) an easy way to navigate and discover frequent and/or common tasks. More information will be available with Windows NT 5.0 Beta 2.
Tool
An assembly of multiple snap-ins into a single compound document, or console. A tool contains and provides all the management behavior represented by all the snap-ins contained in the tool. A tool can be saved (in an .msc file) and reloaded. A tool is also called a document.
To distinguish whether a set of functions should be added to the Control Panel or the MMC, you need to determine whether the functionality is aimed at personal settings or management tasks. While this distinction may be fuzzy at times, it depends on several well-defined characteristics.
A Control Panel application should generally conform to the following:
MMC snap-ins are generally appropriate for tasks with the following characteristics:
Finally, you may want to consider the use of an administrative wizard if your application falls between the two descriptions above. An administrative wizard can be accessed either from the shell or from MMC, and has the following characteristics:
An example of an administrative wizard is the file sharing wizard. Managing file shares is normally an administrative task, but a certain limited subset of the functionality is of interest to non-administrators. This functionality was exposed in a wizard that can then be called from MMC or accessed directly from the shell.
Web pages are currently very well suited for one-time or infrequent management tasks. Unfortunately, for tasks that are repeated frequently or that are more complex and demanding in terms of user interface, Web pages are not ideal. There is a lack of fidelity and richness in the user interface that make it unsuitable for frequent use, particularly in situations that do not demand the ubiquity of access that Web pages provide.
If you do need ubiquitous access to the functionality, consider using a mixture of Web pages and an MMC snap-in for your complete solution. This will allow you to offer the rich Win32 UI that users are accustomed to, while still providing some base functionality on Web pages that can be reached from within MMC. Web pages are always the solution for pieces of your interface that must be accessible on as many platforms as possible. Core functionality should be implemented as server-side objects to minimize the amount of duplication of work in the Snap-in and the Web page. This would allow dual usage in your MMC snap-in as well as through your Web pages.
This appendix is meant to be used as a checklist during your development process to ensure the highest possible UI consistency. It is not by any means a full and exhaustive list of all UI issues, but merely as a guide for MMC development. Information here is of a smaller granularity than that which appeared above in the document. Refer to the appropriate sections above for a fuller explanation.
| DONE | ISSUE | SOLUTION |
| Tasks | Individual tasks do not belong. | |
| Containers | Grouping containers for applications and other containers. | |
| Objects | Place configurable objects in the tree. | |
| Leaf nodes | Don’t want hundreds of child nodes in the scope pane. Make those leaf nodes, so that they only show up in the results pane. | |
| Node naming | Be precise and unique. | |
| Viewable nodes | Use sparingly due to the possibility of obscuring children of that node. | |
| Results pane | Use standard views when possible. | |
| Custom OCX in Results Pane | Use with caution. This will involve more work, and you will need to implement extra interfaces. No provided UI help. | |
| Web pages | Documentation and Web pages can be placed in the namespace, but should be separate from the objects and object containers. Same for Web pages that act as Task Pads. |
| DONE | ISSUE | SOLUTION |
| Size | 252 wide by 218 high dialog units. | |
| Title | The title on the property sheet is provided by the primary snap-in that creates it and should be of the form “Object Properties” (where object is replaced by the name of the particular object, of course). | |
| Common buttons | Place OK, Cancel, and Apply buttons outside the tab boxes. |
| DONE | ISSUE | SOLUTION |
| Context menu | On the top level should be frequently used selections, and should be the same buttons that you have on your toolbar. The New cascade is for creation of objects added to the namespace. The Task cascade is for everything else. | |
| View menu | The snap-in has the opportunity to disable or hide any of the default menu selections. Add selections that you need. The view menu is for altering what shows up in the results pane. It may be for filtering from the same data set or for showing a different data set. | |
| Context | Remove menu items if not appropriate for the current context. | |
| Common commands | Don’t duplicate those that MMC already provides. | |
| Additional cascades | Avoid cascading menus if possible. |
| DONE | ISSUE | SOLUTION |
| Custom command bar style dropdown menu | This should be used in with extreme caution. It is always a good idea to minimize the amount of UI the user can interact with. | |
| Command states: Enabled | Disabled | Hidden |
Each of these commands can be in one of three states: enabled, disabled, and hidden. If a snap-in will ever use one of the common commands when a particular objects is selected, then that command should be shown as either enabled or disabled. It is only when a particular command will never apply to a given object that that command should be hidden. | |
| Frequently-used commands | You should display toolbar buttons for your snap-in's top 1-5 most frequently used commands in any given context. | |
| Group similar commands | It may be preferable to provide several small bands of related functions rather than one large band. You may add separators within each band to group similar buttons. | |
| Common commands | Don’t duplicate those that MMC already provides. | |
| Context | Remove buttons if not appropriate for the current context. Do not just disable (gray) them. | |
| Button Commands and top level Context Menu are same | The snap-ins toolbar buttons and the commands on the top level of the context menu for a particular node should be the same. |
| DONE | ISSUE | SOLUTION |
| Appropriate user focus | End-user is the novice type. Gives an introduction to the tool. Ease the burden of the hierarchy traversal. | |
| Appropriate content | Common tasks. Launching place for scripts, wizards and snap-in commands. Can be used as a “getting started” introduction to tool. | |
| Menu selection | Task pads are stored and accessed as a view on a particular node, user accesses taskpad via the View menu. |
| DONE | ISSUE | SOLUTION |
| Wizards | Wizard97 look and feel. Refer to documentation in the platform SDK. | |
| Description Band | It is particularly suited to the following. For status information that the primary snap-in provides . Information that requires visibility by the user but does not warrant a message box. Information which requires some degree of persistence, at least until the user navigates elsewhere in the interface. For example: (1) For a filtered view: “Filtered View: 1 of 345 items displayed,” and (2) see Windows Explorer. | |
| Load failures | snap-ins requiring logins that may fail should not expand the node. Keep a menu selection to re-attempt a login. | |
| Icons | Use standard Icons. Icons for open state of containers are not always necessary. Provide an icon change for states like offline, warning. | |
| About Box | Provide version number and description information for customers to identify. | |
| Double click | If in the results pane on an object, double click performs the default action. | |
| Help | Use HTMLHelp for main help topics. Accessed via parent window Help menu. | |
| Keyboard access | All menu commands and dialogs need to be designed for keyboard use. |
| DONE | ISSUE | SOLUTION |
| Namespace | Be unique and consistent in node naming. | |
| Menus | Be unique and consistent in command wording. | |
| Toolbars | Don’t duplicate commands. | |
| Property sheets | Consider the state of what you are extending. Use same style and size. |