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
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.
Project Definition
Creating and Managing User Groups (current page)
Problem Statement
Requirements
Groups Use Case Matrix
Design Documents
Design Goals
Context Scenarios (Group creation & management)
Mental Models - Groups
Benchmarking - Comparing how other systems deal with groups
Wireframes
Group manager - advanced group creation V2
Group Manager - advanced creation & editing
Quick group creation
Viewing Groups Wireframes
Archived (early iteration) designs
Project planning
Group Project Plan
UX Activities (groups)
Developer Activities (groups)
Meetings
Understanding the Space
Group & workspace relationship
Project Glossary
Group Type Spreadsheet (examples of groups in higher education)
Federated Authorization Use Cases
Group diagrams from Stanford
SAKAI09 Conference interviews & BOFs
ACAMP Identity Services Summit 2009
ACAMP Identity Services Summit 2010
Communities vs. Sites
Roles and Permissions
Meeting with Shibboleth's Steven Carmody
2010 Sakai Conference presentation
Links to previous related work
User Research Notes from Course Management Project 2006
Sakai 2 integration issues
Course and Site Structure Patterns
"Competitive analysis" from Feb. 2009
Profile scenarios and wireframes from early 3akai work
Other resources
Boston BOF to kick off UX work for groups (Keynote version)
Boston BOF to kick off UX work for groups (.pdf version)
Recent updates
There are no recent updates at this time.
Here's what is in this space
Creating and Managing User Groups
- Group & workspace relationship
- Group Manager - advanced creation & editing
- Community Contexts
- Design Goals
- Developer Activities (groups)
- Federated Authorization Use Cases
- Group Management Project Glossary
- Group manager - advanced group creation V2
- Meetings
- Meeting with Shibboleth's Steven Carmody
- Quick group creation
- Archived (early iteration) Wireframes
- Communities vs. Sites
- Context Scenarios (Group creation & management)
- Community Use Cases
- Benchmarking - Comparing how other systems deal with groups
- Mental Models - Groups
- Problem Statement
- Roles and permissions
- SAKAI09 Groups-Roles Notes
- Sakai 2 integration issues
- Group Project Plan
- Groups Use Case Matrix
- Sakai 3 Groups Ideas
- UX Activities (groups)
- Viewing Groups Wireframes
- Communities (groups) and People - Conceptual Understanding