Content management

[Paul Zablosky]

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
>   

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