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.
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
- 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...)
- 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)
- 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.
A fairly comprehensive set of known use cases has been documented:
It is assumed that formalizing a more complete set of requirements will be part of the process of developing the group management functionality.
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)
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
- 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
- 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