Child pages
  • Add Forms and Attachments User Interface Rework, Version 2
Skip to end of metadata
Go to start of metadata


Add Forms and Attachments User Interface Rework

Jira Number:


Related Jira Numbers:



Matrix, Wizard


Lynn Ward, Indiana University


13 July 2009

Demo Status and Date(s):

Status: (Suggested)
Date: (Date(s) enhancement demoed)

Demo Site


Part 1: Functional Description

Add Forms and Attachments User Interface Rework (1)

Summary (1)

The current layout of form and file objects (and associated metadata) in individual matrix cells and wizard pages is inconsistent and poorly aligned.  This proposal and the work completed in this area at Indiana University attempts to address this problem.  An earlier version of this proposal was reviewed and approved by the OSP community in June, 2008.

Rationale (1)

Origin (1)

This enhancement was suggested as part of a larger proposal for revising the look and functionality of the main page of hierarchical and sequential wizards.  In the end, the community chose to adopt Charles Hedrick's approach to adding forms to the wizard main page, but agreed that reworking the page layout of matrix cells and wizard pages was a worthy project.  The need to complete the work became more pressing at IU in 2009 when three different types of linked objects (assignments, wizard pages, matrix cells) began to appear in matrix cells).   With this additional data arose a need for consistent metadata about the origins, location, author, and last edit date of each object in the cell. 

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

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)

See design spec:  

Community Acceptance (4)

At the June 23rd, 2008 OSP Conference Call, it was tentatively decided that the Add Forms and Attachments to Wizard Main Page proposal would be considered in lieu of the proposal in which these changes were suggested. However, the user interface changes were approved as a separate project (pending available resources) 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)


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.



(Short description of mutually exclusive condition #1)

(Objective, verifiable behavior in response to condition #1)

(Short description of mutually exclusive condition #2)

(Objective, verifiable behavior in response to condition #2)

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

(Unique, short, representative name of the step)

Prerequisite Conditions or Step:

(Conditions or Step name)


(Objective, verifiable behavior)

Post-step Conditions or Next Step:

(Conditions or Step name)


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.


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.