OSP.2_5.UIReview.Add&Review Matrix

Introduction

A user who has permission to "Create" or "Edit" matrices can get to this page by clicking the "Add" link from the "Manage Matrices" page or "Revise Properties" link from the "Matrix View" page.

Tasks

A matrix author can describe a new matrix or revise the properties of a matrix from this page. The properties of a matrix include:

• The TITLE of the matrix
• A DESCRIPTION of the matrix
• The css STYLE that will be used to render the matrix.
• The LABEL NAMES for Rows and Columns.
• The names of the COLUMNS and ROWS of the matrix.
• The workflow PROGRESSION end users will work through when completing the matrix.
• The MATRIX STATUS COLORS to be used when rendering the matrix.

Page Features

The main feature of this page a single, large, ungrouped form with all of the different types of inputs in it. Some of the form elements (style, row and column) have links to helper tools. Others (Matrix Status Colors) provide popup widgets for the user to use to select values for the input.
Required fields have an asterisk to the left of the input label.
Some effort has been made to label the parts of the form with header (h4) elements.

Common Errors

• Submitting a form that does not have all of the necessary fields completed.

Recommendations

orange: Gonzalo Silverio

OK= yes, makes total sense, do not see need to discuss more

???= not sure what this means, have some questions

scaffolding\addScaffolding.jsp

Some mechanical notes:

1. col/row color - "not set" means "background not set"
2. out col/row color in its own col.
3. table width - control better
4. matrix Progression - omit instruction message - incorporate in header
5. rteditor funky
6. Fist column/First row  unclear

Error prevention and handling

• The current "required" fields include the Title and the Matrix Status Colors. However, submitting the form is accepted without specifying any Matrix Status Colors (presumably, default values are used, but not displayed in the form). Either:
  • remove the "required" indicator from the Matrix Status Colors input elements OR
  • display the default values in the form element(gsilver) OK - done. Not required, text changed to "default color"
• If the author submits the form without having specified a ROW or COLUMN, the form does not validate and displays "Required" errors near each of those fields. The ROW and COLUMN fields should be indicated as "required" with an asterisk.
• (gsilver) OK - done
• When a submitted form is not valid, the invalid fields are flagged with a red "! required" error above the required fields. It isn't clear what was required. Was it the field above or below the error? This error should appear to the left of the required field's label to eliminate confusion. (see /wiki/spaces/DESPAT/pages/21109243916)
• (gsilver) OK - done. Highlight the label, display required alert to the right of the peccant element.

Semantics

• When there are no rows or columns created for the matrix, the form includes a header of a table without any table rows. Rather thyan displaying the table without any rows, display the message "This matrix has no rows. All matrices must have have at least one row. Create a row." or "This matrix has no columns. All matrices must have have at least one column. Create a column." as a prompt to create one.
• (gsilver) OK - done
• It seems that an unlimited amount of text can be designated as a row or column name. Limit the length of the field to something reasonable. Longer descriptions could be handled with the glossary.
• (gsilver) OK! I think this is a great idea. But I wonder if everyone feels the same ??? - taking away functionality is bound to step on someone's toes.
• When implemented, matrix users have the ability to add/attach/edit/delete "items" that are related to matrix cells. The use of the term "items" is very generic and would likely not resonate with the users of the matrix. Some schools might refer to these "items" as "Learning artifacts", "Evidence" or some other locally meaningful phrase. This needs to be configurable for each matrix. As such, we need a placeholder in this form to designate that "Item descriptor".
  

  (see OSP.2_5.UIReview.Matrix Cell View#Semantics)

  (gsilver) OK - but this issue does not crop up in this view does it? OIC:  you are proposing a control to set a "term" that in the cells will be used to refer to "items" - great idea - lets do it in 2.6
  

Syntactic elements

• When the color settings for a specific row or column are left at defaults, the preview of the color scheme shows a vertically striped image overlaid by the text "not set". This is both hard to read and confusing. It would be much more clear to either:
  • include the default color scheme with the word "default", much like the word "sample" appears within user selected colors.
  • display the row or column name using the selected color scheme
• OK - done

Syntactic Elements

Form grouping

It seems that there are 4 types of information in this form:

• "Front Matter"
  • TITLE
  • DESCRIPTION
  • Item descriptor - defaults to "Items"
• Colors and Style
  • Style
  • Matrix Status Colors
• Matrix Structure
  • Row and Column LABELS
  • Names of ROWS
  • Names of COLUMNS
• Workflow
  • Matrix Progression

The form should be rearranged to reflect the grouping and each of these groups should be surrounded with a FIELDSET element to chunk the form up into manageable sections. Eliminate the header elements and use the LEGEND element inside of the fieldset to label the parts of the form. Apply some css to the fieldset and legend elements to provide some separation between sections and break up the form for the user.
Perhaps css could be used to further breakup the form into a tabbed page/form that shows only one section at a time. See A List Apart: Let them eat Cake

(gsilver) OK - nice breakdown. Will use your categories and fieldsets. A tabbed panel might be a good idea - but since there are so many external links (add a col/row, color, etc.) the navigation rules are going to be the dickens. This tabbed panel idea needs some more thought - for 2.6, I think

Right-Left Alignment

Align the form labels to the right and the form inputs to the left (including the rich text editor) (see /wiki/spaces/DESPAT/pages/21109243897)

(gsilver) This is not a design pattern, but an opinion. As such it is optional. Any institution that wants to do so can do so via the CSS *everywhere*

Duplication of Forms elements in the menu bar

• There are "Add Row" and "Add Column" links at the top of the tool in the navIntraTool tool bar at the top of the page. I am not sure why these elements are included up there. None of the other form inputs are displayed. I would eliminate them.
• (gsilver) OK- done - eliminated tool bar all told

Extras on demand

Rather than taking the user out of the form to a helper tool when adding rows and columns, add a small additional piece of the form to allow the user to input the new information on the same page (see /wiki/spaces/DESPAT/pages/21109243905).

(gsilver) Probably 2.6