Gap analysis (working document)
The following table represents a first pass (still in-process) at trying to determine what functionality is missing from the Improving the CLE v1.0 designs (second column), when compared to functionality in Sakai 2.5 <http://nightly2.sakaiproject.org:8081/portal>, as well as in some local implementations (i.e. blue text denotes when it's a local need). The third column attempts to list what is missing from the "Sakai 3.0"/MyCamTools implementation <http://mycamtools.caret.cam.ac.uk/dev/index.html> , which is basically an implementation of the designs with some variation.
This is a simple element-by-element comparison. Note that just because something is listed, doesn't mean that it's necessarily a requirement for Sakai: determining that will require further analysis (is it now unnecessary?) and some input from the community. Also, some things that appear to be gaps ("none" listed in 2nd or 3rd column) may not be: while I've looked around the new designs for a place where the equivalent functionality may exist, I'm sure I've missed some and hope the community will fill cells in.
Comparisons have been done primarily against the designs found at the Improving the CLE v1.0 designs page, under "Implementation Summary", since these seem to be the most recent (5 Aug 08). Additional work may need to be done to compare against add'l design work found in the UX Kit.
(Note: As is to be expected, this is a moving target. Since this page was started, Nathan has continued to design; thus more recent work, addressing some of the gaps, is found as well at Round 1 Design mock-ups, and we should expect to see more updates such as this reflected in the table below.)
Sakai 2.5 feature/element/activity | equivalent feature/element in Improving the CLE 1.0 designs | equivalent feature/element in "Sakai 3.0"/MyCamTools implementation | comments/questions | needs of individual institutions |
|---|---|---|---|---|
|
|
|
|
|
Creating site
|
|
|
|
|
choose "Course" as a site type | "Yes" radio button for "Is This a Course site?" | same as designs |
|
|
choose "Portfolio site" as site type | ? "non-course site" option | same as designs | will this really do it for institutions where Portfolios are core? |
|
choose "Project site" as site type | ? "non-course site" option | same as designs |
|
|
specify academic term for a course site | this is present in slide 4a here: Round 1 Design mock-ups | none |
|
|
select roster (from list of rosters for which user is instructor of record) to be added to site | none |
|
| |
see titles of courses when selecting rosters (Berkeley implementation, not sure if in Nightly) | none |
|
| |
specify section that's not in choices offered, and get authorization | appears to be accommodated in slide 4a (Round 1 Design mock-ups), with dropdown indicating "Full Course Catalog" (as opposed to 'My Classes Only') | none |
|
|
add more than one roster to a site | yes, see slide 6 (Round 1 Design mock-ups) | none |
|
|
select rosters for all sections of a course with a single click | none | none |
|
|
create/edit title of site (Berkeley implementation, not Nightly) | Site Name field | same as designs |
|
|
Write site description | Site Description field |
|
|
|
WYSIWIG editing for site Description | none | none |
|
|
information about where Description appears | none | none |
|
|
Short Description field ("Displayed in publicly viewable list of sites. Max 80 characters.") | none | none |
|
|
information about where Short Description appears | none (n/a if not having Short description field) | none |
|
|
Appearance (Icon) | ? Site logo that can be uploaded in "Edit Look and Feel" may negate need for this | ? |
|
|
Site Contact Name field | none | none |
|
|
Site Contact Email field | none | none |
|
|
pick tools for site (aided by descriptions of tool), and customize these tools. | none during process of creating a site, but can be added later | same as designs |
|
|
option to re-use materials from another site belonging to this user | ? Perhaps by choosing "Copy One of Your Sites" (as seen in Presentation, week 2) | same as designs |
|
|
pick which tools to re-use materials from | ? Again, perhaps during "Copy One of Your Sites" (as seen in Presentation, week 2) | same as designs |
|
|
have site that's not available to anyone but self (Publish checkbox) | none during process of creating a site | same as designs? | as long as no rosters are added during site creation process, and default in Site Settings is "Private" this is achieved | |
option to have published site available only to participants, i.e. don't let others join (Global Access checkbox) | none during process of creating a site | same as designs? | as long as default is "Private" this is achieved. |
|
pick default role for those that join on their own | "Member's default role" dropdown | "All new members become" dropdown |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Site settings(Site Info> Edit Site Information) |
|
|
|
|
Display of Site Title | Site Name field | same as designs | why was it changed from Site "Name" to Site "Title"? | |
Edit title of site (Berkeley implementation, not Nightly) | Site Name field | same as designs |
|
|
Display of Term | none | none |
|
|
Description field | Description field | same as designs |
|
|
write site description | Site Description field |
|
|
|
WYSIWIG editing for Description | none | none |
|
|
information about where Description appears | none | none |
|
|
Short Description field ("Displayed in publicly viewable list of sites. Max 80 characters.") | none | none | Where does short description (see "Join & Edit Sites"p6-7) come from if not here? |
|
information about where Short Description appears | none (n/a) | none |
|
|
Appearance (Icon) | ? Site logo that can be uploaded in "Edit Look and Feel" | none |
| Don't use at Berkeley |
Site Contact Name field | ?Site Owner name field | none | Is there a difference? "contact" makes more sense in case of staff/TA/other setting up or administering a site for an instructor. The"owner" is perhaps the instructor. |
|
Site Contact Email field | none | none |
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
Adding members(Site Info > Add Participants) |
| Members tab of Site Settings not functioning, so can't check for any of the following |
|
|
option to add members using username or email address | "Enter Member's Username or Email Address" (but notes say will only ask for email address) |
|
|
|
instructions for how to enter more than one user | Tip |
| text in designs refers to adding " line-breaks" (not a term that all users will be familiar with, nor do they need to be familiar with it.) |
|
add campus ("official") members separately from non-campus ("official") members | none |
| wouldn't it be better if there was a single field and a lookup could happen to determine how to process |
|
option to assign unique roles when adding more than one member | none |
| Nathan's notes acknowledge that may want to do this. Also, can change roles later in Site Settings: Members tab.) | |
Role descriptions when selecting roles | ? Possibly can get to from "What does this mean?" |
|
|
|
option to add members without sending any email | ?none, looks like Invitation is always sent |
|
|
|
add members by adding official roster | none |
|
|
|
|
|
|
|
Comments
If we are contemplating Sakai 3 innovations in this work, I'd like to ask how we see Group Membership and Site Membership evolving. In the context of existing tools, what is the relationship between the "Roster" tool functionality and the SiteInfo "membership" functionality. It seems to me that SiteInfo is a bit like an admin dashboard for the site and Roster tool is simply an informative display of members for non-Admins. But with this separation, how would we handle a use-case for someone browsing a public site, reviewing the list of members and wanting to join on the spot? If in the Roster (membership) tool, then how does that relate to the admin tool in SiteInfo?
Also, I'd like to see integration between Roster displayed information and Profile and the ability for a course member to be present via an alias identity for certain teaching activities - perhaps as a sub-site for a language course. Whether the instructor can decipher the alias might depend on how marking/grading is done.
For now I assume we are looking at UX improvement of Sakai 2.X because we have not even begun to explore these types of issue.
To your last point, I think you're part right. We haven't begun formally designing and documenting these type of interactions, but informal thinking is always taking place.
In my view, everything in Site Settings (moving beyond legacy Sakai terminology) should only be viewable to site maintainers. Site Settings is where site maintainers would manage the members of the site, either by roster or individual.
For non-maintainer users who have a need/desire to sift through site members, either out of curiosity or for work tasks, we should develop a widget for that. The widget may or may not link off to a full screen view (that view could be tool technology or widget technology – a bit outside my realm), where members can be found. Perhaps within these views we would display some related meta data about the member. Each member should also have a profile view that is linked to from the list/directory widget views. In the profile (as well as the directory) view, the member will have some control over what he/she chooses the world to see – if anything at all.
Of course, users browsing these member profiles will have the option to interact with them by inviting friendship, discussion, and viewing work products (if shared).
I think what you are getting at John is that a tool that exists or is perceived largely as an "informative display" is probably an organization of functionality that has not been well integrated into work flows that meet end user goals. A recent example that came up around the Roster was Indiana faculty's need to see a membership list that easily let's them discern which site members have not been assigned to a group. The ability to act on the information by assigning group memberships should be part of an obvious, readily available workflow.
If we're looking forward here, it seems like the existing feature requests and uncompleted tasks should be considered in this context as well. For instance, importing and duplicating are mentioned, but not templating (which is in 2.6), exporting, archiving, deleting, resting, etc. related issues.
We may need a glossary for some of the terms used here. "Roster" as used here seems to indicate a list of people supplied by an external data source, but it could also mean a list of people registered for a particular course (where the site serves more than one course), or something else. The point is that something unclear creates the stated need to have more than one roster in a site. Or is "roster" here being used to indicate any list of members of groups and sections within a site?