Paul.Zablosky at ubc.ca
Wed Sep 12 22:23:41 UTC 2007
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
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:
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.
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
(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.)
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work