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

View: New views

3 Messages — Rating Filter: Alert me

	Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality] by Ray Davis :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Apologies for sending this out of order -- reply-to was pointed to Clay instead of the UX team. Some of my points were taken up by Paul and Michael, but for the record.... Ray -------- Original Message -------- Subject: Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality Date: Mon, 26 Oct 2009 07:09:58 -0700 From: Ray Davis <ray@...> To: clay.fenlason@... References: <4AC5072A.8060802@...> <7B6E7514-0F5B-463C-9320-E6821256E162@...> <34859EE98DD88F4982843F713AE11E9214B032208D@...> <144C8E2433CA3B4D9E080E5CDA803D0503AEE20D@...> <be5dfc6d0910260232y6f55f0m43598b5d9a80e404@...> You're hardly alone in hoping that "roles" could be subsumed into "groups" -- it's standard-operating-procedure across the industry. But you're not going to get them to disappear from a LMS/CLE. (At the Internet2 ID Management summit this year, I got a chance to test that contention against a range of other open source projects, and there was finally agreement that we were stuck with the problem.) A "group" is an _instance_. A "role" is an aspect that cuts _across_ instances. Even in the limited world of the 3akai-demo, a request like "Give me the list of Collaborators" doesn't make much sense. What you probably want instead is "Give me the list of Collaborators in this site context." "Collaborator" has an important human meaning that gets embedded in the UX (we show a site member as a "Collaborator" or a "Viewer", not as a "member of the g-my-little-old-site-collaborators team"). "Collaborator" also determines application and service permissions, and so it has an important meaning that's not so visible in the wireframes. As the 3akai-demo expands to cover more real-world needs, we're going to hit two other areas in which "roles" (or something like them) need modeling: integration with other social contexts (e.g., a department's "administrator" or a class's "enrolled student") and pluggability of new functionality (e.g., "Who gets to be moderator by default?"). To remove one potential source of confusion, I agree that not all "group" contexts include "roles". I also agree that end users need more flexible handling of role-permission mappings than they practically got with Sakai 2. Finally, I agree that in relatively simple collaborative spaces (a standalone discussion board, say) or relatively rigid social spaces and centralized administration (a government agency or a traditionally bureaucratic company), the two concepts (although different in human terms) can be kludged together on the back-end. Such kludges aren't sustainable in an LMS/CLE because we combine support for multiple (pluggable) social contexts with support for multiple (pluggable) collaborative applications and services. Best, Ray On 10/26/09 2:32 AM, Clay Fenlason wrote: > The first thing that strikes me, something I've ventured tentatively > in the past (it's good to not feel alone), is the idea that roles are > a secondary and optional feature of groups. Something about that just > seems right to me in concept, though I won't claim to have thought > through whether this is ultimately a helpful shift in practice. > > I think the value of the role is primarily as a simplification for the > UX, a metaphorical shortcut to help the user achieve sensible > intuitions about a potentially complicated set of permissions. It can > be a valuable design artifact, in other words, in many contexts. But > it need not be assumed for all group contexts. In cases where the > likely intuition might be misleading and harmful, the role might be an > active hindrance and might need to be explicitly set aside in favor of > a specific permission choice in a particular workflow. Again, that > seems to me a design choice in context, and not an inextricable > feature of the technical design. What's more, baking the role deeply > into the technical design may lead to brittleness where role > intuitions are misleading. > > ~Clay > > On Sun, Oct 25, 2009 at 11:55 PM, Bristow, Paul <PBristow@...> 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@... >> www.csu.edu.au _______________________________________________ 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"
	Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality] by jrnorman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Well, at the risk of muddying the water: I can imagine that roles are modelled as groups internally, but preserved as UX concepts. The idea that I read in Clay's post is that a plain-vanilla group only needs members. Roles only come into it if you want to classify members and treat different classes of members ... well ... differently. Technically, which 'class' you are put in among the membership can almost certainly be handled as being added to a group in the code, but would probably not be described that way in the UI. Maybe we should adopt some British terminology and go for Upper Class, Middle Class and Lower Class memberships :-) John PS the examples above tend to assume the classification is exclusive. The system should probably not assume exclusivity. e.g. I can mark homework because I have TA role in Physics 101, I can de-activate a student membership because I also have Admin role, but Chris - the Course Secretary - can only de-activate a student and can't mark homework because (s)he is 'only' an Admin. On 26 Oct 2009, at 15:51, Ray Davis wrote: > Apologies for sending this out of order -- reply-to was pointed to > Clay > instead of the UX team. Some of my points were taken up by Paul and > Michael, but for the record.... > > Ray > > -------- Original Message -------- > Subject: Re: [DG: User Experience] [Using Sakai] Some thoughts on > group > functionality > Date: Mon, 26 Oct 2009 07:09:58 -0700 > From: Ray Davis <ray@...> > To: clay.fenlason@... > References: <4AC5072A.8060802@...> > <7B6E7514-0F5B-463C-9320-E6821256E162@...> > <34859EE98DD88F4982843F713AE11E9214B032208D@...> > <144C8E2433CA3B4D9E080E5CDA803D0503AEE20D@...> > <be5dfc6d0910260232y6f55f0m43598b5d9a80e404@...> > > You're hardly alone in hoping that "roles" could be subsumed into > "groups" -- it's standard-operating-procedure across the industry. But > you're not going to get them to disappear from a LMS/CLE. (At the > Internet2 ID Management summit this year, I got a chance to test that > contention against a range of other open source projects, and there > was > finally agreement that we were stuck with the problem.) > > A "group" is an _instance_. A "role" is an aspect that cuts _across_ > instances. Even in the limited world of the 3akai-demo, a request like > "Give me the list of Collaborators" doesn't make much sense. What you > probably want instead is "Give me the list of Collaborators in this > site > context." "Collaborator" has an important human meaning that gets > embedded in the UX (we show a site member as a "Collaborator" or a > "Viewer", not as a "member of the g-my-little-old-site-collaborators > team"). "Collaborator" also determines application and service > permissions, and so it has an important meaning that's not so > visible in > the wireframes. > > As the 3akai-demo expands to cover more real-world needs, we're > going to > hit two other areas in which "roles" (or something like them) need > modeling: integration with other social contexts (e.g., a department's > "administrator" or a class's "enrolled student") and pluggability of > new > functionality (e.g., "Who gets to be moderator by default?"). > > To remove one potential source of confusion, I agree that not all > "group" contexts include "roles". I also agree that end users need > more > flexible handling of role-permission mappings than they practically > got > with Sakai 2. Finally, I agree that in relatively simple collaborative > spaces (a standalone discussion board, say) or relatively rigid social > spaces and centralized administration (a government agency or a > traditionally bureaucratic company), the two concepts (although > different in human terms) can be kludged together on the back-end. > > Such kludges aren't sustainable in an LMS/CLE because we combine > support > for multiple (pluggable) social contexts with support for multiple > (pluggable) collaborative applications and services. > > Best, > Ray > > On 10/26/09 2:32 AM, Clay Fenlason wrote: >> The first thing that strikes me, something I've ventured tentatively >> in the past (it's good to not feel alone), is the idea that roles are >> a secondary and optional feature of groups. Something about that just >> seems right to me in concept, though I won't claim to have thought >> through whether this is ultimately a helpful shift in practice. >> >> I think the value of the role is primarily as a simplification for >> the >> UX, a metaphorical shortcut to help the user achieve sensible >> intuitions about a potentially complicated set of permissions. It can >> be a valuable design artifact, in other words, in many contexts. But >> it need not be assumed for all group contexts. In cases where the >> likely intuition might be misleading and harmful, the role might be >> an >> active hindrance and might need to be explicitly set aside in favor >> of >> a specific permission choice in a particular workflow. Again, that >> seems to me a design choice in context, and not an inextricable >> feature of the technical design. What's more, baking the role deeply >> into the technical design may lead to brittleness where role >> intuitions are misleading. >> >> ~Clay >> >> On Sun, Oct 25, 2009 at 11:55 PM, Bristow, Paul >> <PBristow@...> 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@... >>> www.csu.edu.au > > > _______________________________________________ > 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"
	Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality] by Ray Davis :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Well, internally all the software is just machine instructions and all the users are just wet piles of sullied carbon. :) But since "known roles" ("relationships", "duties", "titles", etc.) get treated differently from "instances of groups" in human minds, in application integration code, and in community administration code, I think it makes more practical sense to admit them into the model. Leaving the concept out seems to create more complexity rather than less. On 10/26/09 10:53 AM, John Norman wrote: > Well, at the risk of muddying the water: I can imagine that roles are > modelled as groups internally, but preserved as UX concepts. The idea > that I read in Clay's post is that a plain-vanilla group only needs > members. Roles only come into it if you want to classify members and > treat different classes of members ... well ... differently. > Technically, which 'class' you are put in among the membership can > almost certainly be handled as being added to a group in the code, but > would probably not be described that way in the UI. > > Maybe we should adopt some British terminology and go for Upper Class, > Middle Class and Lower Class memberships :-) > > John > > PS the examples above tend to assume the classification is exclusive. > The system should probably not assume exclusivity. e.g. I can mark > homework because I have TA role in Physics 101, I can de-activate a > student membership because I also have Admin role, but Chris - the > Course Secretary - can only de-activate a student and can't mark > homework because (s)he is 'only' an Admin. FWIW, I'm not making that assumption. I am assuming, though, that we can't present our instructors with a flat list of 1000 names and say "Here, sort out which ones of these can mark the homework of the others." Best, Ray > > On 26 Oct 2009, at 15:51, Ray Davis wrote: > >> Apologies for sending this out of order -- reply-to was pointed to Clay >> instead of the UX team. Some of my points were taken up by Paul and >> Michael, but for the record.... >> >> Ray >> >> -------- Original Message -------- >> Subject: Re: [DG: User Experience] [Using Sakai] Some thoughts on group >> functionality >> Date: Mon, 26 Oct 2009 07:09:58 -0700 >> From: Ray Davis <ray@...> >> To: clay.fenlason@... >> References: <4AC5072A.8060802@...> >> <7B6E7514-0F5B-463C-9320-E6821256E162@...> >> <34859EE98DD88F4982843F713AE11E9214B032208D@...> >> <144C8E2433CA3B4D9E080E5CDA803D0503AEE20D@...> >> <be5dfc6d0910260232y6f55f0m43598b5d9a80e404@...> >> >> You're hardly alone in hoping that "roles" could be subsumed into >> "groups" -- it's standard-operating-procedure across the industry. But >> you're not going to get them to disappear from a LMS/CLE. (At the >> Internet2 ID Management summit this year, I got a chance to test that >> contention against a range of other open source projects, and there was >> finally agreement that we were stuck with the problem.) >> >> A "group" is an _instance_. A "role" is an aspect that cuts _across_ >> instances. Even in the limited world of the 3akai-demo, a request like >> "Give me the list of Collaborators" doesn't make much sense. What you >> probably want instead is "Give me the list of Collaborators in this site >> context." "Collaborator" has an important human meaning that gets >> embedded in the UX (we show a site member as a "Collaborator" or a >> "Viewer", not as a "member of the g-my-little-old-site-collaborators >> team"). "Collaborator" also determines application and service >> permissions, and so it has an important meaning that's not so visible in >> the wireframes. >> >> As the 3akai-demo expands to cover more real-world needs, we're going to >> hit two other areas in which "roles" (or something like them) need >> modeling: integration with other social contexts (e.g., a department's >> "administrator" or a class's "enrolled student") and pluggability of new >> functionality (e.g., "Who gets to be moderator by default?"). >> >> To remove one potential source of confusion, I agree that not all >> "group" contexts include "roles". I also agree that end users need more >> flexible handling of role-permission mappings than they practically got >> with Sakai 2. Finally, I agree that in relatively simple collaborative >> spaces (a standalone discussion board, say) or relatively rigid social >> spaces and centralized administration (a government agency or a >> traditionally bureaucratic company), the two concepts (although >> different in human terms) can be kludged together on the back-end. >> >> Such kludges aren't sustainable in an LMS/CLE because we combine support >> for multiple (pluggable) social contexts with support for multiple >> (pluggable) collaborative applications and services. >> >> Best, >> Ray >> >> On 10/26/09 2:32 AM, Clay Fenlason wrote: >>> The first thing that strikes me, something I've ventured tentatively >>> in the past (it's good to not feel alone), is the idea that roles are >>> a secondary and optional feature of groups. Something about that just >>> seems right to me in concept, though I won't claim to have thought >>> through whether this is ultimately a helpful shift in practice. >>> >>> I think the value of the role is primarily as a simplification for the >>> UX, a metaphorical shortcut to help the user achieve sensible >>> intuitions about a potentially complicated set of permissions. It can >>> be a valuable design artifact, in other words, in many contexts. But >>> it need not be assumed for all group contexts. In cases where the >>> likely intuition might be misleading and harmful, the role might be an >>> active hindrance and might need to be explicitly set aside in favor of >>> a specific permission choice in a particular workflow. Again, that >>> seems to me a design choice in context, and not an inextricable >>> feature of the technical design. What's more, baking the role deeply >>> into the technical design may lead to brittleness where role >>> intuitions are misleading. >>> >>> ~Clay >>> >>> On Sun, Oct 25, 2009 at 11:55 PM, Bristow, Paul <PBristow@...> >>> 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@... >>>> www.csu.edu.au >> >> >> _______________________________________________ >> 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"