[Building Sakai] Terminology clarification [was: Groups Call]
Daphne Ogle
daphne at media.berkeley.edu
Fri Jun 19 13:09:22 PDT 2009
Agreed. And great idea!
I'll set up a glossary page later today also and so we can start
making sense of our various terminology.
-Daphne
On Jun 19, 2009, at 10:58 AM, Oliver Heyer wrote:
> John,
>
> Agreed, ultimately we are talking about a means to an end. But I do
> think the semantics are important in a couple of respects. First,
> when others wish to contribute "use cases," we'd like to make sure
> that there's some measure of consistency to what's provided. You can
> already see the proliferation of documentation around "requirements"
> and "use cases" with varying formats and degrees of granularity. It
> will be up to the project team to organize these materials and make
> them legible and useful for development, but better inputs will ease
> that burden. Second, you raise the issue of actors. Clearly, we will
> soon need to settle on some OOTB roles. CSU has the notion of a
> "subject coordinator" . . . I think we first need to set up a
> glossary.
>
> Oliver
>
> John Norman wrote:
>> This makes sense to me. Although I find it interesting that the
>> actor is omitted in the short 'use case' examples. Is it really the
>> same thing for an institutional admin to find a TA as it is for
>> (say) a student to find a TA?
>>
>> I might venture an alternative suggestion:
>>
>> A use case consists of a succinct action and (optionally) a number
>> of scenarios.
>>
>> This allows a focus on Paul's 'verbs K2 must support' (succinct
>> actions) and the scenarios as described, while producing something
>> more complete for the thing I expect to find when I look up a use
>> case.
>>
>> I''m not really invested in the semantics, so long as we create the
>> information we need to get the job done :-)
>>
>> John
>>
>> On 18 Jun 2009, at 23:39, Daphne Ogle wrote:
>>
>>> Hi all,
>>>
>>> Reading this message I realize there are many different
>>> definitions of
>>> use cases. As we talk through requirements for this project, I
>>> think
>>> we should all have a shared language so I'll propose one that I've
>>> been using as we prep for this project and see what others think.
>>> These definitions loosely come from the Unified Modeling Language
>>> (UML) perspective along with UCD.
>>>
>>> 1) Use cases are high level functional requirements: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
>>> They are an abstraction of the stories we have been currently
>>> capturing in all the places mentioned below. I call those stories
>>> scenarios. I've been thinking of use cases as abstract patterns we
>>> find across all these scenarios (and our institutions). They are an
>>> action and a noun (at minimum) that describe what the user needs to
>>> get done in the system. It's tempting to get more granular and
>>> context specific with use cases but I think those details can be
>>> captured in other ways. In a team meeting this morning we put loose
>>> parameters on ourselves that the use cases could not be longer
>>> that 5
>>> words to help keep us at an abstract level. Paul at CSU described
>>> the
>>> verbs as those things that the kernel has to support and I think
>>> that
>>> makes a lot of sense. The details in scenarios (below) are how it
>>> needs to get done.
>>>
>>> 2) Scenarios (some of what is in the Kernel and Group spaces) are
>>> stories about users getting work done in context. They help us
>>> understand *how* the functional requirements need to implemented.
>>> Scenarios may be a concrete example of one use case but more likely
>>> are a string of use cases the user needs to complete an activity.
>>> These rich stories are what will drive the UX design since those
>>> contexts and workflows are so important to the system enabling users
>>> to get their work done in ways that make sense to them.
>>>
>>> To share a concrete example:
>>> Scenario: Catalina is prepping for the upcoming year and the new
>>> Teaching Assistants for Spanish 1 she'll be managing. She needs to
>>> identify who all the TAs are and add them to her "TA knowledge
>>> sharing
>>> group" which she started 2 years ago. Once she's added them to the
>>> group, they'll have access to the collaborative space the group has
>>> been using to share information, discuss class details and work on
>>> course materials together.
>>>
>>> Use Cases we can pull from the scenario: 1) find TAs, 2) Add TAs
>>> to
>>> group, 3) Invite TAs to collaborative space, 4) Send message about
>>> group and space use 5) Find group space
>>>
>>> How do these definitions sit with you all?
>>>
>>> -Daphne
>>>
>>>
>>> On Jun 18, 2009, at 7:54 AM, 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"
>>>
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at media.berkeley.edu
>>> cell (925)348-4372
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (925)348-4372
More information about the sakai-dev
mailing list