Problem Statement from the End Users' Perspective

The problem of...

• Users need to identify and gather sets of people within the system to:
  • collaborate with
  • communicate with
• Users have minimal amount of time, energy and cognition and should not have to relearn similar interactions across contexts (within Sakai)
• Users need to to have up-to-the-minute information and have disparate systems across campus agree about enrollment and membership status.  Information is not always up-to-date and it is impossible to determine what is and isn't current information (e.g. enrollments are not immediately updated)
• Users need to reuse some groups.  Others might be one time groupings (e.g. email recipient list)
• Users need to easily understand how to create and manage groups.  Sakai doesn't always tell users what to do next
• Users need to identify people based on common interest and/or criteria (e.g. everyone with similar thesis interests, students who live around me, everyone interested in cats)
• Users need to be able to define what activities the group will do together (not let the tools decide what the group can do)
• Users need to be able to create a group from within the context I'm working in (not go someplace else, create the group and then come back to the work)

Affects...

• learners
• collaborators
• teachers
• assistants to teachers
• administrators for courses, departments, etc.
• administrators of campus programs
• Authors (publishing model)?
• Lurkers / Public

The impact of which...

• Users are driven to other solutions
• Users can't tell what information is current and what isn't
• Collaborating in Sakai is challenging
• Using Sakai is superficial for many users
• Mass confusion
• Inefficiency
• Unhappiness
• Can't do what they need to

A successful solution would provide...

• Consistent interaction for creating, managing & engaging groups (across Sakai)
• Help users through the process of creating and managing groups
• Enough built in help within the interaction (e.g. feedback, discoverability, "undos", etc.) that users don't need outside help  
• Give feedback about what is happening
• Meet existing expectations & models from other systems they use (email, facebook, linked in, etc.)
• Personal view on all my groups
  • mind mapping?
  • visual relationships
  • visual representations
• Drag & drop
• An easy way to find people that meet X criteria
• A way for people to determine how easily found they want to be (can change across contexts & time)
• Clean relationship with profile
• A way to personally define relationship to group
• Allow for my role to change across contexts
• Historical record of involvement in group (perhaps more for how groups get utilized)
  • authorization
  • student drops course - should still have access to their material but not access official course material
  • course gets unpublished - don't want student to lose access to their learning experience

Design Goals

• Group-centric rather than tool-centric
• Feedback to users about what's happening
• 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)