Re: [DG: User Experience] Randomly assigning students to groups
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
|
|
|
Re: [DG: User Experience] [Using Sakai] Randomly assigning students to groups
by dktr adam marshall
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Randomly assigning students to groups
by jrnorman
::
Rate this Message:
|
|
|
[DG: User Experience] Some thoughts on group functionality
by Bristow, Paul
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by clayf
::
Rate this Message:
|
|
|
Re: [DG: User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by Bristow, Paul
::
Rate this Message:
|
|
|
Re: [DG: User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by Michael Feldstein-2
::
Rate this Message:
Two comments here. First, on the difference between the technical sense
and the human sense, the LMS will be given information about the "human
sense" roles (e.g., student, instructor, teaching assistant,
administrator, etc.) from the SIS via the LIS standard. This
information maps to permissions in many but not all cases. In some
cases it may be important to provide this data in human readable form
but less important for the system to represent these roles as distinct
permissions structures. So it will be important for us to develop
language that makes it easy for us to know which sense we are
discussing whenever we are talking about roles.
Second, when Paul talks about defining separate groups for a resource or service and then using them for the appropriate ACLs, this sounds to me a bit like Bodington. (I could easily be wrong here.) Bodington's system has very powerful affordances but at a cost of usability. My sense is that Moodle also implemented a (possibly piecemeal) approach to to roles and permissions that may approximate this scheme, at least from a functional perspective. It may be helpful to get comments from folks on list who know more about these systems than I do. It's worth noting that Sakai 2's more flexible roles and permissions system was frequently cited by users as a big advantage over Blackboard in UNC's recent evaluation, I'm not sure exactly what this means, in part because I lack recent hands-on experience with Sakai's roles and permissions, but it may be worth looking at closely. I'd like to understand exactly where the locus of value is and what kinds of complexity were seen to be useful and not confusing. - m Bristow, Paul wrote: Clay, I think there are typically two senses in which we talk of roles. In a technical sense we bundle a set of permissions into a role for ease of management - your simplification for the UX (although it's equally helpful at the backend). In it's simplest sense this is like granting a dba role in a database - the role grants the same permissions to all members globally. In a more sophisticated usage the role is a template for the application of a set of meta permissions to create permissions in the context of a specific resource or activity. In a more human sense people fulfil roles in the context of activities of groups. So in an academic sense we have teachers and students. In clubs we have presidents, secretaries, etc. The two definitions blend when we use a templated set of permissions to give members of a group the permissions they need to fulfil their role in a group activity. It is quite possible for members of a group to change roles over time and also to have multiple simultaneous roles. If we manage roles within groups we need agreement on the semantics of the roles between the groups system and the activity or resource where the permissions have meaning. Also we need a set of methods to manage roles in the context of a user's membership of a group (and the context of the resource or activity). My suggested group model could accommodate roles as metadata on the membership objects. But I don't think this is appropriate for the k2 authorisation model. The JCR ACL as I understand it allows us to add a group to a 'role' for a resource but does not have the functionality or the expectation of assigning different roles or permissions according to attributes of individual's membership within the group. More importantly in the long term, k2 should be generic to meet future needs and should not have today's role semantics built into its core functionality. The alternative is to define separate groups for each role for a resource or service and use them for the appropriate ACLs. We can create a supergroup of all members of a site or service just by creating a group and adding the 'role groups' as members . Within k2 we should have separate groups for each role for 'sites' and similar services, along with a group which is the union of these groups. (This is how I interpret Ian's site group diagrams). In the set of templates used to create sites and other resources there should be templates of permissions associated with the resource and templates for the definition of groups to align with expected usage roles and permission requirements. This keeps the 'role' expectations in the data rather than the code and hopefully avoids building today's limitations into the kernel. Roles within groups may be useful for other aspects of membership and can still be supported subject to functionality to manage the extended attributes to support them. But we should consider that there may uses for group functionality which don't relate to permissions and where role is irrelevant - we should be cautious about requiring them in groups Paul ________________________________________ From: sakai-ux-bounces@... [sakai-ux-bounces@...] On Behalf Of Clay Fenlason [khomotso@...] Sent: Monday, October 26, 2009 8:32 PM To: sakai-ux UX Subject: Re: User Experience] [Using Sakai] Some thoughts on group functionality 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 ---------------------------------------------------- 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@... http://collab.sakaiproject.org/mailman/listinfo/sakai-user TO UNSUBSCRIBE: send email to sakai-user-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" _______________________________________________ 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" --
 Michael Feldstein | Principal Product Manager | +1.818.817.2925 Oracle Academic Enterprise Solutions Group 23A Glendale Road, Glendale, MA 01229 _______________________________________________ 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] User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by Bristow, Paul
::
Rate this Message:
|
|
|
Re: [DG: User Experience] User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by Michael Feldstein-2
::
Rate this Message:
Will we see the LIS publicly released as part of 'LIS Alliance will be launched in October 2009'? Perhaps LIS already addresses this broader functionality? The LIS working group has set the end of the calendar year as our (latest) goal for releasing a public draft. The main hurdle we have to overcome right now is documentation. There's a kind of release readiness process in the IMS, where documentation is obviously one of the requirements. We have the base specification documents done, but these are massive--over 800 pages, I think--and the vast majority of the information is irrelevant to anyone who just wants to implement a typical SIS-to-LMS integration. (LIS has a lot of forward-looking stuff in it and some formalisms that make it more extensible, testable, etc., at the cost of being long and dense.) We're in the process of documenting a conformance profile which will be the small subset (maybe 5% to 10%) of the base specification that's necessary for LMS/SIS integration. LIS is intended to provide two things:
Yes, this is one of the main things that it does.Does LIS provision membership of course groups? Ray Davis attended the IMS meeting at Oracle HQ this week, in part to explore this idea explicitly.If so I think the Group System would interact with the SIS directly. Yeah, that's roughly the idea, I think. Again, though, the roles provided by the SIS should be viewed as semantic hints in the learning system and not necessarily determinative of ACLs in the group management system. For example, it may or may not be appropriate to give a teaching assistant different permissions than an instructor (as the SIS understands these roles) in a given course site. Ideally, your roles UI would see the role information sent from the SIS and offer the user a default mapping with an option to override. But your course site could still display that a particular user is a "teaching assistant" because this could be useful information to the humans using the system even if the permissions are unaffected.LMS - SIS interaction would include provisioning sites. Perhaps sakai 3 could have an LIS aware site provisioner where LIS identified the groups to include in ACLs and created them in the group management system? Something similar could be done with LIS section association, where the SIS tells the LMS "these two course sections are related to each other". The Sakai instructor could be given the default that these sections would be merged into one course site with the option to override. - m Bristow, Paul wrote: Yes, this whole field is full of ambiguous terms so we ideally need a reference glossary with clearly defined terms and meanings. I think a Groups System may (and will) be provisioned with human sense roles for groups (common or separate) associated with teaching roles eg student, instructor via the LMS through LIS or from the SIS directly, perhaps through LIS. LMS services may associate those roles with permissions also possibly accessing the role semantics through LIS. But a Groups System should not need to be confined in scope to the LMS (even assuming sakai 3 scope is limited to LMS functionality) and roles within the LMS should not be confined to roles from the SIS. Ideally a group management system should be whole of enterprise and cooperating with group and identity systems external to the enterprise. New groups and new roles should be able to be defined as required and not necessarily together. Groups and roles may be sourced from other systems within and outside the LMS, the SIS and the enterprise. There are more groups and more roles than our SISs know about and more group use cases than just our LMSs. I think groups and identity are fundamental to the activities and relationships on which our organisations are built and should be able to be integrated, leveraged and reused across all our systems. While I don't expect to get there tomorrow I don't want new systems requiring limited functionality as a feature. This is why I'd prefer generic interfaces with included implementations that can be replaced or extended as we mature. It's also why I'd prefer to try to keep clean interfaces with clearly defined linkages between groups, roles and permissions as far as is practical. So we can define basic group and group management functionality. We can overlay human sense role information as attributes on group membership which 'functionality' that's aware of the semantics of that role information can use to customise behaviour according to how it understands the role. We can have authorisation or permission systems that use this role information at the cost of limiting them to known role semantics. We can have authorisation or permission systems that just link groups to permissions without needing to know anything about these roles. We can use the 'template role' concept to drive provisioning services to provision groups and ACLs for services based on standard 'template roles' for the service. And we can link any group to any ACL for any resource. I think it's important that UI designs simplify possibilities to support ease of use. I think it's important that back end designs be generic enough to support changing use. UI designs should limit functionality according to context. Will we see the LIS publicly released as part of 'LIS Alliance will be launched in October 2009'? Perhaps LIS already addresses this broader functionality? Does LIS provision membership of course groups? If so I think the Group System would interact with the SIS directly. LMS - SIS interaction would include provisioning sites. Perhaps sakai 3 could have an LIS aware site provisioner where LIS identified the groups to include in ACLs and created them in the group management system? Paul ________________________________________ From: sakai-ux-bounces@... [sakai-ux-bounces@...] On Behalf Of Michael Feldstein [michael.feldstein@...] Sent: Tuesday, October 27, 2009 12:55 AM To: Bristow, Paul Cc: sakai-ux UX Subject: Re: User Experience] User Experience] [Using Sakai] Some thoughts on group functionality Two comments here. First, on the difference between the technical sense and the human sense, the LMS will be given information about the "human sense" roles (e.g., student, instructor, teaching assistant, administrator, etc.) from the SIS via the LIS standard. This information maps to permissions in many but not all cases. In some cases it may be important to provide this data in human readable form but less important for the system to represent these roles as distinct permissions structures. So it will be important for us to develop language that makes it easy for us to know which sense we are discussing whenever we are talking about roles. Second, when Paul talks about defining separate groups for a resource or service and then using them for the appropriate ACLs, this sounds to me a bit like Bodington. (I could easily be wrong here.) Bodington's system has very powerful affordances but at a cost of usability. My sense is that Moodle also implemented a (possibly piecemeal) approach to to roles and permissions that may approximate this scheme, at least from a functional perspective. It may be helpful to get comments from folks on list who know more about these systems than I do. It's worth noting that Sakai 2's more flexible roles and permissions system was frequently cited by users as a big advantage over Blackboard in UNC's recent evaluation, I'm not sure exactly what this means, in part because I lack recent hands-on experience with Sakai's roles and permissions, but it may be worth looking at closely. I'd like to understand exactly where the locus of value is and what kinds of complexity were seen to be useful and not confusing. - m Bristow, Paul wrote: Clay, I think there are typically two senses in which we talk of roles. In a technical sense we bundle a set of permissions into a role for ease of management - your simplification for the UX (although it's equally helpful at the backend). In it's simplest sense this is like granting a dba role in a database - the role grants the same permissions to all members globally. In a more sophisticated usage the role is a template for the application of a set of meta permissions to create permissions in the context of a specific resource or activity. In a more human sense people fulfil roles in the context of activities of groups. So in an academic sense we have teachers and students. In clubs we have presidents, secretaries, etc. The two definitions blend when we use a templated set of permissions to give members of a group the permissions they need to fulfil their role in a group activity. It is quite possible for members of a group to change roles over time and also to have multiple simultaneous roles. If we manage roles within groups we need agreement on the semantics of the roles between the groups system and the activity or resource where the permissions have meaning. Also we need a set of methods to manage roles in the context of a user's membership of a group (and the context of the resource or activity). My suggested group model could accommodate roles as metadata on the membership objects. But I don't think this is appropriate for the k2 authorisation model. The JCR ACL as I understand it allows us to add a group to a 'role' for a resource but does not have the functionality or the expectation of assigning different roles or permissions according to attributes of individual's membership within the group. More importantly in the long term, k2 should be generic to meet future needs and should not have today's role semantics built into its core functionality. The alternative is to define separate groups for each role for a resource or service and use them for the appropriate ACLs. We can create a supergroup of all members of a site or service just by creating a group and adding the 'role groups' as members . Within k2 we should have separate groups for each role for 'sites' and similar services, along with a group which is the union of these groups. (This is how I interpret Ian's site group diagrams). In the set of templates used to create sites and other resources there should be templates of permissions associated with the resource and templates for the definition of groups to align with expected usage roles and permission requirements. This keeps the 'role' expectations in the data rather than the code and hopefully avoids building today's limitations into the kernel. Roles within groups may be useful for other aspects of membership and can still be supported subject to functionality to manage the extended attributes to support them. But we should consider that there may uses for group functionality which don't relate to permissions and where role is irrelevant - we should be cautious about requiring them in groups Paul ________________________________________ From: sakai-ux-bounces@...sakai-ux-bounces@... [sakai-ux-bounces@...sakai-ux-bounces@...] On Behalf Of Clay Fenlason [khomotso@...khomotso@...] Sent: Monday, October 26, 2009 8:32 PM To: sakai-ux UX Subject: Re: User Experience] [Using Sakai] Some thoughts on group functionality 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@...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@...pbristow@... www.csu.edu.au<http://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@...sakai-user@... http://collab.sakaiproject.org/mailman/listinfo/sakai-user TO UNSUBSCRIBE: send email to sakai-user-unsubscribe@...sakai-user-unsubscribe@... with a subject of "unsubscribe" _______________________________________________ sakai-ux mailing list sakai-ux@...sakai-ux@... http://collab.sakaiproject.org/mailman/listinfo/sakai-ux TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...sakai-ux-unsubscribe@... with a subject of "unsubscribe" _______________________________________________ sakai-ux mailing list sakai-ux@...sakai-ux@... http://collab.sakaiproject.org/mailman/listinfo/sakai-ux TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...sakai-ux-unsubscribe@... with a subject of "unsubscribe" -- [cid:part1.03050208.04040101@...]<http://www.oracle.com> Michael Feldstein | Principal Product Manager | +1.818.817.2925 Oracle Academic Enterprise Solutions Group 23A Glendale Road, Glendale, MA 01229 --
 Michael Feldstein | Principal Product Manager | +1.818.817.2925 Oracle Academic Enterprise Solutions Group 23A Glendale Road, Glendale, MA 01229 _______________________________________________ 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] Some thoughts on group functionality
by Ray Davis
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by jrnorman
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by Ray Davis
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by Bristow, Paul
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by Ray Davis
::
Rate this Message:
|
|
|
Re: [DG: User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by Bristow, Paul
::
Rate this Message:
|
|
|
Re: [DG: User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by jrnorman
::
Rate this Message:
|
|
|
Re: [DG: User Experience] User Experience] [Using Sakai] Some thoughts on group functionality
by Michael Feldstein-2
::
Rate this Message:
John Norman wrote:
LIS is SOA. It's SOAP-based with well defined service operations, and it is explicitly designed to translate from SIS expectations/standards/norms to those of the LMS, though there's more work in that regard on groups translation than on roles. The information LIS supplies about "roles" is not really identity management information in the sense that it doesn't map directly and predictably to permissions. We're talking about two distinct (though related) meanings of the word "role." So LIS is an example of your point, not an exception to it.At first sight, I can imagine an argument that says we only expect to receive and supply groups and memberships. Roles and permissions in an external system have no constraint that means they have to conform to Sakai expectations/standards/norms. I'm curious about use cases that would make the translation (and translation maintenance) task worthwhile. If they exist, it feels like a case for SOA, but I can imagine that we deliberately support selected exceptions such as LIS. - m --
 Michael Feldstein | Principal Product Manager | +1.818.817.2925 Oracle Academic Enterprise Solutions Group 23A Glendale Road, Glendale, MA 01229 _______________________________________________ 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] User Experience] [Using Sakai] Some thoughts on group functionality
by Ray Davis
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by Ray Davis
::
Rate this Message:
|
|
|
Re: [DG: User Experience] [Using Sakai] Some thoughts on group functionality
by clayf
::
Rate this Message:
|
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
