Share via


Designing the Project Guide User Interface

There are two types of Project Guides for Microsoft® Office Project 2003: single-page guides and wizards. As implied, a single-page guide consists of one pane which helps the user accomplish the task. A wizard consists of a set of sequential pages that guide the user through the task. The following list shows the required and optional user interface elements for each Project Guide page.

  • Task name (required)
  • Guide title (required)
  • Text (required)
  • Done link (required)
  • Associated view (required)
  • Section headings (optional)
  • Graphics (optional)
  • Controls (optional)
    • Radio Buttons
    • Drop-Down List Boxes or Combo Boxes
    • Links to dialog boxes
    • Links to other Project Guides
    • Hints, More Information links, and Help links

Task Name

Required. The task name appears in the task list that is displayed when the user clicks a goal in the Project Guide toolbar. You need to specify the goal under which the task appears. Use sentence capitalization (only the first word is capitalized).

The list of tasks in the top-level Project Guide for the goal area is the same as the list in the drop-down menu for that goal in the Project Guide toolbar. For example, the following figure shows the top-level Project Guide side pane for the Tasks goal area.

Task names in the top-level Project Guide for a goal area

Task names in the top-level Project Guide for a goal area

Guide Title

Required. The guide title appears in the title bar of the Project Guide when the user selects the task. It is a shortened version of the full task name; each word in the title is capitalized. The guide title does not have to be the same as, or even a variation of, the longer task name, but should be related to the task name. For example, the following figure shows the guide title for the task Define general working times is Project Working Times.

The guide title is a shortened or related version of the task name

The guide title is a shortened or related version of the task name

Text

Required. All Project Guides include some text that contains concise instructions for accomplishing the task and may also contain critical domain or product information. Write text in an informal, friendly (but not cute) style. Remember, many users don't read long explanations, so keep the text blocks as short as possible.

You should expect to revise the text after you or the developer creates the Project Guide code, because it is difficult to judge how the text will look in the finished page. Usually, the text has to be revised several times. The most effective way to revise the text is to sit down with the developer and a user interface expert or a technical writer and walk through the text online.

You have a lot of flexibility when it comes to text. Feel free to use sentence fragments. If the users can and will see an element in the user interface for themselves, you don't need to spell it out. Instead, point out the less obvious but critical things that users might miss. The following figure shows examples of concise text information.

Keep text short for accessible Project Guides

Keep text short for accessible Project Guides

Use the following additional guidelines for text:

  • Generally, introduce the guide with a paragraph that does one or a combination of the following: clarifies why/when the user might need to do the task, or provides immediate directions for doing or starting to do the task.

  • When you instruct the user to do something, use sentence structures such as the following:

    "To [do this], [take this action]." For example, "To start, click on the link below."

    "Do you want to:" [followed by a set of radio buttons]

  • When you instruct the user to do something in the associated view, use the following phrasing:

    "To the right, [take this action]." For example, "To the right, type the names of people in your project."

    "On the right, [take this action]" or, "[Take this action] on the right." For example, "Select a task on the right."

  • When instructing users to do something in a dialog box, use the phrasing "In the [title of] dialog box on the right, ..."

Required. If the Project Guide is a single page, the Done link must be either on the bottom of that page or above a More Information link. If the Project Guide is a multi-page wizard, the Done link must be on the last page of the wizard.

The Done link can go to the next step in the goal area or return to the main Project Guide for the goal area. In the case of a More Information page or a subtask, the Done link should go back to the previous task page.

Associated View

Required. Project Guide goals, tasks, and views work together. That is:

  • Each task has a default view associated with it. When the user selects the task, Project displays the default view in the main view area.
  • A view can have a default goal area associated with it. When the user chooses the view, the default goal area appears in the side pane if the Project Guide is visible.
  • Each Project Guide task has a default view associated with it. These default views can be standard or modified versions of Project views. For example, when the user chooses the task Specify people and equipment for the project, a modified version of the Resource Sheet appears. It contains fewer columns and a different column order than the standard Resource Sheet.

For any new tasks you create, you need to evaluate both the standard Project views and the modified views available for Project Guide tasks. Then you can pick one of the existing views, or pick a view and modify it to meet your needs. In some cases, the view is not a critical factor, because the user will be interacting with a dialog box to accomplish the task. Where it is critical, it's important that you choose/create a view that is optimized for your task. The Project Guides should simplify the user interface and help the user focus on the task at hand. On the other hand, you have to balance the need to keep the number of views as low as possible so the user does not have to learn a new user interface. So, if one of the already simplified Project Guide views works for you (it's 80-90% of the way there), you should use that view instead of creating a new one.

Be sure to list which views the task can be used with, so the code operates correctly when the user chooses a view that the task does not work with.

Section Headings

Optional. If the Project Guide provides access to two tasks, you can break up the tasks with headings. A heading uses sentence capitalization and has a line under it, as in the following figure.

Use underlined headings for multiple tasks in one page

Use underlined headings for multiple tasks in one page

If the task requires two or more distinct steps (aside from the step of selecting a task/resource/assignment in the associated view), you can clarify the steps with numbered headings as shown in the following figure. Like other headings, steps use sentence capitalization. There is also a line under each step.

Use numbered headings for steps in a task

Use numbered headings for steps in a task

Graphics

Optional. You can use graphic images in your guides, but be careful. Screen-shot style graphics are difficult to localize, and space is at a premium in Project Guide side panes. So, use graphics sparingly and only when they add real value or are necessary to clarify something.

Testing of the early Project Guide prototypes showed that users are confused by graphics of user interface elements. Where graphics of buttons appear in the guides, users either thought they should be able to click them or didn't realize they could click them. They did not realize that they were being told to look in the user interface for a button that looked like the graphic and then click that. Therefore, only include button graphics if you are going to make them actionable controls.

The following figure shows both an explanatory graphic and how button graphics should be used.

Example of how to use explanatory and button graphics

Example of how to use explanatory and button graphics

For example, to insert a new row, the user clicks the graphic that the text points to in the side pane. Use these guidelines for clickable button graphics:

  • Place each button on a separate line.
  • Use a graphical arrow to point to the button.
  • Write text instructions next to the arrow in this format: "Click here to [take this action]."

Note  The following object is considered a control, and so does not follow the guidelines for graphical buttons. Control object, not a graphical button

Controls

Optional, but strongly suggested. If your guide only contains text, controls are of questionable value. You should provide actions the user can take in the guide to accomplish the task. You can use any control that can be implemented technically, fits in the guide, is understandable by the user, and supports your task. Some Project Guides use controls in unconventional ways. However, for a control to be easily understandable, you should use it in a commonly understood way. Following are guidelines for how to use the common radio button and list box controls.

Radio Buttons

Radio buttons are extensively used in the Project Guides in two ways:

  • The traditional usage allows the user to choose one option in a set of options.
  • Radio buttons are also used as a navigation method within a Project Guide, allowing the user to choose a particular path to accomplish the task or a portion of the task.

The first method is obvious, the second can be less so. That is, use radio buttons whenever you need to display a different set of text or controls depending upon what the user wants to do or what method he/she wants to use. If you give the user a choice of how to accomplish the task or of specific subtasks the user can choose to do, precede the choices with the prompt, "Do you want to ...". The following figure shows examples.

Examples for the use of radio buttons as a navigation method

Examples for the use of radio buttons as a navigation method

You should also use radio buttons anytime you want to display different sets of text or controls that depend on what the user wants to do. In those cases, you don't necessarily need to use the "Do you want to..." prompt. If you don't, make sure that the combination of introductory text, your radio button text, or hints clearly identifies the choices and any ramifications. The following figure shows examples of this use of radio buttons.

Examples for the use of radio buttons to shows different sets of information

Examples for the use of radio buttons to show different sets of information

In this case, the user can decide which list of fields to look at, and insert from, by selecting one of the radio buttons. The text and controls change appropriately.

Use drop-down list boxes or combo boxes where appropriate to allow the user to choose an item from a long list of items. An example of their use is in the Project Guide for the task Select a view or report.

Example of the use of a list box in a Project Guide

Example of the use of a list box in a Project Guide

Note the excellent use of descriptive text below the list box, which displays a description of each view that has the focus. The Apply this View button is below the description. This structure gives the user the option of scanning the available views, and mimics an OK button that the user has to click to finalize a selection.

Use links to bring up dialog boxes or other user interface components that the user interacts with to complete the task. Introduce the link with a paragraph. Generally, the link should appear on its own line following the paragraph. If space is an issue, you can word the paragraph to include the link as part of the text. The following figure shows the Project Guide for the task Link to or attach more resource information, where the link Add a note in the side pane brings up the Notes tab in the Resource Information dialog box.

The link 'Add a note' brings up the Notes tab of the Resource Information dialog box

The link Add a note brings up the Notes tab in the Resource Information dialog box

You can use links to other project guides when they provide valuable additional information or to connect to a required project guide. You can include the link on its own line and precede it with a paragraph, or include the link as text in a paragraph. The following figure shows an example.

Example of one Project Guide that links to another Project Guide

Example of one Project Guide that links to another Project Guide

As previously discussed, you can rank information in order of priority: absolutely critical to completing the task; important or may be necessary for completing the task; useful supporting information or closely related tasks the user may want to do. Critical information is always on the primary Project Guide pane. Use the following kinds of controls or links to display noncritical information.

Hints   Hints appear as a light-bulb icon. When clicked, the hint text appears as stretch-text (the content below the light bulb shifts down and the hint text appears in its place). Clicking the icon again hides the text. Use hints to provide a small paragraph of text that may be critical to a certain subset of users, to clarify a concept that is key to understanding the instructions, or to otherwise provide important information.

More Information   This type of link appears as a balloon icon that contains a question mark, followed by the link text More information, or a short description of the information. When the user clicks the icon or the link, the current guide is replaced with the More Information guide. The More Information guide consists of a title that describes the topic covered, text or graphics that provide the additional information, and (optionally) links to help topics.

Use links for more information when you need to provide more than a paragraph of important information. You might use the link if some set of users may need more information, if a concept needs to be clarified, if the user may need more information in order to understand how to complete the task in the primary guide, or if you want to provide information with links to additional, related Help topics. The following figure shows a More Information guide for the link Entering Material Resources.

Link to a 'More Information' Project Guide

Link to a More Information Project Guide

Help Links   A Help link appears as a traditional Help icon (a book with a question mark on the cover), followed by the title of the Help topic that the link goes to. Help links only appear in More Information guides; they do not appear on primary guide pages. This positioning gives the user the information he or she needs as close to the task as possible. The help topic appears in another window, which interrupts the user from the task at hand. Therefore, you should attempt to provide the information the user is most likely to need in the More Information guide, and link to additional topics from there if necessary.

After you have created a satisfactory design for a custom Project Guide side pane, the next step is building it. For more information, see Side Panes.