Response to Sakai walkthrough

Wed Sep 19 10:09:09 UTC 2007

Hi people

Just a quick mail to say that I read the summary of the Sakai walkthroughs
so far with great interest. The issues you identify tie up absolutely with
issues that we have already identified at Cambridge.

http://wiki.fluidproject.org/pages/viewpage.action?pageId=1705058

For academic year 07/08, we're changing tool names

Site Info > Site Admin
Schedule > Calendar
Worksite Info > Welcome (would ideally be 'Welcome to German Beginners', but
that would need development work - so we'll keep encouraging people to
change it themselves)
Roster > Site Members (for consistency in project and course sites)

We're also anglicizing 
Syllabus > Course Outline

I'll let you know how changing tool names goes, so you've got one
institution's experience to back up the recommendations.

All the best

Harriet

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

CamTools and your MyWorkspace will be getting a new look on Tues 25th
September. Look at the CamTools home page for more details. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Centre for Applied Research in Educational Technologies
University of Cambridge
16 Mill Lane
Cambridge
01223 765 040

> -----Original Message-----
> From: Daphne Ogle [mailto:daphne at media.berkeley.edu] 
> Sent: 13 September 2007 18:27
> To: Resources WG
> Cc: fluid-work at fluidproject.org
> Subject: Specific content management links of interest...
> 
> 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
> 
> 
> 
> [see attachment: "message0.html", size: 5653 bytes]
> 
> 
> Attachments:
> 
> message0.html
> https://collab.sakaiproject.org/access/content/attachment/ca1e
> 1aa0-e2a2-4fa1-0007-82a2d2cb1fb1/message0.html
> 
> ----------------------
> This automatic notification message was sent by Sakai Collab 
> (https://collab.sakaiproject.org/portal) from the Project: 
> Resources site.
> You can modify how you receive notifications at My Workspace 
> > Preferences.
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.485 / Virus Database: 269.13.16/1004 - Release 
> Date: 12/09/2007 17:22
>  
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: 18/09/2007
11:53