Content management

Mara Hancock mara at media.berkeley.edu
Thu Sep 13 19:18:42 UTC 2007


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





More information about the fluid-work mailing list