Specific content management links of interest...

[Daphne Ogle]

HI there,

After the resources call I thought I'd point out some more links   
regarding the UX Walkthroughs and content management that might be of  
interest for folks.  I'm copying the fluid community in case anyone  
else wants to add anything.   I'm really looking forward to having  
some of these conversations face to face at the summit.

1)  Here's a list of component ideas we've been thinking about so  
far:  http://wiki.fluidproject.org/display/fluid/Component+Suggestions.
These have come from various places and thus we don't have a shared  
meaning yet.  Work at the summit will drive us toward a shared  
understanding.   I hypothesize that many in the list will end up  
having overlap in needs and thus roll up into one component...with  
various properties, etc. to allow for implementation in a specific  
context.

2) Content management scenarios we're using for the Sakai UX  
Walkthroughs:  http://wiki.fluidproject.org/pages/viewpage.action? 
pageId=1704469

3) Sakai Results (in progress):  http://wiki.fluidproject.org/display/ 
fluid/Sakai+UX+Walkthrough+Results

This work is making us all rethink what it means to manage content in  
the respective products (if you're really curious check out this  
interesting thought exercise on uPortal and content management:   
http://wiki.fluidproject.org/display/fluid/Content+Management+- 
+uPortal+Usability+and+Accessibility).  We really need new  
terminology since content management is such a loaded term.  Perhaps  
"creation, organization & presentation of course materials" is 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).

On the call today, Clay mentioned that it's difficult to see how  
components relate to (or are derived from maybe) the content  
management  focus.  This is another place where we use "loaded"  
terminology.  In Fluid when we refer to components it's more than how  
components have typically been implemented.  So we aren't just  
talking about widgets, although some will be more widgety,  but even  
larger chunks of functionality that can be implemented as a  
component.  For example, Harriet and I were talking about this idea  
of allowing multiple views on files (like Apple's Finder or Window's  
Explorer).  This entire piece of functionality could potentially be a  
component -- not just the widget to switch between views but the  
views themselves too (layout, sorting, etc.).  This is a hypothetical  
example and we are continuing to better understand how much can be  
included in a component.   Context is soooo important in design so a  
big challenge is how much can be generalized before we are unable to  
include contextual needs in the behavior.  The "views" needed and the  
interaction within them are different for a group of documents than  
for a group images fro instance.  Can those contextual needs be built  
into a component?

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/b98900bf/attachment.html>