Child pages
  • Wizards
Skip to end of metadata
Go to start of metadata

Overview

Wizards are new in OSP 2.1. They provide structure and guidance to inform the Portfolio Owner's experience. A Program Administrator or CIG Coordinator uses the Wizard Designer to create a Sequential, Hierarchy, or Matrix Wizard which the Portfolio Owner will then use to complete Forms, associate existing Forms and Files, Reflect, and receive Feedback and Evaluation. A Portfolio Owner will generally access Wizards in a particular CIG, however the Portfolio Owner may also create their own Wizards in their Personal Workspace.
Wizards contain pages which are presented to users. Each of the three types of Wizards (sequential, hierarchy, and matrix) has a unique way of organizing and presenting the pages, but pages in all Wizards are essentially the same. A Wizard Page can contain Guidance, Forms, Feedback, Evaluation, and Items which the Portfolio Owner has associated (Files and completed Forms). A Sequential Wizard presents pages in a linear sequence, a Hierarchy Wizard organizes pages into categories and sub-categories, while a Matrix organizes pages into cells which represent the intersection of a series of rows and columns.
Any user with the Reviewer role may provide Feedback to the Portfolio Owner for each page in a Wizard. Feedback is provided in the form of rich text. Evaluators explicitly assigned when the Wizard was designed, can use an Evaluation Form to evaluate the Portfolio Owner's work. Evaluation Forms can be consistent for an entire CIG, Wizard, or customized for each Wizard Page. When a Wizard Page is designed to include Evaluation, the Portfolio Owner is able to submit the page for evaluation. Once submitted, the page cannot be altered to ensure the integrity of the review.
All Wizards track Portfolio Owner activities such as start time, and status which can be used in Reports. The contents and attributes of Wizards may also be used in Portfolios to share them with other Portfolio Owners, Reviewers, and Guests.

Key Features by Role

Portfolio Owner

  • Views Wizard Instruction, Rationale, and Examples
  • Interacts with Wizard navigation to complete Wizard objectives:
    • Filling in Forms
    • Reflecting
    • Submitting for Evaluation
    • Creating Portfolios (* potential for 2.1)

Program Administrator / CIG Coordinator

  • Designs Wizards for Portfolio Owners to interact with
    • Select Forms
    • Select Style
    • Create Guidance (Instruction, Rationale, and Examples)
    • Sets other Wizard attributes as appropriate

Reviewer

  • Review's Portfolio Owner's work and provides rich text feedback

Evaluator

  • Uses Wizard's Evaluation Form to Evaluate Portfolio Owner's work
  • Browses Evaluation To-Do's
  • Submits Evaluation Forms

Sequential Wizard

A Sequential Wizard provides the Portfolio Owner simple navigation through a linear sequence of Wizard Pages. The Portfolio Owner is first presented with an introduction page that contains basic information like the title and description, and any Guidance placed on the introduction page. The Sequential Wizard presents a single page at a time to a Portfolio Owner, with navigation that allows movement forward and back, as well as skipping directly to any page in the sequence. Each page may present the Portfolio Owner with Guidance, Forms, Items, Feedback, and Evaluation.
Sequential Wizards deal with Evaluation on the Wizard as a whole, versus individual Wizard Pages. Therefore, if the Sequential Wizard is designed with Evaluation, the Wizard will have a submit step where the Portfolio Owner is expected to submit their work for Evaluation. Sequential Wizards may also have a 'create Portfolio' capability if the Wizard designer associated a Portfolio Template with the Wizard.

Hierarchy Wizard

A Hierarchy Wizard is an organizational structure for Wizard Pages which is presented to the Portfolio Owner like an outline. Each item in the outline may either be: 1) a category which contains other categories or pages; or 2) Wizard Pages which present Guidance, Forms, Items, Feedback, and Evaluation. CIG Coordinators and Program Administrators design the organization of categories, sub-categories, and pages to convey relationships among the information, and a navigational structure for Portfolio Owners using the Hierarchy Wizard. Portfolio Owners interacting with the Hierarchy Wizard use the outline to navigate between categories, and to Wizard Pages. Once on a page, the Portfolio Owner is presented with Guidance (if present), Forms to be completed, Items which she has already associated with the page, and any Feedback that has been given. The Portfolio Owner may create new Items from the Forms, edit or remove existing Items, and select Items from her Resources that match the required Form types.

Matrix Wizard

A Matrix Wizard is an organizational structure for Wizard Pages which is presented to the Portfolio Owner in a visual representation of rows and columns. The intersection of a row and column¿a cell¿is a Wizard Page which provides a point of interaction for the Portfolio Owner, Reviewers, and Evaluators. In general, the matrix provides a means of supporting longitudinal progression, with access to each Form determined by the completion of the Form that immediately precedes it. Navigation for a matrix may move horizontally across a row, vertically down a column, or independent of Form relationships within the Matrix. The specific workflow, as well as other attributes, is designed by a Program Administrator or CIG Coordinator.

  • No labels

1 Comment

  1. In the Hierarchy description the term 'category' should be replaced with the term 'level' to match terminology used within the OSP Requirements document.

    Throughout the document, the term 'wizard page' is referencing a concept that is defined as a 'form' in the OSP Requirements, and the term 'form' is referencing a concept defined as an 'element' within the OSP Requirements document.

    As the 2.1 release is implmenting a reduced set of functionality as defined by the OSP Requirements, the terminology may not be too much of an issue, but all should understand that later implementations and associated documentation should honor the work and resulting lexicon provided by the official OSP Requirements. Changes should be reflected first in the OSP Requirements based upon discussion through the OSP Requirements Workgroup and OSP Requirements Confluence space.