Sakai 3 Groups Home Page

This is the Confluence space for collaborating on Groups functionality in Sakai 3


Introduction 

We propose that, in accordance with the model of "Projects" described in the new Sakai Development Process that emerged out of the last Board retreat, the integration of expanded User and Group Management functionality with the K2 and 3akai code bases constitutes such a project.

The services and functionality to incorporate, create and manage different kinds of user groups in Sakai has not been, up until now, designed and built in a comprehensive, systemic fashion. Services have been awkwardly bolted on top of one another; complementary tools with important unique capabilities also overlap in functionality, failing to play well together; the very meaning of a "group" is inconsistent and unpredictable across Sakai. With the introduction of social networking as a key concept in Sakai 3.0, the problem of rationalizing the federation and management of multiple kinds of groups has become even more complex.  

Problem Statement 

Project Objectives 

In brief, this project aims to deliver a coherent, yet flexible user and group membership management UX across a broad range of organizational possibilities both within and outside the site context:

  • institutionally defined and provisioned groups, including course rosters, cohorts etc.
  • non-institutionally defined groups via Open Social integration
  • user defined, non-provisioned Sakai groups
  • combinations of the above

Key Deliverables

  • UI for creating and adding groups and sub-groups
  • UI for adding, deleting and moving group memberships
  • UI for associating groups with sites
  • UI for finding groups
  • AuthZ to support appropriate levels of access to end user administrative functions
  • Any required mechanisms for bringing in external users and groups
  • Supporting system configuration options
  • Relevant UX Design Patterns for reusable chunks of UI regarding groups (i.e. searching (for groups, for people), selecting people...)

Design Goals

  • Quick access & group creation AND more complex group creation need to be supported
  • Group-centric rather than tool-centric
  • Feedback to users about what's happening all along the way
  • Easy/intuitive to use
  • Roles need to map to real world/how work gets done
  • Allow single person to have several roles across contexts
  • Don't make users leave their working context to create groups
  • Consistency across the application where it makes sense
  • Don't require users to understand roles (system roles)

Key assumptions

  • K2 and the 3akai UX are the foundations of the 3.0 release and the new work will build on the existing requirements and services they provide.
  • Groups can be defined and exist outside of the site context
  • User and Group data are available to Sakai via services provided by external enterprise systems. Sakai will consume that data to support native functionality when necessary, but will also expose external system functionality as widgets when possible. Sakai should aim to minimize duplication of SIS or enterprise identity management services and applications.
  • Requirements will be shared and coordinated with the Kuali Student project

Risks and dependencies 

  • Sakai 2.X has the notion of group and section "awareness" within tools. While the primary focus of this project is the delivery of administrative user and group management capabilities, the aggregation and representation of groups will continue to be required in other Sakai functional areas, e.g., grading, assignments. The UX for managing users and group memberships would ideally proceed in parallel with these other as yet undefined projects so that its design and development is informed by their requirements.
  • Issues raised by this project may need to both inform and shape certain areas of K2 , e.g., user metadata and permissions, especially those associated with groups.  The impact of the JCR hierarchy is an area for exploration.
  • The necessary technical and functional alignment outlined in the points above suggests a fairly wide degree of community and project coordination that may be in tension with making timely progress.

Use cases 

A fairly comprehensive set of known use cases has been documented:

Federated Authorization Use Cases

Frequency Matrix 

Group Types Spreadsheet

It is assumed that formalizing a more complete set of requirements will be part of the process of developing the group management functionality.

Team

Project Manager:  Oliver Heyer (UCB)

Developers:  Ray Davis (UCB), UC Davis Development team (Jon Gorrono, Thomas Amsler, Michael Wenk)

Interaction Developers:  Eli Cochran (UCB)

Interaction Designers:  Daphne Ogle (UCB), Keli Amann - 1/3 FTE (Stanford), Joanna Proulx - partial (MIT)

Partners

We seek other institutional partners to work with UCDavis and UCB in order to gather a reasonably broad set of perspectives on the issues involved.



Here's what is in this space


Creating and Managing User Groups

Group-Workspace Conceptual Visualizations