Communities vs. Sites

This page doesn't describe an existing mental model. Instead it's trying to explore a new one. So far the exploration seems to be going OK, but it could drop off the edge of the world at any time...

"Groups need to be first-class citizens"

The current "open experiment" of 3akai and K2 was driven by Nathan's earlier UX proposal, which in turn was heavily influenced by Sakai 2: we see social networking, content management, and dashboard features added to a friendlier version of "Worksite Setup". Because of this, "Site memberships" are the only groups the current 3akai demo can create, browse, add to and remove from. (In Jackrabbit-group terms, there's also one level of subgroups that hold site role assignments.)

However we know that we want Sakai 3 groups to have some sort of existence outside "site membership" and be usable outside a single "site". We're not yet sure what exactly that means, but we know we want it. Frustrated Sakai users tell us they need a straightforward way to give communities a collaborative workspace online. ("Community space" is a phrase I hear a lot.) Many of these communities already exist, with associated information and memberships available through services such as LDAP. There's also still a desire to easily set up a space which might then form a community around it (even if the "community" consists of readers who've subscribed to an update feed), or to easily create resources shared across multiple groups.

My first thought about how to get there from here was to interpret "first-class citizen" as "top of the URL path": we would have a "/sites/" tree and a "/groups/" tree, and somehow "/groups/courses/English/2009/Fall/202" and "/groups/organizations/Latin Club" and "/groups/colleges/Balliol" could obtain spaces at "/sites/Restoration Drama" or "/sites/Omnia Dicta Fortiora" or "/sites/Balliol's Scholars" or "/sites/Balliol Presents the Immortal Dryden's All for Love".

But again this may be premature. Things such as an academic department or a tutorial group involve more than just membership lists. They very frequently include roles (or job titles, or relationships) and scheduled meetings or events. A "canonical course" may not carry any particular memberships but still supply a default syllabus and grading scheme inherited by more group-like "course sections." If course descriptions and class enrollments and section memberships and campus residences are managed outside Sakai and visible to Sakai services, why should Sakai users have to "create a site" in order to see them? Why not allow direct access when it's available?

In other words, would it be possible to make communities first-class citizens, and to selectively add Sakai-supplied capabilities and Sakai-hosted content to the online community? Since most paths in a collaborative web application will be associated with some sort of membership list, there would be no special need to distinguish "top-level groups" from "site memberships": a site membership is a top-level group. Two things distinguish this from the Sakai 2 world: A) Such groups can be referred to from multiple spaces rather than being confined to a single URL space. B) Addressable URL spaces might correspond to an existing (externally defined) group without any special action being taken to "create" them.

Some more thoughts from the 2009-08-21 meeting with the Groups-n-Roles team and Michael Korcuska...

What dissatisfactions with Sakai 2 lay behind "Groups must be first-class citizens"? The motives I've heard most often are to:

• Easily share resources across organizational structures.
• Easily and more flexibly map community roles to application roles.
• Easily handle multiple types of community (courses, clubs, department staffing, colleges, residences, cohorts...).

So here's a thought experiment: At the top of the Sakai site are Individuals and Communities. Individuals have a "My Dashboard"; Communities have a "Community Space". In "My Dashboard" I can see what communities I belong to with links to their spaces. A known person doesn't have to "create a site" to have a space. A known community or organization doesn't, either. What the space shows by default depends on what information is available from the external integration (e.g., a person's name, email address, and institutional status, or a community's membership, roles, description, and calendar) and what default templates have been set up.

A resource/widget can be shared with other individuals or other groups without making them "members" of the originator's dashboard/space. A site can be created and then shared with other individuals or other groups. (As Michael K. pointed out, though, this is almost exactly equivalent to defining a new community space whose membership will be drawn from multiple sources. It's really a matter of initial emphasis.)

Big pictures

1. Integration with externally maintained communities

2. Map community roles to functional roles, access rights, workflows, ...

3. Breaking the silos