UX Walkthrough pilots - Daphne, Clayton & Colin

Permissions matrix format is mostly consistent across tools.  Users can leverage learning in one tool for usage in others.

All tools > Permissions

CL

When adding participants to a site via their email address, the system checks for valid email address.  Protection against users entering the wrong address and not realizing it.

Worksite Setup & Site Info > Add participants

CL

Tool & content distinction pretty clear

While creating course, default of current semester is good - in most cases user won't have to move down in drop down.

WYSIWYG editor listens to common keyboard shortcuts

General

On initial view of system it is not clear why I see what I see (what role am I) and how that compares to what others see.  This is particularly important because of the hierarchical structure of a class and the need to protect students confidential information.

Visibility of system status

High

Display users role on every page.  Allow instructors to "see what students" see.  .

Recommendation for next step:  Component creation

All

"Role identifier" and/or "Student View"

Permissions settings are not human readable ( ex. "all.groups",  "new")

Match between system and real world - System should speak user's language

Permissions

Medium

Use terminology that matches user's mental model of the action.   The label should be in the "verb + noun" format.  For example, "new" in the Assignments Tool could be replaced with "create assignments".  Tool tips on the permission settings could add additional information if needed. 

Recommendation for next step:  Analysis of all permission matrix for consistency in language.  Customize terminology to each particular tool.

All

Permissions table is not clear.  It is not immediately clear is the row or column is the 'role'

Minimalist design

Permissions

Medium

If it's meant to be spreadsheet like then make it look more like a spreadsheet with gridlines and the such.
Recommendation for next step: Various visual and interaction design models should be reviewed to determine the best representation.  The redesign could become a component.  IMPORTANT:  The fact that the matrix is consistent is a positive so any changes should be made across the board.

All > Permissions

Permissions

If the user plays around with permissions, there is no way to get back to the default unless they remember.

Recognize rather than recall

High

Add a "revert to default" button (better terminology than default should be used)
Recommendation for next step:  Add above functionality to Sakai out-of-the box and/or include it in a permissions component

All > Permissions

Permissions

Gradebook

"Release assignment" is jargon -- not likely a term familiar to instructors.

Match between system and real world - System should speak user's language

Medium

New GB designs for 2.5 have a definition link built into several terms like this.  Term is always displayed clickable link that on click displays the definition. Need to confirm this was implemented with IU.  Not sure this is accessible. 

Recommendation for next steps: Use GB behavior as starting point to design and develop a "term definer" component.  Perhaps this could be more like a 'tool tip on demand'.

Gradebook

Term Definer

Home

"Worksite info" is not a familiar term to users.  It doesn't align with the idea that they are working in their Course site.

Match between system and real world - System should speak user's language

Home 

Medium

Rename to "Course site information".  The appropriate course type should be inserted for "course".

Recommendation for next steps:  Sakai community should change the language in the out-of-box version.

Home

Home

Arrangement of tools is inflexible and doesn't always match user needs.  For instance, new announements may be most important as deadlines approach yet they are buried below the fold.

User control & freedom

Low

Allow users to easily reorganize this page as appropriate for current situation

Page layout/organizer

Syllabus

If user has uploaded a pdf of their syllabus it displays as a link to the pdf rather than the contents displaying in-line on the page.  The users viewing the pdf are required to manage multiple windows since the pdf opens seperately.  This particularly cumbersome for keyboard and screen reader users.

Minimalist design

Syllabus w/pdf link

Medium

Display contents of the pdf on the page (as if an image).  The root of the issue is the metaphor the tool currently uses -- syllabus are created within the tool so each document uploaded is treated as if an item in the syllabus.  The more typical user model is to have an existing syllabus document that they can either display in this tool or copy and paste into the tool.

Recommendation for next steps:
- Redesign of syllabus tool to allow for it's current model plus the 2 mentioned above.  The tool could ask users what they want to do and direct them to the right workflow.  For example, "do you have an existing document you want to display?"
-  Coordinate with Cambridge on the Resources viewer to see if it can be leveraged.

Syllabus

Resources Viewer (look at what Cambridge is doing here)

Schedule

Intra-tool navigation links at the top of the page are not clear from their labels -- they are not explicit and some use language that will be unfamiliar to users in this context.

Match between system and real world - System should speak user's language

Schedule - intra-tool navigation

Low

Use explicit terminology in the form of "verb + noun".  Use terms that match users model of the action (i.e. "Display more schedules" rather than "Merge").

Recommendation for next steps:  Card sorting will help create better language.  Then change the labels in Sakai out-of-box.

Schedule

If user has no other schedules to merge (they don't own other site for instance), when they arrive at the "Merge" page, there is nothing listed.  This is further confused by the unclear label of the page itself.

Match between system and real world - System should speak user's language

Schedule > Merge

Medium

Rather than a blank list, display a message:  "You do not have any other schedules to display.  You may only display schedule items from other sites you own."  (needs better language).

Recommendation for next steps: 
- See above terminology change for nav and page label
- Display message above in Sakai out-of-the box

Schedule > Merge

Title of Merge page and instructions refer to "calendar" but "schedule" is used everywhere else

Consistency & Standards

Schedule > Merge

Low

Use either calendar or schedule everywhere when referring to the same thing.
Recommendation for next steps:  Change calendar to schedule in those places (see next issue for caveat) 

Schedule > Merge

Calendar is more common terminology for what that schedule tool is (ical, Oracle calendar, Outlook calendar, etc.)

Consistency & standards

System should speak user's language

Low

Change tool name and all related references to Calendar.

Recommendation for next steps: Sakai community should change this language.  It is a bit tricky since tool name changes are not backward compatible (at least they have not been yet).  Any existing sites would keep the tool title Schedule.  Some analysis should go into the trade-offs in user experience.

Schedule

On the Fields page, it's not clear what "fields" are (same goes for intra-tool nav label).  Am I choosing new fields, do I need to choose from this list?  Also, what kind of interaction will these have for users creating new items:  date for instance?

Recognition rather than recall - User should not have to remember information from another part of the system.

Schedule > Fields

Medium (edge case functionality not used often)

Rename this functionality to something that better matches the user's mental model.  Even something like "Schedule item attributes" would be better (although attribute is pretty geeky). 
OR create a 'wysiwyg interface' for this.  The fields can be edited while looking at a view of the form used to create schedule items 

Recommendation for next steps: 
- Card sorting to find out how user's semantically think about this functionality.  Then change the terminology in Sakai out-of-the box.
- OR redesign entire page as described above 

Schedule > Fields

On the Fields page, the remove checkboxes do not look connected to the fields.  Also the initial inclination is that checked items will appear and unchecked won't since this is a common interaction in Sakai.

Consistency and Standards

Schedule > Fields

Medium
(edge case functionality not used often)

At a minimum make the left table column less wide so there is a visual connection between the item in the list and it's checkbox.  Even better change the interaction so there is no doubt what the user is doing.  Some ideas are a "wysiwyg interface" (described in issue above) or a different layout where the fields are checked if they're included.
Recommendation for next steps:  
-  Adjust column width in Sakai out-of-the box (short term)

-  Redesign page in wysiwyg style (long term)

Schedule > fields