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

[Nate Angell]

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
>