Community Contexts

Community Contexts

Much of what I've said about groups mockups has to do with the problem of mashing varied social connections into a single web framework. Over the last year-plus of UX reviews, interviews, and integration requirements gathering, I've developed a vague but hopeful intuition of community context as an approach to the problem. I'll describe the intuition here and maybe start to find out where it works and where it fails.

A community context decides what groups, people, membership types, etc., you're most likely to be interested in at a given moment. When you choose people, the context decides which people you usually see: not everyone in the universe, not everyone in the university, but everyone in this context. When you look at named lists of people, the context decides which ones you usually see. When you want to create a new named group of people or new categories of groups, what you create most likely stays within this context. (Although always with the optional ability to jump out to another or a wider community context - particularly important when adding new members or membership feeds!)

Sketching out scenarios from Daphne's and Keli's earlier work, I found that different types of community context tended to have different types of built-in groups and group categories. And I found that different types of community context also tended to integrate externally defined and populated groups from different sources. Which suggests a pluggable model in which Sakai 3 installations can pick and choose among various community context types, all of which support similar person/group UX operations.

To keep the concepts clearer, in the following sketches I'll leave out things like "we should collapse community hierarchies when the user only has access to one context in the hierarchy" and "the dashboard should let users decide that some contexts are more important than others".

You log into your Sakai 3 installation and see your Dashboard. As side-bar links (or as tabs, or as a tree menu, or as a revolving exploding pie chart), you see entries to a variety of community context types:

Choosing any of the links brings you to the top of a community context. Once you're there, you see messages, new resources, etc., for the context. For each of the examples, I'll show some built-in or externally-defined categories and groups, and then add a named group or category of groups to the context.

MY CONTACTS

The top of the context here is a person. What I see here is "My Contacts"; what someone else with suitable privileges would see is "Ray's Contacts".

Relationships are built-in contact types used by social networking software; possibly integrated with external OpenSocial networks.

The new groups are named and created by myself. My "Suitemates" won't conflict with some other person's "Suitemates".

MY PORTFOLIO

These are built-in types used by pedagogical and career-oriented software to help determine privileges and workflow; possibly integrated with campus systems, etc.

COURSES

This would match whatever academic hierarchy best fits the local institutional style. Supplied groups and categories might come from the registrar, IMS LIS, Kuali systems, ...

"Roles" is a built-in category of possible interest to software.

"Labs" is a category integrated from campus systems. This "Lab 1" doesn't conflict with some "Lab 1" in Psychology 101.

"Mid-term project teams" is a locally created category with automatically named and populated groups.

DEPARTMENTS

These groups and units are integrated with personnel systems via LDAP.

Job titles might also be used as group names.

SHARED SPACES

This is a way to expose a new community context for sharing a collection of rich resources. In other words, a Sakai 2 "project site".

"Roles" is a built-in category of groups, used to make it easier to assign privileges and responsibilities to multiple people at once.

RESEARCH PROJECTS

This is a possible example of hosting a multi-institutional research site using Shibboleth and SAML for basic authentication and authorization.

Sharing content across contexts

Depending on application-specific rules, any given chunk of rich content might be shared across community contexts.