2.4 Requirements
Contents
- Forward compatibility
- Integrate Goal Management Tool
- UI rework/refinement
- Documentation & Sample data structures
- Improve authoring flexibility
- Reports
- Builders for the hard to create xsd, xsl, css, xhtml files
- Portal
Forward compatibility
( All )
No changes that require difficult migration. The project team is making a commitment to building all migration scripts for a seamless upgrade from 2.2.x.
Integrate Goal Management Tool
(see OSP-24-REQ-GMT to edit)
(Syracuse / rSmart)
Id |
OSP-GMT-01 - Refactor rating scale configuration. |
Jira Items |
|
History |
Jan 8 2007: Created |
Description |
Refactor configuration of rating scales. This is currently part of the assigments tool and must be moved/refactored for inclusion in 2.4. Move this to the goal management tool placement. |
Actors |
Goal management tool administrators |
Steps |
|
Id |
OSP-GMT-02 - Develop linking ability between a wizard page and goals in the GMT. |
Jira Items |
|
History |
Nov 28 2006: Created |
Description |
As of OSP 2.3, the contrib Goal Management tool is not integrated with OSP matrices or wizards. |
Actors |
Wizard page/matrix cell authors |
Steps |
|
UI rework/refinement
(see OSP-24-REQ-UI to edit)
Responsible: (U Michigan / ASU)
Focus on making the user experience more integrated and cohesive by assessing current user workflows, reducing clicks, potentially reducing tools, increasing UI consistency between tools,and making language consistent.
ui-usecases1-7.doc
Key to estimates:
- small = one day or less
- medium = one week or less
- large = more than one week
Type I
Minor UI changes to JSP, JSF, transformation that do not require Java development.
Id |
OSP-UI-01 - Displaying description and instructions from xsd in the form when form is being filled out. |
JIRA Tasks |
|
Status |
lead: rSmart |
History |
Nov 16 2006: Created |
Description |
The form xsd contains a node locale (<xs:documentation source="ospi.description" />) for instructions associated with an element (a label/input pair) but this is not available to user when form is being filled out. This forces form creators to overload the label with instructions, to the detriment of the form's legibility. |
Actors |
The resources tool |
Steps |
When the tools displays the HTML edit form to fill out a form for each item in the form definition that has an associated description that description should be rendered |
Issues |
Made "ospi.description render as an extended tooltip. Also added processing for new node <xs:documentation source="ospi.inlinedescription" /> that will render as a bit of inline text associated with the element. Since the form render is via a transformation that can be customized, these two choices should be useful and can be changed as needed. |
Id |
OSP-UI-03 - Resolve issues with forms not rendering properly where fields move off to the right of the screen, especially when there are hierarchical elements of the form. |
JIRA Tasks |
|
Status |
completed - issues detailed below addressed in separate JIRA default tickets |
History |
Nov 16 2006: Created |
Description |
Failure on validation (ie. forget to fill in a required field) wipes out data. |
Assumptions |
Forms and Resources tool will continue to be integrated |
Actors |
Users filling out forms. |
Steps |
User fills out form - either from Matrix or from Resource |
Variations |
See associated wire frames |
Issues |
First pass done. Remaining issues:
|
Id |
OSP-UI-04 - The resources tool should display the form type in the list view of resources as a new column, or a mouse over, or an icon type. The form type should be recognized by Sakai as a valid file type. |
JIRA Tasks |
|
Status |
UM: pending completion of the release of new resources tool functionality |
History |
Nov 16 2006: Created |
Description |
Form type (ie. "Personal Information") needs to be displayed at least in two places: in the Resources list and in the Form title. |
Assumptions |
Forms and Resources tool will continue to be integrated |
Actors |
The resources tool |
Steps |
From Matrix or Resource, create new form, view same in Resources list context |
Variations |
See associated wire frames wf-osp-ui-04.pdf |
Issues |
In list hspace is at a premium; could use a mouse over text for the form type. |
Type II
Minor changes in the underlying logic that require Java expertise.
Id |
OSP-UI-07 - Define and implement a folder structure for forms like feedback, evaluations, and reflections created as a part of a wizard. These forms should be automatically stored in the author's resources, in a folder patterned like: "portfolio-interaction"/site/wizard name/type where type is either "Reflections", "Evaluations", or "Feedback." |
JIRA Tasks |
|
Status |
lead: IU |
History |
Nov 20 2006: Created |
Description |
Define and implement a folder structure for forms like feedback, evaluations, and reflections created as a part of a wizard. These forms should be automatically stored in the author's resources, in a folder patterned like: "portfolio-interaction"/// where type is either "Reflections", "Evaluations", or "Feedback." This is a means of improving the storing of Feedback, Evaluation and Review forms (fer-forms) in the resources area of the user My Workspace in such a way that the root area of the resources does not get cluttered with forms. The forms are saved in a patterned folder structure and are named by use case OSP-UI-09 |
Assumptions |
The page that the form is added to belongs to a published matrix. |
Actors |
Users that have 'use' permission on the wizard (students) |
Steps |
|
Variations |
#5b: if the folder exists no operation is performed |
Issues |
1. We need feedback on what the best option is for the folder structure adnd form name. |
Id |
OSP-UI-08 - Add a property to a form in the form tool to specify that this form is a 'hidden' form. 'Hidden' forms show up in wizards but not in resources tool. |
JIRA Tasks |
|
Status |
lead: rSmart |
History |
Nov 20 2006: Created |
Description |
Add a property to a form in the form tool to specify that this form is a 'hidden' form. 'Hidden' forms show up in wizards but not in resources tool. |
Assumptions |
|
Actors |
Form creators |
Steps |
|
Id |
OSP-UI-09 - Define and implement an auto-naming scheme that simplifies the creation and storage of forms that have been completed by the end user, including reflections, evaluations, and feedback forms from wizards. |
JIRA Tasks |
|
Status |
lead: IU |
History |
Nov 20 2006: Created |
Description |
Define and implement an auto-naming scheme that simplifies the creation and storage of forms that have been
|
Assumptions |
These assumtions apply to the resources tool: |
Actors |
Wizard Tool |
Steps |
|
Issues |
Row and Column names and Wizard Page Names may be very long, how should we deal with that? Suggestion: take a number of characters |
Id |
OSP-UI-10 - Make the ability to preview portfolios more intuitive. For example, clicking "finish" to complete a portfolio and then having to click on the portfolio name is not a user-friendly way to preview a portfolio. |
JIRA Tasks |
|
Status |
ASU* |
History |
Nov 20 2006: Created |
Description |
Make the ability to preview portfolios more intuitive. To preview a portfolio now, the user needs to click "finish" to complete |
Id |
OSP-UI-11 - Matrix cells form/feedback relationship needs to be expressly stated |
JIRA Tasks |
|
Status |
UM High Priority |
History |
Nov 20 2006: Created |
Description |
Presently feedback is global when added to a matrix cell. Feedback should be either global or related to a particular form entry. So: |
Type III
Changes in underlying logic with framework implications or a need for the interaction of multiple tools.
Id |
OSP-UI-13 - form entry form optimisation: Change the UI for completing a form so that the "resources" parts are more clear. Move the "title" and "description" to the top and change "title" to "save as". Remove the "access", "copyright", "meta-data", and "groups". Configure Sakai properties as the means for determining whether or not to include these fields. The default should be to hide the properties. If they are shown, they should appear below the rest of the form. |
JIRA Tasks |
|
Status |
a. dependent on Resources tool rework, See Resource Design Meeting Minutes for more details |
History |
Nov 20 2006: Created |
Description |
See osp-form-flowv2.pdf for some possible designs for this workflow.
|
Note |
thanks to - SAK-7030Getting issue details... STATUS the forms are independent from the Resources tool UI. Most of the issues detailed here are moot. Some that are not: use of metadata in forms - needed? if so which metadata items are pertinent? see above Description |
Type IV
Existing bugs and tasks already in Jira.
Id |
OSP-UI-19 - Resolve/merge the following Jira's: SAK-6947(guest comment) , SAK-5852 (forms reset) |
JIRA Tasks |
|
Status |
lead: UM/rSmart |
Description: |
see JIRA for details |
Documentation & Sample data structures
(see OSP-24-REQ-DOC to edit)
(IU / rSmart / Michigan/ UVA / Syracuse) Lead Contact: Melissa Peet
Documentation should include a map and description of how all the tools work together.
User Documentation
IU will be contributing KB text articles, as well as short Flash videos created with Captivate. This documentation will be for both users, i.e. students, and authors.
rSmart, in partnership with Charles Sturt University of Australia, will contribute a map and description of how all the tools work together, including simple 'start here' cookbook and docs on how to construct the various interrelated data structures. This will include the following:
- sample interrelating sets of data structures with examples of populated forms, wizards, and portfolios for a variety of portfolio purposes - accreditation, self presentation, integrative learning, project portfolios.
- documentation on the workflow for creating and using the data structures.
Authoring Documentation
IU will be contributing KB text articles, as well as short Flash videos created with Captivate. This documentation will be for both users, i.e. students, and authors.
Library of Sample structures
This would include forms, wizards, etc.
- By April 1, 2007: rSmart ,on behalf of Charles Sturt University, will provide a foundation for a library on Sakaiportfolio tools. This documentation will reflect the current state of the Sakai portfolio tools in a structure that allows for change and expansion as the tool set evolves.
- Beyond April 1, 2007: Other members of the community will participate in updating and adding to the materials as the tool set evolves
Idea to Implementation Documentation
rSmart in partnership with Charles Sturt University, (with additional contributions from the University of Michigan) will make a significant contribution to this area. Wende Morgaine will also make contributions. Because so much of the work it takes to run OSP is conceptual, documentiion for the entire "idea to implementation" process must be provided. This large area of documentation includes everything from how to determine goals for the matrix and types of measurement for the columns, to how to craft reflection questions, minimize data migration problems, and identify the best pedagogical approaches to boost adoption of OSP,
Specific rSmart contributions will include:
1. a very high-level answer to the question, "What can you do with Sakai's suite of portfolio tools?"
2. a very high-level answer to the question, "What are some of the more common uses of wizards, matrices, and portfolios?" focusing primarily on uses for these suites of data structures that have widespread applicability: personal portfolios, portfolios to guide teaching and learning, and portfolios for institutional assessment and accreditation. As needed to ensure understanding, these docs will explain the context in which these items might be created and their intended value. For each of these areas, the following will be provided:
- A List and name the elements needed (e.g., three forms with the following fields, one matrix or wizard, one presentation template, etc).
- a high-level workflow that indicates who does what when to create the structures and participate in their use throughout the life cycle of the sample
- A view of the final product as seen by participants and remind readers of the intended audience and application.
Becoming a Community Participant
Many newbies to the OSP and Sakai communities have commented on how hard it is to get involved. When you come in cold, you don't even know to join the mailing list. Once you know it exists, you don't know where to find it. The same can be said of confluence. The information the public gets about OSP needs to be calibrated to the newbie and needs to be accessible to them if adoption is going to increase.
Improve authoring flexibility
(see OSP-24-REQ-AUTH to edit)
( U Michigan / rSmart )
Improve ability to edit and completely delete data structures (forms, wizards, portfolios) once created and published. Rethink the immutable design of published data structures and when it makes sense to allow changes in them, i.e., should it be possible to add pages to a wizard once it is already in use?
References:
- Documentation on Matrix Wizard Mutability
Key to estimates:
- small = one day or less
- medium = one week or less
- large = more than one week
Id |
OSP-WF-01 - Adding Rows and Columns |
JIRA |
|
Status |
lead: UM |
Description |
In a published matrix:
|
Id |
OSP-WF-02 - Removing Columns and Rows |
JIRA |
|
Status |
lead: UM |
Description |
In a published matrix when no participant has added items or reflections to a page:
|
Id |
OSP-WF-03 - Changing the forms in a page |
JIRA |
|
Status |
lead: UM |
Description |
|
ID |
OSP-WF-04 - Add more flexibility when editting forms |
JIRA |
|
Status |
sak-8591 scheduled for 2.4 |
Id |
OSP-WF-05 - Being able to test (preview) a matrix and wizard |
JIRA |
|
Status |
lead: UM |
Description |
A matrix designer has the need to test matrix before publishing. This could be part of the preview mode. Besides the status published, unpublished there would be a status named preview. In the status anyone with the appropriate permission can use and/or revise the matrix. On publishing the matrix all data is removed. |
Id |
OSP-WF-06 - An author will be able to delete a published matrix (and wizard) |
JIRA |
|
Status |
lead: UM |
Description |
If a designer needs to make more extensive changes than allowed by these rules, a new matrix may need to be designed and an existing matrix deleted. |
Reports
(see OSP-24-REQ-RPT to edit)
(rSmart / Syracuse)
OSP-24-RPT-01 - Create library of report templates for data from OSP tools. These will be delivered with the documentation, tentatively by the end of March.
- OSP Report Template Library, including reports on data from forms, wizards, and portfolios.
- Sakai Report Template Library, including reports on data from assignments and other Sakai tools. (out of scope for OSP)
- Usage Report Template Library, including reports on user activity, storage, and file types. (out of scope for Sakai 2.4)
OSP-24-RPT-02 - Clear documentation for the creation of report templates
DBA/XML/XSLT developers need clear documentation for the development of reports based on user requests.
- Use cases to determine report parameters, fields, and layouts and allow developers to easily create report templates
- Information on how to specify which roles can run reports on all sites or only sites in which they have membership.
Documentation requirements for the OSP Report tool.
The documentation for the OSP 2.4 report tool will provide step by step instructions for 3 audiences:
- End users (Program Coordinators, faculty, deans, system administrators) that may want to request and view reports
- This section will inform end users about what the report tool is capable of doing, its limitations and strengths and how it fits in with other OSP/Sakai tools.
- This section will help a non-technical user to be able to be able to articulate their needs to a Report Developer, including:
- what data they want to include in the report
- the display format for the data
- how often the report should be run and by whom
- access, dissemination and publication requirements for the report results
- Report developers (XML developers and/or DBA's)
- This section will document:
- Some ethics and privacy concerns to be considered
- Steps and files needed for a "Hello World" report, including:
- Reports configuration and definition files (or whatever they are going to be in 2.4)
- Report results files
- XSL files for the desired format
- Implementation
- This section will document:
- System Administrators and IT managers
- This section will contain:
- Some ethics and privacy concerns to be considered
- Time estimates and staffing suggestions for tool use
- This section will contain:
OSP-24-RPT-03 - Report templates
- Development of functionality within the reports tool to allow the creation of report templates using .xml and .xsl for users to use in running reports.
- Creation of new report templates will not require direct access to the server or a server restart.
- Users with permission can sort the list of report templates to locate appropriate reports to run.
- Users with permission can set query parameters through a user friendly interface.
- Reports will be goal aware allowing users to run reports of goals associated with various data structures.
OSP-24-RPT-04 - Intuitive interface to schedule and store reports
- A calendar tool will be created to facilitate setting the schedule for running reports.
- Documentation will be included for running reports and scheduling runs of reports.
- There will be designated folders for user create for the storage of reports.
OSP-24-RPT-05 - Share, publish, and disseminate report results
- Users with permission will be able to share reports with selected viewers via username, email address, public URL, or through the Resources tool.
- Users with permission will be able to export the report results (CSV, Excel, etc...)
- Users with permission will be able to view the results in various presentation formats.
"Builders" for the hard to create xsd, xsl, css, xhtml files.
(IU / U Michigan / ASU)
Create "Builders" for the hard to create xsd, xsl, css, xhtml files. In the short term, tools that enable faculty to build their own forms and their own custom presentations are also needed to reduce the bottleneck around programming staff.
Form Builder Phase 1
Build a user based form builder allowing authors (coordinators) the ability to generate forms. (No institutional data elements). XSD Weaver is being modified for Phase I.
XSD Weaver is now available from the Sakai Contrib space at https://source.sakaiproject.org/contrib/ucf/Xsdweaver/
Requirements brainstorming, voting, etc.
OSP Portal changes
Id |
*OSP-PL-01 - create a property to switch off the site tabs |
JIRA Tasks |
|
Status |
lead: rSmart |
History |
Feb 12 2007: Created |
Description |
this would allow the osp-portal to passthrough the sakai site tab code which would get rid of the site categorization. this could be turned off or on independently of the tool categories. |
Id |
*OSP-PL-02 - optionally load site type and tool category beans from the database |
JIRA Tasks |
|
Status |
lead: rSmart |
History |
Feb 12 2007: Created |
Description |
optionally read the tool category and site type info from the database. this will lead to eventually supporting dynamic changes of these settings. we may also be able to change this on a site by site basis, which would be a step in the direction of exposing this functionality to a site maintainer. |