Thoughts about Forums Tool

James Laffey laffeyj at missouri.edu
Thu Oct 18 14:27:37 UTC 2007


Michael wrote
"Even for instructors, though, I think we'll be more
successful in structuring navigation around tasks/activities that
folks are trying to accomplish."

I'd like to climb on Hannah's soap box, although I think it would be  
a transition for instructors who "use" sakai as a tool in their  
teaching rather than as their medium for teaching. It depends on what  
the task is. If you just have students read syllabi or drop off  
assignments then sakai does not manage the lesson just elements of  
it. You might argue that it is already designed around those tasks.  
However, if you are a distance educator then the whole process is  
mediated through sakai and we definitely will benefit from process  
support tools. Of course there are other  blended learning  
instructors who fall somewhere between fully mediated and simply  
syllabus and dropbox using.

Hannah ....correct me if my comments are not in keeping with your ideas.

On Oct 18, 2007, at 8:57 AM, Hannah Reeves wrote:

> Me too, I've been on this soap box since CHEF 1.0.
>
> Hannah
> ----- Original Message -----
> From: "Michael Korcuska" <mkorcuska at gmail.com>
> To: "Daphne Ogle" <daphne at media.berkeley.edu>
> Cc: "Diana L Perpich" <dperpich at umich.edu>, "Sakai UI" <sakai-dg- 
> ui at collab.sakaiproject.org>, fluid-work at fluidproject.org
> Sent: Wednesday, October 17, 2007 6:56:28 PM (GMT-0500) America/ 
> New_York
> Subject: Re: Thoughts about Forums Tool
>
>
> I'll chime in and say I don't think tools are the best way to think
> about navigation. Maybe for an instructor it works. Less so for the
> learner. Even for instructors, though, I think we'll be more
> successful in structuring navigation around tasks/activities that
> folks are trying to accomplish. I know this is (one strand of)
> conventional wisdom in the design world, but I like it.
>
> Sign me up to help, Daphne.
>
> Michael
>
> On Oct 17, 2007, at 3:35 PM, Daphne Ogle wrote:
>
>> It does make me cringe a bit that we allow user's to create
>> unwieldily navigation for their sites.  But I think the root of the
>> problem is less about us letting them create multiples and more
>> about whether that is the right solution.  Why did the instructor
>> need that many web content tools.  Perhaps the current tool isn't
>> supporting their needs well.
>>
>> When I read Clay's comment I think, "perhaps tools aren't the best
>> way to structure out navigation".  Of course, this is nothing new
>> -- many have said it before (you and I probably had this  
>> conversation, eh Diana :) ).  Thinking about changing it seems
>> overwhelming at this point but perhaps its time to give this some
>> real attention.   If not tools, then what?
>>
>> Some people in Fluid and Sakai have been thinking about this
>> question a bit.  In fact, there may be a WG forming soon that will
>> focus on the problem spaces of file management and navigation (2
>> areas that have risen to the top form the UX Walkthroughs we've
>> been doing).  One of the first steps will be to do some contextual
>> inquiry with users to understand how they work with content in
>> their sites -- why do they want it in there, how do they get in,
>> what are they doing with it once it's in, etc.  The result should
>> be a much better understanding of this space which should lead to a
>> better understanding of how navigation structures can best support
>> users work.  I'm curious if there are people in the community that
>> could help with some of the research, analysis and design?   If
>> you're interested and have the time to get involved in a project
>> like this, let me know.  I'm in the midst of thinking through what
>> a plan for this would look like and how we get the greatest user
>> coverage with limited time and resources.
>>
>> -Daphne
>>
>> On Oct 17, 2007, at 12:27 PM, Diana L Perpich wrote:
>>
>>> Indeed, there are several useful tools that can structure
>>> themselves in that way...
>>>
>>> For example, we've always allowed the site owner to create as many
>>> Web Content and News sections as their little hearts desire.  I've
>>> seen absolutely sites with a dizzying number of Web Content
>>> links.  One site, no joke, had 30... and of course until recently
>>> there wasn't a very good way to re-order them, so they didn't even
>>> have *organization* going for them!
>>>
>>> So what kind of policy or pedagogy might inform a decision to
>>> restrict the number of left-nav links to Forums, or Chat, but not
>>> Web Content or News sections?
>>>
>>> As training and support staff, I looked at the 30-Web-Contents
>>> site in horror not because the system allowed them to create
>>> thirty web content sections, but because we had failed to inform/
>>> teach them that discretion is the greater part of valor, that less
>>> can be more, and that the wiki would have gotten them nine-tenths
>>> of what they wanted without all that confusion.
>>>
>>> More thoughts on ways to combat left-nav sprawl.
>>>
>>> -- a prompt on the Edit Tools confirmation page, some kind of a  
>>> tip recommending that they consider limiting their left nav bar to
>>> 10 (or whatever) of fewer for ease of use.
>>>
>>> -- more boldly, a limit to the number of left-nav items a site can  
>>> have (or show) at any given time.
>>>
>>> -- a reassessment of the value of Help as a left-nav item in every  
>>> site.  What about moving this out of the site-specific
>>> navigation?  Might it live comfortably as a link in the banner?
>>> It seems often to live at the upper-right corner of complex sites
>>> I visit.  Often beside search.
>>>
>>> -- a thought to whether Site Info must be a left-nav item visible  
>>> to all.  For our students, all they see there is the most basic
>>> site info, little that is regularly useful to them.  Could Site
>>> Info be hidden by default from all but those who have site.edit
>>> permissions?  The site owner could choose to unhide it if class/
>>> project protocol deemed it useful.
>>>
>>> -- in the Workspace particularly (physician, heal thyself) a  
>>> reassessment of tools like Preferences and Account.  Do they need
>>> to be separate left-nav items?  Could they be combined in multi-
>>> tool page or reworked to present as a single tool?  Someone posted
>>> recently about combining Memberships and Browse Sites and maybe
>>> even Worksite Setup.
>>>
>>> -- more guidance.  Too often folks turn on more tools than they  
>>> actually use.  Email archive is a common tool that I see, more
>>> often than I'd like to admit, turned on at course sites with not a
>>> single message posted half way into the term.  Announcements is
>>> another-- lots of instructors that turn on announcements and then
>>> post 10 or fewer the whole term.  Train people to turn off or hide
>>> tools when they aren't being used.  Train people on alternatives
>>> (announcement content on the wiki page, if they're also using the
>>> wiki).
>>>
>>> -- muti-tool pages.  While this may well merely move the confusion  
>>> out of the nav bar and onto the main page, there are also strong
>>> cases for bringing this option out of the sole province of system
>>> admins.  Some infrequent Announcements users would just as soon
>>> use the half-width frame on the Home page to post announcements.
>>> If it were easy to replace Recent Announcements with Announcements
>>> on the Home page, thus eliminating a left-nav link, that could
>>> reduce what appears now to be redundancy.  Schedule can behave
>>> similarly.  I've tweaked handful of sites so that the Schedule
>>> tool appears on the Home page instead of occupying its own left-
>>> nav space.  A trim view of Resources could show up on the Home
>>> page, or beside a trim Schedule.
>>>
>>> I notice that my bullet points are getting progressively longer,
>>> and that's a good sign to close.
>>>
>>>
>>> • diana lee perpich • use-lab •  digital media commons •
>>>
>>>
>>> On Oct 17, 2007, at 12:25 PM, Clay Fenlason wrote:
>>>
>>>> 2007/10/16, Diana L Perpich <dperpich at umich.edu>:
>>>>>
>>>>> 1-- RE Clay's comment:
>>>>>
>>>>> Between Web Content, RSS feeds, Resources Viewer (in
>>>>> development) and
>>>>> other potential areas
>>>>> like this one, that tool navigation menu itself becomes rather
>>>>> unwieldy.
>>>>>
>>>>> I think the nav bar only becomes unwieldy when people wield the
>>>>> tools
>>>>> willy-nilly.  A site with just three tools (maybe we should call
>>>>> them
>>>>> pages, since a page can have multiple tools.  Better yet, call  
>>>>> them
>>>>> sections, since "Pages" don't do justice to the multiple pages
>>>>> within
>>>>> any given "Tool").  Anyway, a site with
>>>>>
>>>>> Home
>>>>> Forum 1
>>>>> Forum 2
>>>>> Resources
>>>>>
>>>>> on the left isn't unwieldy at all.  It's actually quite
>>>>> straightforward.
>>>>
>>>> Right, but that example is rather begging the question.  If there
>>>> are
>>>> several useful tools that structure themselves in this way, we are
>>>> creating a situation where instructors are tacitly encouraged to
>>>> produce sprawl - and it's what we are in fact starting to see.  We
>>>> shouldn't design around only the most spare and Spartan of site
>>>> mantainers, and there's currently some tension between best
>>>> practices
>>>> of creating multiple such pages and a minimalist structure for site
>>>> navigation.
>>>>
>>>> ~Clay
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: User
>>> Interaction site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>
>> 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: 17617 bytes]
>>
>>
>> Attachments:
>>
>> message0.html
>> https://collab.sakaiproject.org/access/content/attachment/
>> cf6fea68-076b-437b-0015-8b1796b10ebd/message0.html
>>
>> ----------------------
>> This automatic notification message was sent by Sakai Collab
>> (https://collab.sakaiproject.org/portal) from the DG: User
>> Interaction site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>
> -- 
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska at sakaifoundation.org
> mobile: +1 510-599-2586 // phone: +1 510-931-6559
> skype: mkorcuska
>
>
> ----------------------
> This automatic notification message was sent by Sakai Collab  
> (https://collab.sakaiproject.org/portal) from the DG: User  
> Interaction site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>
>
>
> -- 
> Hannah Reeves
> CLE Product Manager
> The rSmart Group
>
> ----------------------
> This automatic notification message was sent by Sakai Collab  
> (https://collab.sakaiproject.org/portal) from the DG: User  
> Interaction site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>

Jim Laffey
Professor, School of Information Science and Learning Technologies
laffeyj at missouri.edu
573 882 5399
--  
  "Don't teach men how to build a boat. Teach them to yearn for the  
wide and open sea."   Antoine Saint Exupery

Old Irish expression "Heres to a long life and a merry one. A quick  
death and an easy one. A pretty girl and an honest one. A cold beer  
and another one!




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


More information about the fluid-work mailing list