[DG: Teaching & Learning] [DG: User Experience] Wiki's and Sakai

[Luke FERNANDEZ]

My apologies if I'm a little out of the loop....just a point of
clarification; is the sentiment that " I can't really imagine a
scenario where content authoring is not something Sakai offers OOTB as
a core native function" something that is shared by the strongest
drivers in the 3G initiative?  My impression is that it is and that
many people recognize the need and that one sees this in the 3akai
demos even.  But demos I've seen by Instructure, and advertised talks
by Chuck of "placing LMS systems into content instead of placing
content into LMS systems" (
http://www.dr-chuck.com/csev-blog/000602.html ) suggest that there are
perhaps alternative equally viable ways of teaching.  I haven't yet
seen Chuck's talk so I may be reading too much into the blurb.....but
the way Instructure imagines it is that faculty members would host
their content in a Wiki or CMS and then link out to the LMS for more
private discussions, gradebooks and assessments.  Sorry if my question
is a couple steps back here in the flow of DG conversations....just
trying to catch up.

Cheers,

Luke

>>> Nate Angell <nate.angell at rsmart.com> 4/6/2009 11:29 AM >>>
I think two very different strategies for defining Sakai are being  
called up in this discussion.

One imagines Sakai as having native functionality for key teaching,  
learning, research and collaboration activities.

The other imagines Sakai as a container for other tools that support  
those activities, integrating them with some core services like those 

Jason mentions (searchability, tagability, gradability, import/ 
exportability, etc).

Either strategy is probably possible (although I agree with Jason that 

the second may well be significantly more complex). The most likely  
path is some combination of the two.

Taking a lesson learned the hard way from OSP, I think Sakai should do 

some very clear things out-of-the-box (OOTB; as it already does)  
without requiring the installation and integration of separate
systems.

I can't really imagine a scenario where content authoring (pace  
Michael Feldstein: I'm using the term in its most ordinary sense) is  
not something Sakai offers OOTB as a core, native function. And  
because Sakai is designed primarily to support collaborative  
activities, both individual and collaborative ("wiki-like") authoring 

should be part of that OOTB functionality.

Meanwhile, Sakai should always look to ease integration with external/

auxiliary systems—whether to duplicate some core function for a local
 
use case (eg, Xythos storage) or provide something not available in  
Sakai (eg, TurnItIn). But I would suggest it's a better strategy to  
support generic integration rather than pick one other system and  
integrate it. To turn to the same glaring example, O that it were easy 

to plug any WYSIWYG editor into Sakai rather than just the FCKeditor.

So...

+1 for backporting Sakai 3 collaborative authoring to Sakai 2.x, if  
that's reasonable. If not, then I say we put up with rwiki and/or  
whatever other integrations/workarounds folks are using till Sakai 3  
is ready to go.

On Apr 5, 2009, at 5:44 PM, Jason Shao (CampusEAI Consortium) wrote:

> On 4/5/09 3:15 AM, "DAVID ROLDAN MARTINEZ" <darolmar at upvnet.upv.es> 

> wrote:
>
>> Jason, very good pointing out.
>>
>> From my point of view, if Sakai wants to win adopters it should be 

>> able to
>> integrated what adopters use. I think that the solution (not quite 

>> easy, I'm
>> sure) can be to define Sakai connectors for each external  
>> application so that
>> the connector is responsible of adapting external app to Sakai  
>> information
>> interchange standards. In this way, to use external application X  
>> you "only"
>> need to deploy connector X. It is the connector which has to lead  
>> the issues
>> you have remarked.
>
> David,
>
> From a technical perspective, I would tend to agree with you, in
many
> respects that's exactly the problem-domain I spend a lot of time on 

> the
> Portal side of the shop. Thought I hate to be the pessimist, I do  
> feel the
> need to point out:
>
> * It's a non-trivial amount of work per-target
> * In Sakai 2.x land, even with highly integrated tools, we've had  
> trouble
> applying horizontal concepts like search, tagging, import/export -  
> I'm not
> sure we'd have better luck with a clound of disperate services
further
> spliting the engineering effort
> * Different services have different concepts, and the impedence mis-

> match
> may cause... "interesting" issues in terms of generating a  
> consistent user
> experience.
>
> Jason
>
> --
> Jason Shao
> Director of Product Development
> CampusEAI Consortium
> 1940 East 6th Street, 11th Floor
> Cleveland, OH 44114
> Tel: 216.589.9626x249
> Fax: 216.589.9639
>

_______________________________________________
pedagogy mailing list
pedagogy at collab.sakaiproject.org 
http://collab.sakaiproject.org/mailman/listinfo/pedagogy 

TO UNSUBSCRIBE: send email to
pedagogy-unsubscribe at collab.sakaiproject.org with a subject of
"unsubscribe"