[Building Sakai] [Fwd: Re: Groups call]
Oliver Heyer
oliver at media.berkeley.edu
Thu Jun 18 07:54:07 PDT 2009
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
>>>>
>>>>
>>>>
More information about the sakai-dev
mailing list