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

[John Norman]

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? 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"