[Building Sakai] [DG: User Experience] [Fwd: Re: Groups call]
Oliver Heyer
oliver at media.berkeley.edu
Thu Jun 18 08:07:24 PDT 2009
The call is today/tomorrow, June 18-19.
Oliver
Oliver Heyer wrote:
> The below off list conversation evolved from working out the logistics
> of a synchronous meeting across disparate time zones to topics of
> general interest, including questions of project planning and the
> current state of groups-related work on the K2 demo server at
> http://131.111.21.17:9090/dev/index.html. If you start at the bottom,
> everything should flow pretty well from Matt's initial question, even
> though the indentation hierarchy is off.
>
> The call we are having Thursday PM/Friday AM will allow CSU in Australia
> to explore their interest in participating in the nascent groups project
> at a somewhat less ungodly hour than last Monday's would have required.
> For others wishing to join in today, here are the details:
>
> (2pm Thurs US West Coast / 5 pm US East Coast/ 10pm Thurs Cambridge /Fri
> 7.00 am Sydney).
>
> Telephone: +1-812-856-7060
> Internet:156.56.240.9
> Conference Code: 348#
> PIN: 72524#
>
> Oliver
>
> -------- Original Message --------
> Subject: Re: Groups call
> Date: Wed, 17 Jun 2009 23:18:07 +0100
> From: Ian Boston <ieb at tfd.co.uk>
> To: Oliver Heyer <oliver at media.berkeley.edu>
> CC: Morton-Allen, Matt <MMorton-Allen at csu.edu.au>, Michael Korcuska
> <mkorcuska at sakaifoundation.org>, Bristow, Paul <PBristow at csu.edu.au>
> References: <C65F96A4.12CF4%mmortonallen at csu.edu.au>
> <4A396817.1040304 at media.berkeley.edu>
>
>
>
> Looking at [1] "Manage Site Members" and "Add Site Members" have roles
> which in K2 terms are groups associated with the site. There is detail
> missing here since there is no information on how the roles are
> configured or the permissions managed. I suspect that there has been
> an assumption in these screens that that happens by some other
> mechanism.
>
> If another group was associated it would appear in the list with
> Student, Teacher, Instructor.
>
> but, I think the set at [1] is not complete or upto date, I will still
> need to check with Nico.
> Ian
>
> [1] http://confluence.sakaiproject.org/confluence/x/noVDAw
>
> On 17 Jun 2009, at 23:03, Oliver Heyer wrote:
>
>
>> Pedantic is good in my book, Matt. There's some more detail between
>> 1 and 2, but I'll leave that discussion for the call.
>>
>> BTW, I do not see any existing non course group management screens
>> on http://131.111.21.17:9090/dev/ or at http://confluence.sakaiproject.org/confluence/x/noVDAw
>> . I do see the Connections list for the dashboard, and the Site
>> membership list. Should I be looking elsewhere, Ian?
>>
>> Oliver
>>
>> Morton-Allen, Matt wrote:
>>
>>> Sorry to be pedantic, but just to check that I'm on the same page a
>>> summary of what's being proposed is that we:
>>>
>>>
>>> 1. Capture as many relevant use cases as we can over the next X
>>> time period (X being < "circa end of Sep")
>>> 2. Translate those use cases into requirements
>>> 3. Select (presumably) a sub-set of those requirements we'd like
>>> to have included by "circa end of Sep"
>>> 4. Identify those of #3 that are already part of K2 and modify if
>>> needed
>>> 5. Identify those of #3 not already part of K2 and implement
>>> 6. Work with the UX folks to implement a "front end" for #4 and #5
>>>
>>> (note that steps 4,5,6 would all run with some degree of parallelism)
>>>
>>> Is this right? If it is (or even reasonably close to right) then it
>>> makes a lot of sense to me.
>>>
>>> Cheers
>>> Matt
>>>
>>> On 18/06/09 5:52 AM, "Ian Boston" <ieb at tfd.co.uk> wrote:
>>>
>>> Oh sorry,
>>> IIRC
>>> If I remember correctly.
>>> Ian
>>> On 17 Jun 2009, at 20:07, Oliver Heyer wrote:
>>>
>>>
>>>
>>>> IIRC?
>>>>
>>>> You have described *the* fundamental design challenge we face
>>>> below. :-)
>>>> Oliver
>>>>
>>>> Ian Boston wrote:
>>>>
>>>>
>>>>> That sounds good.
>>>>> My drift.
>>>>> IIRC there are already some non course group editing screens.
>>>>> Groups that integrate as dynamic groups with an SIS will require
>>>>> one or 2 extra properties from a technical perspective.
>>>>> Having 2 places where you edit group associations with sites, would
>>>>> IMHO be a bad thing, but making the project site group UX complex
>>>>> would be bad.
>>>>>
>>>>> As you can see I don't know a great deal about the UX, so as long
>>>>> as you are in close collaboration thats great.
>>>>>
>>>>> Ian
>>>>>
>>>>> On 17 Jun 2009, at 19:00, Oliver Heyer wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Not sure if I'm catching your drift, Ian, but, yes, I think
>>>>>> integrated in the right way will require close collaboration and
>>>>>> frequent, open communication. Quite apart from any formal
>>>>>> structures, we'll either band together as necessary or fail. It
>>>>>> will also require a willingness and capacity to iterate over
>>>>>> designs and code for a good long stretch.
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> Ian Boston wrote:
>>>>>>
>>>>>>
>>>>>>> That sound great, I agree getting the UX right is really hard,
>>>>>>> and I know I am not the right person to be in that space, 4 years
>>>>>>> of training in Mechanical Design Engineering and a year at Fine
>>>>>>> Art school sadly didn't equip me for 2D UX.
>>>>>>>
>>>>>>> Are the Sakai3 UX/UI team getting involved with this initiative,
>>>>>>> it would seem critical to its success to have something this core
>>>>>>> to the UX integrated in the right way?
>>>>>>>
>>>>>>> Ian
>>>>>>>
>>>>>>> On 17 Jun 2009, at 18:02, Oliver Heyer wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Right, my response was largely framed in terms of the UI. That's
>>>>>>>> intentional, because I know that there is a strong desire to
>>>>>>>> have user facing capabilities driven by UX, even those that rely
>>>>>>>> on fundamental enterprise services. Plus, I already know how
>>>>>>>> hard it will be to get the UI right. :-)
>>>>>>>>
>>>>>>>>
>>>
>>>
>
>
>
>
> Oliver,
> Some of the services you mention already exist in K2, although they
> have not been exposed in the UI.
> There is also a complete (almost complete) suite of administration
> utilities written in perl to perform back end push based integration,
> as you can see from the performance testing that has been done [1]
> The pull based integration for groups has been in for a while and I am
> in the process of hooking up to a SOAP end point at the moment.
> As I say, I have a feeling that the functionality is there, it just
> hasn't been addressed in the UI, partially because the setup for many
> of these types of sites is a provisioning operation rather than a Web
> UI operation.... but it still needs a UI for some schools.
>
> Ian
>
>
> [1] work in progress: http://confluence.sakaiproject.org/confluence/display/KERNDOC/225+-+Scalability
>
> On 17 Jun 2009, at 17:20, Oliver Heyer wrote:
>
>
>> To Michael's reply I would add that we and the community need the
>> system to do many very familiar things that ultimately involve
>> groups of users. The team working on groups will not be able to
>> build out all of these capabilities by itself over the next 6 months
>> or year. Our next order of business is to circumscribe the scope for
>> what group management functionality we can design, build and
>> integrate with the prototype at http://131.111.21.17:9090/dev/index.html
>> between now and circa the end of September. The available contexts
>> to build on top of in the K2 prototype are limited, which is
>> probably a good thing, at least in terms of establishing a place to
>> get started. For example, we have no assessment workflow yet, nor is
>> there a system administration area. Some logical first step options
>> we do have include a basic group member picking UI within the site
>> membership page (which may prove highly reusable as a UI design
>> pattern) and a way to represent those groups vis a vis the
>> comprehensive site membership list; the service and UI for attaching
>> SIS provided groups to a site etc. That work will more than likely
>> affect and require changes to some of the existing designs you now
>> see on the above demo server. Similarly, as other contexts emerge
>> and our attention turns to them, anything that's previously been
>> designed and built by the groups team will be subject to further
>> change.
>>
>> Looking forward to chatting.
>>
>> Oliver
>>
>> Michael Korcuska wrote:
>>
>>> No, you're not missing anything Matt. Use cases aren't
>>> requirements, as you say, although they are a crucial test to make
>>> sure the requirements actually meet the need (as well as providing
>>> a way for less technical users to participate in the process).
>>>
>>> I'd say the project probably should add the creation of a
>>> requirements document to the list. There is good thinking to start
>>> that work here:
>>>
>>> http://groups.google.com/group/sakai-kernel/browse_frm/thread/ce886f6325c7b492/fe5ba882f4c3c0c9?lnk=gst&q=sites
>>> +and+groups#fe5ba882f4c3c0c9
>>>
>>> and here:
>>>
>>> http://groups.google.com/group/sakai-kernel/browse_frm/thread/e9d6d13abbbd96dc?hl=en&tvc=1&q=Authorization+and+Relational+Indexes
>>>
>>> (man, Sakai 2 URLs don't look so bad....)
>>>
>>> Other sources for requirements:
>>>
>>> * Oxford's hierarchy work
>>> * IMS LIS
>>> * Existing Sakai 2.x CM implementation (although we should be
>>> careful about what we take forward)
>>>
>>> Getting this thinking consolidated into a single requirements
>>> document that people could read would be a great contribution from
>>> someone :-).
>>>
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>> On Jun 16, 2009, at 23:47, Morton-Allen, Matt wrote:
>>>
>>>
>>>> Thanks Oliver.
>>>>
>>>> I think my issue here is trying to see the forest for the trees.
>>>> There's a lot of use case / user story like material here, which
>>>> is good, but which isn't quite the same thing as the requirements
>>>> that ultimately come from these kinds of documents. Consequently
>>>> I'm having some difficulty in identifying what it is you need the
>>>> system to actually do which in turn makes it difficult for me to
>>>> match between the GA Tech / CSU requirements (and Cambridge model).
>>>>
>>>> From this I suppose what I don't have straight in my mind at the
>>>> moment is the following:
>>>>
>>>> a) how/when/where these use cases will be consolidated into
>>>> implementable requirements?
>>>> b) how those requirements will be mapped against those the K2
>>>> design currently facilitates?
>>>> c) how/where/when the outcomes from B are integrated into the code
>>>> that's currently referred to as "K2"?
>>>>
>>>> I've copied Michael in as it's likely that much of my uncertainty
>>>> relates to community process and how the move from K2 + 3akai to
>>>> foundation S3 is going to work.
>>>>
>>>> Cheers
>>>> Matt
>>>>
>>>> P.S. Yes, sorry about the "subject" trick, it hurts our brains to
>>>> think of "course" sites as this is something entirely different
>>>> for us. :)
>>>>
>>>>
>>>> On 16/06/09 10:14 AM, "Oliver Heyer" <oliver at media.berkeley.edu>
>>>> wrote:
>>>>
>>>> Matt,
>>>>
>>>> Yes, I have seen that google page. From our end, I would point you
>>>> again to
>>>>
>>>> http://confluence.sakaiproject.org/confluence/x/FIJDAw
>>>>
>>>> particularly the Federated AuthZ link at the bottom. We have not
>>>> attempted a comprehensive high level description of our current site
>>>> hierarchy, SIS/ID management integration, course life cycle etc
>>>> requirements at UCB. I *think* the CSU reqs on the K2 page are
>>>> familiar,
>>>> even with that neat trick of calling course sites "subject
>>>> sites." :-)
>>>> I'm not sure if the CSU requirements have been adequately
>>>> represented or
>>>> accounted for in the use cases we've compiled thus far. If the above
>>>> link leaves you with more questions than answers, when we chat I
>>>> hope to
>>>> clear them up or figure out which ones we still need to provide an
>>>> answer for.
>>>>
>>>> Oliver
>>>>
>>>> Morton-Allen, Matt wrote:
>>>>
>>>>> Oliver,
>>>>>
>>>>> BTW I'm not sure if you have seen these or not but Ian's put up a
>>>>> page on the basics of the CSU group requirements here:
>>>>>
>>>>> http://groups.google.com.au/group/sakai-kernel/web/csu-site-user-and-groups-requirements?hl=en
>>>>>
>>>>> Is there an equivalent for the Berkley ones we can look at?
>>>>>
>>>>> Cheers
>>>>> Matt
>>>>>
>>>>>
>>>>>
>>>>>
>
> _______________________________________________
> 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"
>
More information about the sakai-dev
mailing list