Assessment related use cases from Fluid user research

Clay Fenlason clay.fenlason at et.gatech.edu
Fri May 9 19:41:01 UTC 2008


On Fri, May 9, 2008 at 10:20 AM, Barbra Mack <barbra at nyu.edu> wrote:
> We want to move away from people having to bring this disparate material
> into Sakai to be able to share and collaborate, and instead just use a
> meta-resource management tagging tool that interfaces with tools in Sakai
> (like Blogs, Wikis, and some sort-of DIY page editor--which we would use the
> existing Resources tool for) to manage and access their files regardless of
> where they are stored. We haven't selected a tagging tool yet, but an
> example of one we are considering is SIMILE's semantic bank.

That sounds like our wavelength, but it also sounds to me like a class
of things that we've imagined should be fairly core to Sakai
functionality, which its services should support for a variety of
reasons.

I may be reading too much into this (and what's said below), but it
also sounds like you may be assuming the status quo of the current
Resources tool, when the next round of development in this problem
space seems to be leaning (somewhat) away from it.  I'd caution
against going too far to array a set of other tools based on this
assumption, if that's the case.  Also, are you familiar with Fluid's
fledgling "taggable" work?

> This tagging tool would be tightly integrated with Sakai, replace much of
> the role that Resources currently plays. For example, the tagging system
> would be accessed to locate and embed files within Sakai; and if a person
> adds a file to a page within Sakai that file will be automatically added as
> a entry within the tagging tool. But what would be stored is a URI instead
> of a file itself (if a person is adding a file from their desktop, instead
> of an institutional repository then a copy of that file would be added to
> Xythos and the URI taken from there). This meta-tagging tool would store
> meta-data about files under a person's own personal schema--not under the
> institutional repositories schema (though a person could choose to import
> existing meta-data if they wish). And, while this tool would be tightly
> integrated with Sakai, this tool should be able to be accessed outside of
> Sakai as well.
>
> Without having done any real serious technical evaluation, we see this
> mostly effecting the Resource Helper, and the role that Resources currently
> plays in Sakai. We also see it having a broad effect on how permissions are
> handled, since it would be nice to have users lists and groups that extend
> past just a "course site" that a course owner could then just apply
> different permission sets to same groups when in the tagging tool outside of
> Sakai, or when in the discussion tool in a specific course site, etc.

Similar comments to what I've said above:  all good thoughts, of a
piece with thoughts coming from other Sakai visionaries, but I'd
encourage thinking less about the "Resources" tool as such, and more
about the content services running against JCR, and the flexibility
they might afford.  John's already expressed his interest, I know
Fluid and its partner institutions do as well, as does Georgia Tech
and others.  The topic seems ripe for some careful thinking about
shared services, as the JCR work is coming into its own.

~Clay

>
>
> On May 9, 2008, at 9:48 AM, Clay Fenlason wrote:
>
>> ... cc-ing Barbra, in case she isn't on this list.
>>
>> On Fri, May 9, 2008 at 9:45 AM, Clay Fenlason
>> <clay.fenlason at et.gatech.edu> wrote:
>>>
>>> I'm trying to be better about taking my conversations to the lists,
>>> and realize that I stumbled here earlier - there is more interesting
>>> work happening around content management in Sakai than I think most
>>> people realize, and it just needs to be ushered out into the open.
>>>
>>> In any event, let me pose a follow-up question to Barbra on the list:
>>>
>>> When you say "use Sakai within a Research Portal," do you mean that
>>> you are imagining Sakai as a "server that houses resources"?  Or do
>>> you mean that Sakai itself would be accessing a wide array of
>>> repositories and sharing across them?  I think my interest is to get
>>> away from the idea that Sakai is itself a repository, but is rather a
>>> container that can knit repositories together (eventually with the
>>> sort of cross-cutting collectioning and sharing UX that you describe).
>>>
>>> I'm going to keep watching the Fluid research model as well, in the
>>> hope that it helps ground requirements that seem to keep flitting
>>> about but never quite land.
>>>
>>> ~Clay
>>>
>>> ---------- Forwarded message ----------
>>> From: Barbra Mack <barbra at nyu.edu>
>>> Date: Wed, May 7, 2008 at 4:40 PM
>>> Subject: Re: Assessment related use cases from Fluid user research
>>> To: Clay Fenlason <clay.fenlason at et.gatech.edu>
>>> Cc: Daphne Ogle <daphne at media.berkeley.edu>, Nicola Monat-Jacobs
>>> <nicola at nyu.edu>
>>>
>>>
>>> Yes. That would be great to have a conversation. Daphne it looks like
>>> we are moving in similar areas.
>>>
>>> Effort on this Sakai thing was put on hold here at NYU for a few
>>> weeks. But there is very serious consideration to use Sakai within a
>>> Research Portal. Which would be a "cloud system" that allows people to
>>> go in and select resources from institutional respositories, and then
>>> share their selections using a variety of collaboration tools,
>>> including a tagging system, blogs, wikis, etc.
>>>
>>> NYU's proposed portal, and also considerations about how we could use
>>> Sakai as an LMS would significantly break down the barriers that exist
>>> now between course sites that are housing in an LMS, and scholarly
>>> activities that might go on in relation to classes, graduate work,
>>> post-doctoral research, research groups, faculty peer collaboration,
>>> etc.
>>>
>>> However, most of this hinges on looking at how can resources be more
>>> fluid, and making the meta-data and the reuse of these resources not
>>> dependent on the server that houses them. Of course, this also means
>>> that we need to look at how permissions are assigned, and allowing
>>> user groups to be larger than a course site, and even shared between
>>> systems.
>>>
>>> I'm happy to share some of the research, and the user needs analysis
>>> that we did to come up with these 1st mock-ups.
>>>
>>> -Barbra
>>>
>>>
>>>
>>> On May 7, 2008, at 4:17 PM, Clay Fenlason wrote:
>>>
>>>> Thanks, Daphne.  I'm also copying a couple of our colleagues at NYU,
>>>> since they've been giving a lot of thought to content management in
>>>> Sakai in recent months.
>>>>
>>>> Barbra and Nicola, I'd highlight Fluid's work in this area as a good
>>>> place to engage with content management in Sakai:
>>>>
>>>> http://wiki.fluidproject.org/x/pAIa
>>>> http://wiki.fluidproject.org/x/44ok
>>>>
>>>> Daphne, Barbra posted what NYU has been thinking through here:
>>>>
>>>> http://confluence.sakaiproject.org/confluence/x/J4ArAQ
>>>>
>>>> There might be opportunities for collaboration here.
>>>>
>>>> ~Clay
>>>>
>>>> On Wed, May 7, 2008 at 2:40 PM, Daphne Ogle <daphne at media.berkeley.edu>
>>>> wrote:
>>>>>
>>>>> Hi Clay,
>>>>>
>>>>>  If I've already sent this sorry for the duplication.  I've been on
>>>>> holiday
>>>>> and know I wanted to send this before I left but not sure I did.
>>>>>
>>>>>  There may not be much new to you here but wanted to let you know we
>>>>> are
>>>>> starting to get the research model up on the wiki,
>>>>>
>>>>> http://wiki.fluidproject.org/display/fluid/Content+Management+Research+Models.
>>>>>
>>>>>  The Use Case Frequency Matrix is probably most useful.  We are still
>>>>> working on the completing the who  and the frequency but you can at
>>>>> least
>>>>> get an idea of the kinds of activities users told us and showed us they
>>>>> were
>>>>> doing.  The Xs identify who we heard the use cases from although there
>>>>> may
>>>>> be others also doing them, we just didn't hear it directly from them.
>>>>>  That
>>>>> analysis is one of our next steps.
>>>>>
>>>>>  Let me know if you have any questions.
>>>>>
>>>>>  Daphne Ogle
>>>>>  Senior Interaction Designer
>>>>>  University of California, Berkeley
>>>>>  Educational Technology Services
>>>>>  daphne at media.berkeley.edu
>>>>>  cell (510)847-0308
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Clay Fenlason
>>>> Director, Educational Technology
>>>> Georgia Institute of Technology
>>>> (404) 385-6644
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Clay Fenlason
>>> Director, Educational Technology
>>> Georgia Institute of Technology
>>> (404) 385-6644
>>>
>>
>>
>>
>> --
>> Clay Fenlason
>> Director, Educational Technology
>> Georgia Institute of Technology
>> (404) 385-6644
>
>
>



-- 
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644



More information about the fluid-work mailing list