[DG: User Experience] Pending groups-and-role 3akai tasks

[Ray Davis]

Apologies in advance for this noise -- we lack a more focused way of
coordinating developer communities while waiting for Simple Learning
Environment project management to coalesce.

I have a fairly extensive list of possible group-and-role-related tasks
to tackle next, but I know Paul Bristrow has started working the same
territory, and others may be wandering around here as well. Less
formally, then, does anyone have any particular feelings pro or con
about which of these seems most worthwhile at present? Or another task
which trumps them all?

A. Now that we've dropped our local simple pick-and-clump-people
component --
http://confluence.sakaiproject.org/display/GROUPS/Quick+group+creation
-- into a site membership context, I can do a similar proof-of-concept
drop into a personal dashboard (where the membership pool is "personal
connections/contacts" rather than "site members").

B. Since we know that UX which browses or selects site members must
include named subgroups alongside site member roles, I can start
abstracting site roles as a "built-in" list of groups for use by UX
components.

C. I can start providing group "categories" (the name might be thrown
away, but we need a way to say things about a set of groups, such as
"everyone must be a member of one of these groups", "each person can
belong to only one of these groups", and "clump these groups together
under the name X"):
http://confluence.sakaiproject.org/display/GROUPS/Group+manager+-+advanced+group+creation+V2

D. I can start modeling things like site membership roles and personal
connection relationships as such "categories". This will let us do
real-world testing with multiple sources of group information (expanding
into academic organizational structures on one side, and OpenSocial /
portfolio relationships on another), and directly engage with Paul's
sketch of possible "APIs for a group management system."

E. I can streamline and consolidate 3akai's current site membership
functionality as described here:
http://groups.google.com/group/sakai-kernel/browse_thread/thread/bc02df16f691bc8c
Among other benefits, this should make it easier to experiment with
different approaches to site roles (for example, making them
customizable through templates).

F. I can take a couple of days of vacation. :)

Best,
Ray
_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

I thought we agreed to E: on October 26 on the kernel list. If it is  
not done yet, it would get my vote.

John

On 5 Nov 2009, at 19:59, Ray Davis wrote:

> Apologies in advance for this noise -- we lack a more focused way of
> coordinating developer communities while waiting for Simple Learning
> Environment project management to coalesce.
>
> I have a fairly extensive list of possible group-and-role-related  
> tasks
> to tackle next, but I know Paul Bristrow has started working the same
> territory, and others may be wandering around here as well. Less
> formally, then, does anyone have any particular feelings pro or con
> about which of these seems most worthwhile at present? Or another task
> which trumps them all?
>
> A. Now that we've dropped our local simple pick-and-clump-people
> component --
> http://confluence.sakaiproject.org/display/GROUPS/Quick+group+creation
> -- into a site membership context, I can do a similar proof-of-
> concept
> drop into a personal dashboard (where the membership pool is "personal
> connections/contacts" rather than "site members").
>
> B. Since we know that UX which browses or selects site members must
> include named subgroups alongside site member roles, I can start
> abstracting site roles as a "built-in" list of groups for use by UX
> components.
>
> C. I can start providing group "categories" (the name might be thrown
> away, but we need a way to say things about a set of groups, such as
> "everyone must be a member of one of these groups", "each person can
> belong to only one of these groups", and "clump these groups together
> under the name X"):
> http://confluence.sakaiproject.org/display/GROUPS/Group+manager+-+advanced+group+creation+V2
>
> D. I can start modeling things like site membership roles and personal
> connection relationships as such "categories". This will let us do
> real-world testing with multiple sources of group information  
> (expanding
> into academic organizational structures on one side, and OpenSocial /
> portfolio relationships on another), and directly engage with Paul's
> sketch of possible "APIs for a group management system."
>
> E. I can streamline and consolidate 3akai's current site membership
> functionality as described here:
> http://groups.google.com/group/sakai-kernel/browse_thread/thread/bc02df16f691bc8c
> Among other benefits, this should make it easier to experiment with
> different approaches to site roles (for example, making them
> customizable through templates).
>
> F. I can take a couple of days of vacation. :)
>
> Best,
> Ray
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Ray Davis]

I did (B) at the end of the week, and the experience left me even more
motivated to tackle (E). :)

Best,
Ray

On 11/8/09 4:23 AM, John Norman wrote:

> I thought we agreed to E: on October 26 on the kernel list. If it is not
> done yet, it would get my vote.
>
> John
>
> On 5 Nov 2009, at 19:59, Ray Davis wrote:
>
>> Apologies in advance for this noise -- we lack a more focused way of
>> coordinating developer communities while waiting for Simple Learning
>> Environment project management to coalesce.
>>
>> I have a fairly extensive list of possible group-and-role-related tasks
>> to tackle next, but I know Paul Bristrow has started working the same
>> territory, and others may be wandering around here as well. Less
>> formally, then, does anyone have any particular feelings pro or con
>> about which of these seems most worthwhile at present? Or another task
>> which trumps them all?
>>
>> A. Now that we've dropped our local simple pick-and-clump-people
>> component --
>> http://confluence.sakaiproject.org/display/GROUPS/Quick+group+creation
>> -- into a site membership context, I can do a similar
>> proof-of-conceptdrop into a personal dashboard (where the membership
>> pool is "personal
>> connections/contacts" rather than "site members").
>>
>> B. Since we know that UX which browses or selects site members must
>> include named subgroups alongside site member roles, I can start
>> abstracting site roles as a "built-in" list of groups for use by UX
>> components.
>>
>> C. I can start providing group "categories" (the name might be thrown
>> away, but we need a way to say things about a set of groups, such as
>> "everyone must be a member of one of these groups", "each person can
>> belong to only one of these groups", and "clump these groups together
>> under the name X"):
>> http://confluence.sakaiproject.org/display/GROUPS/Group+manager+-+advanced+group+creation+V2 
>>
>>
>> D. I can start modeling things like site membership roles and personal
>> connection relationships as such "categories". This will let us do
>> real-world testing with multiple sources of group information (expanding
>> into academic organizational structures on one side, and OpenSocial /
>> portfolio relationships on another), and directly engage with Paul's
>> sketch of possible "APIs for a group management system."
>>
>> E. I can streamline and consolidate 3akai's current site membership
>> functionality as described here:
>> http://groups.google.com/group/sakai-kernel/browse_thread/thread/bc02df16f691bc8c 
>>
>> Among other benefits, this should make it easier to experiment with
>> different approaches to site roles (for example, making them
>> customizable through templates).
>>
>> F. I can take a couple of days of vacation. :)
>>
>> Best,
>> Ray
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"
>
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"