[DG: User Experience] Sakai 3 community contexts - what are sites?
Oliver Heyer
oliver at media.berkeley.edu
Thu Feb 25 09:31:52 PST 2010
A garbled edit. Should read:
I suppose you could supply a configuration or rule that turned off the subgrouping piece of the workflow, but I wonder
who would choose to do that.
Oliver Heyer wrote:
> Ian,
>
> I am definitely not a) and have unfounded pretensions to b). The local
> team would probably deny me c) :-)
>
> The entire set of designs and workflow suggest that the groups that
> appear in the dropdown are subgroups. I would venture to say that the
> ability to subgroup is one of the key pedagogical use cases for user
> management. If any institution were to choose simultaneously to support
> the subgrouping in the UX designs, and to treat all groups atomically, I
> have a hard time imaging a sensible UX emerging out of that, much less
> one that worked as a first class complement to one that acknowledged the
> hierarchical dependencies between some groups.
>
> I suppose you could supply a configuration or rule that turned off the
> ability to turn off the subgrouping piece of the workflow, but I wonder
> who would choose to do that.
>
> So in sum, yes, I understand your argument, but I'm still not sure that
> this is a level of configurability the UX should support.
>
> Oliver
>
>
>
> Ian Boston wrote:
>
>> On 25 Feb 2010, at 15:34, Oliver Heyer wrote:
>>
>>
>>
>>> Ahh, sorry-- this is the page I meant:
>>>
>>> https://source.sakaiproject.org/contrib/sakai3ux/trunk/Groups_Instructor_Create_04/View_group_members_list_[by_arranged].html
>>>
>>> I am wondering if the problem being discussed isn't more fundamental than one of institutional preferences. Thanks,
>>>
>>>
>> Oliver,
>>
>> Ahh Ok. So what I say now is as a person working in University who has listened to *some* of the use cases that exist rather than a a) back end developer b) an expert in groups within a University context, c) someone who knows anything about UX design.
>>
>> A.
>> If depends on what "DNA Research Group" is.
>>
>> If its a a grouping of researchers from 3 independent projects "Chromasonal DNA", "Mitocontrial DNA" and "Sitochondiral DNA" then when "DNA Research Group" is deleted the others would continue to exist.
>>
>> If is a grouping a individuals, subgrouped into area of interest for a conference, the the subgroups might be deleted when "DNA Research Group" is deleted.
>>
>> And who knows what might happen then, should they be elevated, or not ?
>>
>> Or it could be a mixture of the 2, or something entirely different.
>>
>> The point I was trying to make was there is a vast range of ways in which humans group themselves, collaborate and view the existence and relationships between those groups, hence I was suggesting, where there are rules (as opposed to none at all), then those rules should be selectable or configurable by the institution/user?
>>
>> DNA Research Group .... is a ......... interdisciplinary team consisting of pre-exisitng groups (which implies a suitable set of rules to its behaviour and makeup)
>>
>> Biology Study Group ....... is a ........ Second Year course study group in the Department of Life Sciences.
>>
>> Does that make any sense ?
>> In a sense it is more fundamental than Institutional Preferences, we cant afford to cover every possible use case in detail, there are too many.
>> Ian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Oliver
>>>
>>> Ian Boston wrote:
>>>
>>>
>>>> On 24 Feb 2010, at 16:06, Oliver Heyer wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On this page
>>>>>
>>>>> https://source.sakaiproject.org/contrib/sakai3ux/trunk/Groups_Instructor_Create_04/index.html
>>>>>
>>>>>
>>>>>
>>>> Oliver,
>>>> Which page are you talking about, the url is for the outer frameset with the first page "My people and Groups" highlighted.
>>>>
>>>> An example of a URL that takes the reader to a page is
>>>> https://source.sakaiproject.org/contrib/sakai3ux/trunk/Groups_Instructor_Create_04/Create_a_group_[details_added].html
>>>>
>>>> Thanks
>>>> Ian
>>>>
>>>>
>>>>
>>>>
>>>>> if the DNA research group in the left navigation tree is deleted, what are the various rules that might apply to the teams/subgroups (DNA Project Teams, Cell Labs, Study Groups etc.) in the open drop down of the right hand panel ? In one case, would they automatically be elevated to be first order members of the navigation tree on the left?
>>>>>
>>>>> Oliver
>>>>>
>>>>> Ian Boston wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Ray,
>>>>>> I think you have identified a number of rules associated with how groups relate to one another. I would like to propose that rather than hard coding this into the code, they remain as a replaceable rules packages (using the rules engine due to be integrated in May) so that institutions can agree to differ. My fear is there are subtle differences in your description of requirements/needs/behaviour and that of others. If you try and create a system that covers 100% of everyones use cases you will "die trying", and if it enforces one institutions view it will be of less use to others.
>>>>>>
>>>>>> If we can agree that institutions differ, then the message that needs to go to back to the UX designers is that they *might* want to consider giving a use the option of specifying the nature of a group and consequently the rule set the it obeys.
>>>>>>
>>>>>> The second observation is, IMVHO, Jackrabbits groups only become authorisation focused when they are associated with ACL's prior to that they are just groups with membership, metadata and no rules. You appear to be suggesting that a parallel groups implementation is required which IMVHO will be a mistake.
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>> On 23 Feb 2010, at 17:34, Ray Davis wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The distinction between "subgroups" and "member groups" (or "external feed groups") seems clear to me, but that may be a sign of having worked here too long. :)
>>>>>>>
>>>>>>> * Subgroups (as opposed to "feed groups") should go away if the parent group goes away. That's a definitional requirement, not an arbitrary limitation. If someone deletes a self-managed top-level community ("This Year's Models", say, with "Designers" and "Fabric Cutters" subgroups), the subgroups would be unreachable. (If you need to reach the old subgroup definitions, the same need would be there for the top-level group and they would all presumably be handled the same way in versioned history.) If next year someone else creates a different top-level community with the same name, the old subgroups would be distracting at best and disastrous at worst. (Remember, this doesn't necessarily mean losing access to content created by the group: we're planning on better sharing of resources among multiple groups and individuals, so that, for example, a syllabus written for a class that gets dropped by the registrar might still remain part of the department's reference library
>>>>>>>
> and part of the author's portfolio.)
>
>>>>>>> * Subgroup memberships are restricted to the parent group's membership. Again, this is not an arbitrary rule. If I want to divide up students and teaching assistants into project teams, I need to be able to rely on the idea of "members in the class." If a student drops the class or a teaching assistant quits the job, I don't want to keep seeing them in an apparently full (but now short-handed) project team.
>>>>>>>
>>>>>>> * Category rules or operations can be applied to subgroups. Most notoriously, "site members" might need to have a role, and if roles are implemented internally as groups, that means a rule that "each site member must be in one and only one of these groups." We have similar less-notorious requirements for class sections and project teams.
>>>>>>>
>>>>>>> I agree that some of these aspects might also apply to other sorts of entities. But they do all come together in the subgrouping use cases we've gathered, and none of them have out-of-the-box equivalents in Jackrabbit's authz-focused groups (for the good reason that such functions have nothing to do with the Jackrabbit project's goals).
>>>>>>>
>>>>>>> Best,
>>>>>>> Ray
>>>>>>>
>>>>>>> On 2/22/10 11:29 PM, Bristow, Paul wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Ray,
>>>>>>>>
>>>>>>>> Again, as you've said, we probably agree more than we disagree but I think there's a risk taking groups as far as can be done based on use cases predicated on a sakai2-ish view of sites may mean a complete rethinking and reimplementation of groups later. The requirements (including ours) seem to come from a traditional groups within site focus. I may be being unfair in this perception but the requirements seem focused on in site management of groups and without considering how sites might be different in sakai3 this seems likely to be limited.
>>>>>>>>
>>>>>>>> But I also agree there's value in building group functionality now, it's just that it may change with further analysis :) And there's a contradiction in my arguing that we can't do groups properly until we've defined sites at the same time as I'm arguing that they're independent entities...
>>>>>>>>
>>>>>>>> Is the specific subgroup functionality you want ... automatic removal from a subgroup if a member is removed from the parent? Otherwise I'm failing to see why subgroups being independent principals is a bad thing. I thought there was a requirement that external users could be added to subgroups (John's porosity) which seems to force this behaviour.
>>>>>>>>
>>>>>>>> (personally I think these sorts of rules could be useful for all groups but this could complicate things compared to quarantining the complex bits in sub groups)
>>>>>>>>
>>>>>>>> My concern with subgroups is that the whole group concept is recursive. Groups can be members of groups - its implicit in the group implementation with sling and in Ian's documentation from some time ago for how groups and sites could fit together. It seems to me that it adds complexity to the group model to add a specific type of subgroup which isn't a fully fledged group.
>>>>>>>>
>>>>>>>> ----------------------------------------------------
>>>>>>>> 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
>>>>>>>> ----------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: sakai-ux-bounces at collab.sakaiproject.org [mailto:sakai-ux-
>>>>>>>>> bounces at collab.sakaiproject.org] On Behalf Of Ray Davis
>>>>>>>>> Sent: Tuesday, 23 February 2010 4:20 AM
>>>>>>>>> To: sakai-ux at collab.sakaiproject.org
>>>>>>>>> Subject: Re: User Experience] User Experience] Sakai 3 community
>>>>>>>>> contexts - what are sites?
>>>>>>>>>
>>>>>>>>> My reasons for keeping the concept of a designated "site" or "space"
>>>>>>>>> match yours, Paul: even in a world of individual people, groups,
>>>>>>>>> resources, and pluggable applications, it still seems needed for
>>>>>>>>> templating and access control requirements. I'd like to try
>>>>>>>>> prioritizing
>>>>>>>>> the personal/group dashboards as much as possible, though, just to see
>>>>>>>>> how far they can be taken.
>>>>>>>>>
>>>>>>>>> Group interchange standards: No, not a lot out there. An LMS/CLE hits
>>>>>>>>> serious issues with federated membership-role authz faster than any
>>>>>>>>> other domain space I've known; social networking sites and Google Apps
>>>>>>>>> are just now having to grapple with the problems. What I found in
>>>>>>>>> surveying the community is that the interchange approaches tended to
>>>>>>>>> vary somewhat depending on which type of integration we were talking
>>>>>>>>> about. So IMS LIS should help quite a bit with typical academic
>>>>>>>>> hierarchies like class enrollments, but not so much with residency-
>>>>>>>>> based
>>>>>>>>> communities or non-instructional staffing or research teams.... And IMS
>>>>>>>>> LIS won't magically solve the authz issues that occur when you mix two
>>>>>>>>> independent role-sources at a single resource (e.g., creating a shared
>>>>>>>>> site for "Chem 304" and "Bio 1a"). On a personal note, the challenge of
>>>>>>>>> federated groups is what interests me most about working on Sakai 3. :)
>>>>>>>>>
>>>>>>>>> I've been defining a sub-group as a group whose definition is dependent
>>>>>>>>> on a parent group. This is different from a membership-feed (where
>>>>>>>>> members come and go based on membership changes in a different,
>>>>>>>>> independent group). Note that there's no sub-group concept built into
>>>>>>>>> Jackrabbit groups: a group can have other groups as members, but
>>>>>>>>> Jackrabbit treats those members as independent principals.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Ray
>>>>>>>>>
>>>>>>>>> On 2/21/10 10:26 PM, Bristow, Paul wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It seems to me we still haven't really defined 'what a site is for'
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> in sakai 3 so we still have a degree of sakai 2 site centricity in
>>>>>>>>> working out the relationship between groups and sites. The scenarios
>>>>>>>>> seem to assume creating groups as part of the process of creating a
>>>>>>>>> site and creating subgroups within a site. Both of these are important
>>>>>>>>> use cases but I think they're part of the site group relationship, not
>>>>>>>>> the totality of it. Focusing on these leads to thinking of groups as
>>>>>>>>> secondary objects, subservient to sites.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I believe sites, groups and content can all be first class objects in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> the sakai 3 environment and should be able to be mixed and matched at
>>>>>>>>> will, unconstrained by any historical creation context (although this
>>>>>>>>> may be enforced for particular business cases). In particular I believe
>>>>>>>>> sites, groups and content can have separate lifecycles and groups and
>>>>>>>>> content can persist beyond the life cycle of a site in whose context
>>>>>>>>> they were created.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> But my primary question is still 'what is a site for?' (or 'for what
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> is a site?'?)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> My feeling is that a site provides:
>>>>>>>>>> A context for creating and managing content
>>>>>>>>>> Something that can be provisioned to link resources to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> teaching needs eg course sites
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> A way in which users can discover and access content (but
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> perhaps not the only way)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> A way to provide default access control rules for content
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> published in the site context
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Something that can be provisioned with a template which can
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> enforce various enterprise rules about predefined content/services,
>>>>>>>>> read only vs modifiable content/services, available site roles, groups
>>>>>>>>> to create or link at site creation etc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The last point is functionality that could be provided by creating
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> sites from templates according to a type. So a template for a site type
>>>>>>>>> would define the institutional rules for the creation of sites.
>>>>>>>>> Technically I don't think a site needs to remain the type it was
>>>>>>>>> created (unless its template provides that it be locked down).
>>>>>>>>> Technically a site could evolve into something different - a course
>>>>>>>>> site in sakai 3 could become something different over time - the
>>>>>>>>> 'courseiness' is to do with the choices made when provisioning it, not
>>>>>>>>> something that has to last forever.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I kind of hope eventually there will be the potential for users to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> mash up all their content into their 'workspace' or portal site and
>>>>>>>>> personalise it to suit the way in which they interact with it. In this
>>>>>>>>> scenario sites as created/provisioned become default UI for access
>>>>>>>>> until the workspace or portal is configured and access points for use
>>>>>>>>> cases where we want to lock users into a fixed UI for a particular
>>>>>>>>> workflow, for instance examination or payment processes. Users may
>>>>>>>>> choose to manage content within site space to take advantage of site
>>>>>>>>> based access control rules.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Lastly groups. As others have suggested there are social and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> institutional groups. Within our situation at CSU we have dynamic
>>>>>>>>> groups which are populated automatically according to rules and user
>>>>>>>>> attributes. Some of these groups may be potential until someone chooses
>>>>>>>>> to make them concrete.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> When looking at social groups and externally provisioned groups I
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> think we suffer from a lack of external group interchange standards
>>>>>>>>> (has IMS addressed this). I think there's been thought of importing
>>>>>>>>> groups from external sources, ideally we should be looking at
>>>>>>>>> federating groups
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I think there are also use cases for allowing self addition and self
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> removal from groups, subject to an institutions business rules.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Are subgroups groups in their own right or some limited form of
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> group?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------
>>>>>>>>>> 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
>>>>>>>>>> ----------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: sakai-ux-bounces at collab.sakaiproject.org [mailto:sakai-ux-
>>>>>>>>>>> bounces at collab.sakaiproject.org] On Behalf Of John Norman
>>>>>>>>>>> Sent: Monday, 22 February 2010 5:42 AM
>>>>>>>>>>> To: Sakai UX
>>>>>>>>>>> Subject: Re: User Experience] Sakai 3 community contexts
>>>>>>>>>>>
>>>>>>>>>>> Separating groups from sites was a primary goal of Sakai 3.
>>>>>>>>>>> 'Communities' as sets of people is the same as groups.
>>>>>>>>>>> Groups/communities may or may not have sites. But groups/communities
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> sets of people is a 'people' thing. The problem with having 'groups'
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> the top level rather than 'people' is that sometimes you want to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> find
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> individuals by some means other than a context/community.
>>>>>>>>>>>
>>>>>>>>>>> I can see the argument that in courses and sites we do put the
>>>>>>>>>>> aggregate at the top (sites rather than pages), that still feels
>>>>>>>>>>> natural. If Rebecca Jones shares a group with me (e.g. Morris
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> dancing
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> society) I am still more likely to expect to find her by name
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> (people)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> than by looking through the membership of the Morris dancing
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> group(s).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> OTOH I am more likely to look for the Morris dancing site to find
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> discussion on the latest excursion, rather than searching an index
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> individual pages (or am I?)
>>>>>>>>>>>
>>>>>>>>>>> Perhaps the main point I am making is "Yes we have communities, but
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> we
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> also have individuals"
>>>>>>>>>>>
>>>>>>>>>>> Make sense?
>>>>>>>>>>>
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>> On 21 Feb 2010, at 17:24, Oliver Heyer wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The information architecture question the more fully illustrated
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> set
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> of potential community contexts raises for me is similar to Clay's.
>>>>>>>>>>> More specifically, why do we need separate "People" and "Courses and
>>>>>>>>>>> Sites" tabs? Could they be replaced with a set of the "Communities"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> participate in?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Oliver
>>>>>>>>>>>>
>>>>>>>>>>>> John Norman wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> If I look at even our most recent header bar, "People," "My
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> Courses
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> and Sites," "My Content& Media," etc., I'm inclined to think
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> list could be improved if it were replaced with some of Ray's
>>>>>>>>>>>>>> community contexts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ~Clay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Well you could do it that way, but then you would want the headers
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> as cross cutting themes across the contexts. In other words this is
>>>>>>>>>>> (multi-dimensional) matrix-land and one axis has to be on top. For
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> me
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> the key thing that leads to the Who (People), What (Content), Where
>>>>>>>>>>> (Sites), When (Events) going at the top is that for any individual,
>>>>>>>>>>> their University experience is some fairly unique mixture of a large
>>>>>>>>>>> number of potential contexts. So for me context is a side axis (i.e.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> cross-cutting concern) and not a top axis (a small and universal
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> set).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> John
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> sakai-ux mailing list
>>>>>>>>>>>>> sakai-ux at collab.sakaiproject.org
>>>>>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>>>>>>>>>
>>>>>>>>>>>>> TO UNSUBSCRIBE: send email to sakai-ux-
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Oliver Heyer
>>>>>>>>>>>> Manager, Learning Systems Group
>>>>>>>>>>>> Educational Technology Services
>>>>>>>>>>>> U.C. Berkeley
>>>>>>>>>>>> (510) 529-5177
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> sakai-ux mailing list
>>>>>>>>> sakai-ux at collab.sakaiproject.org
>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>>>>>
>>>>>>>>> TO UNSUBSCRIBE: send email to sakai-ux-
>>>>>>>>> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai-ux mailing list
>>>>>>> sakai-ux at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>>>
>>>>>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-ux mailing list
>>>>>> sakai-ux at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Oliver Heyer
>>>>> Manager, Learning Systems Group
>>>>> Educational Technology Services
>>>>> U.C. Berkeley
>>>>> (510) 529-5177
>>>>>
>>>>> _______________________________________________
>>>>> sakai-ux mailing list
>>>>> sakai-ux at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>>>
>>>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> --
>>> Oliver Heyer
>>> Manager, Learning Systems Group
>>> Educational Technology Services
>>> U.C. Berkeley
>>> (510) 529-5177
>>>
>>>
>>>
>>
>>
>
>
--
Oliver Heyer
Manager, Learning Systems Group
Educational Technology Services
U.C. Berkeley
(510) 529-5177
More information about the sakai-ux
mailing list