[DG: Teaching & Learning] [DG: User Experience] Wiki's and Sakai
Michael Feldstein
michael.feldstein at oracle.com
Mon Apr 6 11:48:42 PDT 2009
My hope would be that Sakai *becomes* that wiki or CMS. Think of it as
two layers. The top layer is largely a blank canvass. You can create,
organize, and link web pages, and you can put text, multimedia, and
functionality widgets on any of those pages based on any one of a number
of page layouts chosen at page creation time. Some of the widgets come
from the bottom layer, which is Sakai LMS functionality.
In terms of implementation options for the top layer, you have several:
* Use any external system that the implementing school prefers,
which is what you seem to propose here. There is nothing in Sakai
3's design to preclude this option, and indeed some of that is
likely to happen at many adopting institutions, at least on the
margin. But it probably isn't a viable main option for everyone.
* Bundle a single OOTB external system that acts as a canvass layer
for Sakai. This is attractive in theory, but it may be difficult
to find an external system that has all the right characteristics,
particularly including ease of use.
* Take an external system or set of libraries and integrate it into
Sakai to provide the canvass layer. This is also attractive, from
my perspective, but depends again on finding the right project to
integrate.
* Build this capability internally based on the JCR functionality in
K2. I would prefer the second or third options, but if neither
turns out to be viable, then this is a non-crazy option.
- m
Luke FERNANDEZ wrote:
> 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"
> _______________________________________________
> sakai-ux mailing list
> sakai-ux at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
--
Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20090406/6e3ab5f6/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20090406/6e3ab5f6/attachment-0001.gif
More information about the pedagogy
mailing list