[Using Sakai] [DG: User Experience] Some thoughts on group functionality

Mon Oct 26 11:33:55 PDT 2009

On 10/26/09 10:38 AM, John Norman wrote:
> Paul
> 
> It seems to me this is the critical paragraph in your paper:
> "A group management system such as this would be useful across (and  
> beyond) the enterprise. I see no reason why it has to be part of the  
> sakai kernel, part of the same JVM or part of the same service. My  
> preference would be an API for sakai 3 along with a reference  
> implementation which may be outside the kernel but in the sakai  
> instance"
> 
> It goes to the scope question:
> Are we solving the Enterprise Groups problem, or some subset of the  
> problem?

Neither, AFAIK, if I'm part of the "we". :)  What we need to solve is 
more your question 2 than your question 1.

* Sakai needs to support use cases that use a variety of approaches to 
"enterprise groups", including multiple sources and including "no 
sources at all." We can't dictate those. But we _can_ be prepared for 
particular testable real-world use cases, and we _should_ support the 
most common ones (possible candidates include IMS LIS, Kuali SIS, some 
LDAP configurations, some SAML configurations, OpenSocial as both 
producer and consumer) out of the box.

* Sakai needs to combine integration with externally managed communities 
(including "enterprise groups") with the flexibility our users expect of 
decent collaborative software. That means not ONLY supporting 
internally-managed memberships, roles, and permissions, and not ONLY 
supporting externally-dictated memberships, roles, and permissions. The 
hardest task (or at least the task on which Sakai 2 fell apart most 
painfully) is supporting both in a way that normal human beings can 
understand.

So I talk a lot about integration approaches because I know we need to 
understand them (and sometimes hook up to them) to meet Sakai user 
needs. And I spend some time pressing for standardization of integration 
sources (so that, for example, Google Apps Education, Moodle, Sakai, and 
Blackboard can all work from the same feeds) because that will 
ultimately reduce the amount of duplicated work Sakai customers need to 
do. But they're basically a side issue to the problem that really 
preoccupies us.

In terms of integrating with a single all-in-one group-management 
solution, see:
http://confluence.sakaiproject.org/display/GROUPS/Potential+service+integrations

Best,
Ray

> If we are solving a subset, what are the integration points  
> with the Enterprise Groups solution and what do we do if no Enterprise  
> Groups solution is available? If we solve the Enterprise Groups  
> problem, what does deployment look like in an institution with another  
> Enterprise Groups solution in place?
> 
> In general, the approach I believe you are proposing - that the UI to  
> manage groups interacts with code outside the kernel but then is  
> expressed in terms of JCR groups inside the kernel through an api - is  
> appealing. It offers performance for questions the code needs answered  
> (like: can this user access this information?) and it seems to offer  
> flexibility for educationally-important group use-cases that are not  
> strictly Sakai-only information. But as I try to think this through I  
> get stuck in a couple of places
> 1. How do we create a UI that is meaningful both outside and inside  
> Sakai
> 2. How can we design a user experience that works equally well for  
> institutions that have Enterprise Groups and institutions that do not?
> 
> John
> 
> PS This is for me the main area of ambiguity in the documents to which  
> Ray keeps referring. I can't find where the questions are addressed  
> and I keep imagining that Ray is in fact trying to write the  
> Enterprise Groups application of which Sakai would then be a client.  
> In supposing that Sakai would be able to manage some of the  
> information in an Enterprise Groups store, one makes assumptions about  
> what the owners of that store will accept from other systems. Those  
> assumptions may not be universally valid.
> 
> PPS The problem is exacerbated by Enterprise Groups currently being an  
> unsolved problem (as far as I know) and different institutions having  
> very different political contexts in which any solution might be  
> deployed and operated. Each of us is likely making assumptions about  
> how an Enterprise Groups future might be realised and that is likely  
> colouring our expectations of how this might impact Sakai. I think the  
> emergence of LDAP as an intermediate step in one profile (?) of the  
> IMS SIS/LMS integration work both illustrates the dilemma and one  
> possible response to the dilemma.
> 
> PPPS If I think of the problem as an Enterprise Integration problem, I  
> am tempted to come over all SOA and say Sakai should have a means of  
> being aware (and kept up to date) of relevant information sources  
> outside Sakai and should be able to determine what it does with that  
> external information. If Sakai manages/processes the information it  
> should be able to do what it likes, but should emit events that notify  
> the external system of Sakai's manipulations and allows the external  
> system to decide what notice it takes of those manipulations. This  
> points to a more tightly scoped set of user interactions with groups  
> data.
> 
> Scope is everything in this discussion.
> 
> On 25 Oct 2009, at 23:55, Bristow, Paul wrote:
> 
>> http://docs.google.com/View?id=dcshzgr2_1c892k2pt
>>
>> Some conceptual thoughts about group functionality, required  
>> functions and a possible approach. Rough thoughts at the moment,  
>> could be expanded if there's value in them.
>>
>>> From what I can see from the sidelines of the Sakai 3 groups  
>>> initiative it seems focused on the client side of how users use a  
>>> group management system. I've tried to coalesce the functionality  
>>> of the requirements identified here and elsewhere along with our  
>>> local experience and expectations into a possible system and API  
>>> for back end functionality.
>> Comments, suggestions, criticism welcome
>>
>> ----------------------------------------------------
>> Paul Bristow
>> Applications Architect
>> Division of Information Technology
>> Charles Sturt University
>> Ph: 02 6051 9959
>> Fax: 02 6051 9919
>> pbristow at csu.edu.au
>> www.csu.edu.au
>> ----------------------------------------------------
>>
>> YOU MUST READ THIS NOTICE
>>
>> This email has been sent by Charles Sturt University (ABN 83 878 708  
>> 551). This email
>> (and any attachment) is confidential and is intended for the use of  
>> the addressee(s)
>> only. If you are not the intended recipient of this email you must  
>> not copy,
>> distribute, take any action in reliance on it or disclose it to  
>> anyone. Any
>> confidentiality is not waived or lost by reason of mistaken delivery  
>> to you. The
>> views expressed in this email are not necessarily those of Charles  
>> Sturt University.
>> It is very important that before opening any attachments to this  
>> email you check them
>> for viruses and defects. CSU does not accept liability for any  
>> corruption or viruses
>> or any consequence which arise as a result of this email  
>> transmission. Email
>> communications with CSU may be subject to automated email filtering,  
>> which could result
>> in the delay or deletion of a legitimate email before it is read by  
>> its intended
>> recipient at CSU. Please tell us if you have concerns about this  
>> automatic filtering.
>> The Commonwealth Register of Institutions and Courses for Overseas  
>> Students (CRICOS)
>> Provider Number is 00005F (NSW), 025973E (QLD), and 01947G (VIC) for  
>> Charles Sturt
>> University.
>> ----------------------------------------------------
>> _______________________________________________
>> sakai-user mailing list
>> sakai-user at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-user
>>
>> TO UNSUBSCRIBE: send email to sakai-user-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
> 
> _______________________________________________
> sakai-user mailing list
> sakai-user at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-user
> 
> TO UNSUBSCRIBE: send email to sakai-user-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 