[Building Sakai] Terminology clarification [was: Groups Call]

[Daphne Ogle]

On Jun 19, 2009, at 4:45 AM, 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 just got the same question from Diana at Michigan.  The idea is that  
the subject of the use case is an attribute we'll capture in a  
matrix.  So rather than listing both "institutional admin finds TA"  
and "student finds TA", we can list "Find TA" in a spreadsheet and  
then attributes will be who does it.  The way I've done this in the  
past is to list use cases in the first column & then have a column for  
each actor (TA, Admin, Teacher...) and we can mark which actors do  
each use case.  Kind of like we did for a Fluid project:   http://wiki.fluidproject.org/display/fluid/Content+Management+Research+Models 
   (see use case frequency matrix about 1/4 way down the page), except  
we will likely use actors or roles instead of personas.  I like this  
matrix because it can also include how often something happens which  
is interesting both for prioritizing work and the interface design.   
I'll get this started for groups later today and send out a link so  
folks can see if they think it's a useful tool.
>
>
> I might venture an alternative suggestion:
>
> A use case consists of a succinct action and (optionally) a number  
> of scenarios.
Yes!  I was thinking that each use case would link to another page (or  
section of a page) where we describe a few scenarios.  This approach  
will also allow us to create the scenarios over time as use cases make  
it into the iteration.    Listing the use cases is really just meant  
to be a simple way to keep track of and prioritize the required  
functionality at a high level.  How does that sound?
>
>
> 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 :-)
Yep,  my goal is also to make the information easily digestible both  
at a glance and in detail.  Please share any ideas people have to help  
us with this too!

Thanks so much for the feedback!

-Daphne
>
>
> 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