----

Part 1: Functional Description

---

Add Forms and Attachments to Main Wizard Page (1)

Summary (1)

Currently, the main page of a hierarchical wizard can contain a reflection, feedback, and evaluation form, but there are no options for including data collection forms and attachments on the main page.  The addition of these elements would increase the utility and usability of the wizard under certain circumstances.

In addition, to simplify the process of completing forms, we propose including options to:

• limit users to the creation of a single copy of each form
• suppress the display of the Select Form_name link

Rationale (1)

At IUPUI, we have some portfolio implementations that would benefit from the availability of data collection forms on the main page of a hierarchical wizard. In particular, wizards whose primary purpose are data collection for the purpose of outputting as a presentation would be much more intuitive and involve many fewer clicks if the forms were simply listed on the main page rather than placing each form on a separate page as is commonly done for resume and other similar wizard types.  In addition, we've encountered situations for a scaffolding consisting of a single page would provide the ideal solution. As an example, we would like to implement a wizard that allows students to give informed consent required by our institutional research board. We tried implementing within the existing functionality of the matrix and wizard and the process required so many clicks that we have resorted to a paper form.

Origin (1)

This enhancement was one of several wizard improvements suggested by IU in Reviewed Community Ideas for Future OSP Releases for reasons identified in the rationale above.  More recently, it surfaced as a solution to specific usability problems identified by Charles Hedrick (Rutgers) in his Observations on the OSP Interface.

User Stories (1)

The User Stories should paint a picture of what it is like for a user to make use of the enhancement. The actors should be based on real users with definable tasks and goals. Include as many stories as necessary to demonstrate how the enhancement would be used by different types of users.

Actors and Stakeholders

Actor: Coordinator
Actor: Participant

User Story 1:  Coordinator Creates One-Page Resumé Wizard

1. Coordinator creates a new hierarchical wizard designed to collect resumé data for output as a templated Presentation.
2. Coordinator adds a form for each data category(contact info, employment, education, skills, etc.) to the main wizard page.  The forms use subforms to handle multiple entries for each category.  To simplify the interface, the coordinator decides to hide the  Select Form_name link and allow each participant to create only one copy of each form.
3. Coordinator adds instructions for completing the resume, including generic instructions for adding, saving, and editing forms.
4. After the desired elements are added to the main page of the wizard, the coordinator clicks Continue to advance to add categories and pages or Finish to save as a single page wizard.
5. Coordinator publishes the wizard (Note that today it is not possible to publish a wizard that does not have at least one page in addition to the main page.)
   

User Story 2:  Participant Completes Resumé Wizard

1. Participant opens Resume wizard and reads instructions.
2. Participant clicks Add to complete and save the first form in the list.  H=She is now able to edit or delete the form, but he cannot add a second form of the same type.
3. Participant repeats step 2 for each form in the wizard.
4. Participants adds attachments (artifacts) to the main page of the wizard.
5. When the participant is finished, she clicks Return to Wizards to return to the Manage Wizards page.

Functional Details (may be added after community demo) (1)

Describe any functionality not fully captured in the User Stories.

• The following elements are added to Add/Edit Wizard: Step 2 of 3:
  • User Forms and Attachments section containing:
    • labels, guidance, and widgets for selecting forms
    • list of selected forms
    • 'Suppress Attachments' checkbox
  • The list of selected forms includes the following enhancements:
    • Revised formatting
    • Actions column for viewing and removing each form
    • Up and Down arrows for changing the relative position of each form
    • Allow Multiple checkbox - by default only one copy of each form can be saved by each participant.  Checking this box allows multiple copies per user.
    • Allow Existing checkbox - by default the Select Form_name ,link does not delay.  If it's important for users to be able to select saved copies of a form, this box can be checked.
• Depending on the Wizard settings, the following new items may or may not appear in the participant/reviewer/evaluator view of the main wizard page:
  • List of data collection forms with Add, Select, and Remove links (for participant)
  • Add Attachments link (for participants)
  • Add Feedback links (for reviewers)
• Wizards without pages can be published.
  

Interaction and Implications (1)

Identify and describe potential interactions with existing and planned OSP/Sakai tools and enhancements from a functional perspective.

Diagrams and Mockups (3)

Include any ERDs, flowcharts, sketches, mockups, etc.

Community Acceptance (4)

At the June 23rd OSP Conference Call, it was tentatively decided that the Add Forms and Attachments to Wizard Main Page proposal would be considered in lieu of this proposal's addition of forms to the main wizard page. However, the user interface changes were approved and very popular.

---

Part 2 of the Proposal for Enhancement Template: The Specification
The specification should be filled out once the feature is clearly defined.

---

Specification Template (5)

Behavior

Describe each specific behavior of the feature in the present tense as if the feature were implemented perfectly. Use precise, objective language to describe ideal behaviors against which actual behaviors can be evaluated.

In the case of conditions and behaviors that must be evaluated independently, they should be presented in a two-column table as below.

When there are workflow behaviors (steps) that must be evaluated in sequence, they should be identified with prerequisite conditions, behavior, and post-behavior conditions as below.

Workflow Steps

Interaction

List any entities or actors that are used or affected by this feature. Each should link to an entry in the OSP Terminology page.

Quality Metrics

Describe any non-functional requirements of the feature, such as usability, performance, or design. Provide objective and, where possible, quantitative measures against which actual implementations can be evaluated.

Assumptions

Provide any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.

Outstanding Issues

The Outstanding Issues section is a placeholder for the evolution of this specific feature. It should mention any explicit design or implementation decisions that are pending. There must be no outstanding decisions as of the confirmation of the feature as a requirement.