Content management

Daphne Ogle daphne at media.berkeley.edu
Thu Sep 13 21:47:47 UTC 2007


Interesting.  This is the exactly what we are struggling with.  To  
our users almost everything about their site is content.  I described  
this earlier in an email to the Sakai resources team (building on  
Gary's definitions in this thread) as ""creation, organization &  
presentation of course materials" as perhaps a better way to refer to  
it in Sakai.  What we find as we think about this from the  
instructor's perspective is that it takes us all the way back to site  
creation since how the site is organized forms the basis for  
organization and presentation and in some ways creation  
(collaborative authoring for instance)."

This is especially challenging because we are trying to come up with  
a way to talk about this concept without strictly defining it since  
the point of the research is to be able to define it from the users  
perspective.  Perhaps another way to get our heads around this is to  
look at and refine the contextual inquiry guidelines (which came out  
of the same wkg mtg at Berkeley) which includes the categories and  
kinds of information we expect to learn:  http:// 
wiki.fluidproject.org/display/fluid/Contextual+Inquiry+Guidelines.

-Daphne


On Sep 13, 2007, at 12:18 PM, Mara Hancock wrote:

> Very interesting. I am wondering if there is some learning from the
> Chandler Project about the convergence between portlet mgmt. and
> mgmt. and viewing of content in an CLE: http://chandlerproject.org/
> features. Some things that jump out at me are the blend between tools
> match user workflows, not single toolsets. They can be configured by
> the users in a more portlet style environment, the definition of
> content goes beyond resources to things such as emails, notes, etc..
> and the associations that can be built between them to make them more
> meaningful to the user.
>
> Mara
>
>
>
> On Sep 13, 2007, at 11:53 AM, Gary Thompson wrote:
>
>> Yes, this is interesting stuff.
>>
>> As has been discussed before, I wonder if content management is too
>> broad and overloaded a term for what we are setting out to do.
>> Conceptually and categorically, it makes sense, but "content" and
>> "management" refer to so many different types and tasks, that it is
>> hard
>> to pin down the context using those terms.  It seems to suffer from
>> "this encompasses everything" - even if that is unintentional.
>>
>> Perhaps, according to the Sakai problem statement, it could be
>> narrowed
>> down to more specific terminology and language relating to
>> "resources",
>> "assets", and/or "documents" in the context of "teaching", "learning"
>> and/or "research".
>>
>> Then I have a better sense of how to evaluate those goals and  
>> problems
>> in the context of uPortal.  As Paul speaks to, uPortal clearly has
>> a set
>> of distinct issues in regards to "content management" in a portal
>> context, but from what I understand, these goals and problems are
>> probably different in type and category than "heavy use of the
>> Resources
>> tool and related activities to manage content in course and project
>> sites."  As can be seen, Paul's terminology and language is  
>> different,
>> referencing things like "portlet", "layout", "customization", and
>> "personalization".
>>
>> There are likely guidelines and principles that will translate and
>> overlap, but I think in the end we may be losing something by
>> trying to
>> umbrella Sakai's main issue(s) with uPortal's main issue(s) in the
>> bucket of content management.
>>
>> Hopefully that is making some sense.  Not that I am trying to overly
>> separate uPortal and Sakai, but just pointing out that it seems that
>> Sakai's main issue and uPortal's main issue are beasts of different
>> kind
>> and nature.
>>
>> So, perhaps Sakai's main issue is:
>> Managing course (or research) content [in a site].
>>
>> And uPortal's main issue is:
>> Integrating and distributing content views [in a portal].
>>
>> It clearly needs more thought and refinement, but in my mind that
>> starts
>> to reveal the nature of the problems.
>>
>> Gary
>>
>>
>> Paul Zablosky wrote:
>>> This is very interesting stuff Daphne; it's definitely an area
>>> deserving investigation. I suspect that we've just scratched the
>>> surface with portals. Right now, most portals are still seen as
>>> "broadcast" services where all the content management is handled by
>>> portal administrators and content providers.  As we move to a more
>>> user-centric view, we find that the content-management functionality
>>> offered to the user is fairly primitive.
>>>
>>>    1. The user can (sometimes) arrange the portlet windows within  
>>> the
>>>       columns and tabs, as well as subscribe and unsubscribe to
>>>       portlets from a catalog
>>>    2. The user can (sometimes) configure their profile for a  
>>> specific
>>>       portlet.  (This should be invoked through EDIT mode, but is
>>>       often not implemented this way.)
>>>
>>> The user usually cannot:
>>>
>>>    1. Easily determine what aspects of their layout are mutable, and
>>>       which are customizable.
>>>    2. Set the default window state for a portlet in their layout.
>>>
>>> As far as I know, there are no conventions for proper use of window
>>> states or edit modes, nor are there guidelines for portlet behaviour
>>> in a multi-portlet display. A lot of this is discussed in more  
>>> detail
>>> in the wiki page:
>>> http://wiki.fluidproject.org/display/fluid/Content+Management+-
>>> +uPortal+Usability+and+Accessibility
>>>
>>> I'm still developing my understanding of what we mean by "Content
>>> Management".  I'm starting to think that what we mean is "user
>>> centric
>>> manipulation of layouts and portlet selection (either through
>>> customization or personalization), as well as the ability to
>>> configure
>>> individual portlet behaviour (through EDIT mode).
>>>
>>> Does anyone know of any research results or proposed conventions for
>>> this sort of thing?
>>>
>>> Daphne, I am in strong agreement with your points about how the  
>>> users
>>> will tend to think of the portal as a unified monolithic service,  
>>> and
>>> expect cooperation and consistency between its elements -- even
>>> though
>>> we know that its a collage of mutually unaware applications.  I  
>>> think
>>> we should find a way of expressing this as a fundamental design
>>> principle.
>>>
>>> I'm trying to think of some components that may assist with all  
>>> this.
>>> Perhaps:
>>>
>>>    1. A common EDIT mode tool for portlets
>>>    2. An EDIT mode tool that sets default portlet state
>>>    3. A layout status tool that lets users see "you can change this,
>>>       you can't change that"
>>>    4. An extended who-am-I tool that helps users assess their
>>>       personalization state.
>>>
>>> (Have we talked about the precise meanings of "personalization" and
>>> "customization"?  We need to get these into a glossary somewhere if
>>> we're going to use them consistently.)
>>>
>>> Regards,
>>> Paul
>>>
>>> Daphne Ogle wrote:
>>>> Hi there,
>>>>
>>>> I'm working on defining a Fluid Content Management research  
>>>> project.
>>>>  We'll be discussing it further at the summit.  The focus is to
>>>> understand how our users think about content management in the
>>>> respective tools and thus how we can better support our user's  
>>>> goals
>>>> and needs..  Hopefully we'll be able to answer a lot of the
>>>> questions
>>>> that have come up for us during the walkthroughs.
>>>>
>>>> We had some working meetings a while back at Berkeley where we
>>>> started defining what a project like this would look like.   
>>>> Since we
>>>> are all more familiar with Sakai, it's definitely
>>>> biased...particularly the problem statement.  I'm wondering if  
>>>> there
>>>> is a separate problem statement for uPortal or perhaps we just need
>>>> to tweak what's there to represent both product perspectives.  It's
>>>> all in the wiki
>>>> space, http://wiki.fluidproject.org/display/fluid/Content
>>>> +Management+Research.
>>>>
>>>> Thoughts?
>>>>
>>>> Daphne Ogle
>>>> Senior Interaction Designer
>>>> University of California, Berkeley
>>>> Educational Technology Services
>>>> daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>> cell (510)847-0308
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> -
>>>> ----
>>>>
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at fluidproject.org
>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> ---
>>>
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at fluidproject.org
>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> ======================================================
> Mara Hancock
> ETS Associate Director of Learning Systems
>
> http://ets.berkeley.edu
> University of California, Berkeley
> Educational Technology Services
> 9 Dwinelle Hall, #2535
> Berkeley, CA 94720
>
> Desk: 510-643-9923
> Mobile: 510-407-0543
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070913/bd557fc6/attachment.html>


More information about the fluid-work mailing list