[Building Sakai] Rwiki

Sat Jul 18 11:29:01 PDT 2009

I strongly support the idea of (backporting?) the Sakai 3 content  
authoring experience to Sakai 2 as one of the most salient ways to  
provide a user-experience bridge between the versions, especially if  
it also addresses the need for a better wikiesque experience in Sakai  
2. If what Clay said about such an effort also assisting with or at  
least not complicating data migration from 2 to 3, then so much the  
better. For those institutions focused on Sakai 2 to 3 bridges, this  
may be one of the biggest, easiest wins (and I can say that cause I  
have no idea how much work it would be ;)

As long as we're on the subject of wiki editing syntaxes and the like  
however, I'd like to remind us of a couple of points that we might  
want to take into consideration.

1) TinyMCE may seem like a great choice now, but I think we all feel  
constrained by a certain lock-in with FCKEditor in Sakai 2.  
Accordingly, I think the ideal path would be to aim toward authoring  
capabilities that more easily enable the global use of a specific  
authoring tool (eg, TinyMCE), but also make it easier to plug in  
something different (eg, Sferyx or similar to get math/equation  
editing), or even more than one alternative tool. If it were possible  
to make the whole authoring UX pluggable and configurable that would  
be best, so one institution might deploy only TinyMCE everywhere,  
while another might offer TinyMCE alongside their favorite flavor of  
wiki markup (like Confluence does), while another might require raw  
HTML only (because they are masochistic). Too ambitious probably for  
Sakai 2, but should maybe be a goal for Sakai 3. I'm sure everyone can  
guess the place I'd go for prior art on such a pluggable/configurable  
approach (http://drupal.org).

2) As long as were talking about basic wiki functionality (eg,  
versioning, easy page linking), let's not forget version comparison/ 
diffing, even if it's just a goal for Sakai 3. While I may be loving  
my constructivist flow, if I'm doing it in a collaborative context, it  
can be pretty important to be able to see the changes others have made  
easily.

On Jul 18, 2009, at 4:52 AM, John Norman wrote:

> I just checked 3akai. Linking in TinyMCE works as you would expect:  
> as you type you can highlight a word and click on a 'link' button.  
> At present there are 2 such buttons, the standard button that  
> expects you to give the URL to any arbitrary page and define the  
> behaviour of the link (e.g. open a new window) when clicked on. But  
> there is a second 'link' button created as part of the Sakai  
> extensions to TinyMCE for the demo. This offers a list of existing  
> pages in the site. I imagine it would be possible to extend this  
> functionality to include 'create a blank page as a placeholder'.
>
> Right-click on a highlighted word invokes a drop-down menu with the  
> standard linking in the options. Again I imagine it would be easy to  
> add the Sakai linking option to the drop down.
>
> That would allow the 'flow' Sean calls for and which is indeed a  
> major feature of working in a wiki. You would be typing along,  
> highlight a word, right click and select 'create blank page as a  
> placeholder' and continue typing.
>
> So there is work to be done, but I don't believe it would be major  
> work if we keep the buttons separate. A later enhancement might be  
> to incorporate the Sakai button options in the standard linking  
> dialogue box, but I imagine that might have maintenance implications  
> as TinyMCE evolves. But it is worth checking out.
>
> John
>
> On 18 Jul 2009, at 06:01, Sean Keesler wrote:
>
>> Just to be clear, the interruption in the flow occurs in  
>> traditional authoring tools when I am typing along and realize that  
>> I want to create another page about [this idea].
>>
>> What do I do now? I stop and open another window...author a little  
>> nothing of a page so I can link to it...save it somewhere (where  
>> should I put it? lesse...) and back to my original document and put  
>> in the hyperlink to my stub.
>>
>> Now...what was I writing about? Where did my flow go?
>>
>> Sean
>>
>>
>> On Fri, Jul 17, 2009 at 9:39 PM, Charlie Macchia <cmacchia at brainovision.com 
>> > wrote:
>> On 7/17/09 6:51 PM, "Sean Keesler" <sean at keesler.org> wrote:
>>
>> One of the real powers of wiki's for teaching is the ability to  
>> stub out ideas and create links to non-existent pages. The result  
>> is an invitation to extend and flesh out the rough ideas. Wiki  
>> syntax isn't particularly important...but the idea that you can  
>> easily state an area you, you peers, or your students need to come  
>> back to and address later without interrupting the flow of ideas  
>> IS. A traditional google doc approach doesn't really capture that  
>> important functionality (unless I don't use it right ;).
>>
>> I can't help but but notice that many of the TWSIA uses of wikis  
>> involved student "exploration" and "constructionist" uses that  
>> probably exploited the ability of a wiki to facilitate organic  
>> growth and exploration of interesting areas of student learning.
>>
>> Sean
>>
>>
>> … as a musician ( http://homepage.mac.com/charliemacchia/iMovieTheater10.html 
>>  ) I think I understand the process of constructionist efficiency,  
>> though I’ve never called it that before; a bad tool can get in the  
>> way, or worse, side-track – most dangerously - without the  
>> ‘constructors’ even being aware that they’re being sandbagged: this  
>> is why so many folks with MIDI studios write terrible music, their  
>> brains get creative, then something happens which halts the process  
>> and involves the tool, and now due to the tool, they have to spend  
>> most of their energies problem solving rather than creating – this  
>> makes every creative idea far more a case of heavy lifting than it  
>> should be ( hint, there’s a reason the best song writers can sing  
>> and play and instrument at the same time ).
>>
>> So, I appreciate your comment about the efficiency of the tool, by  
>> way of creating stubs – you can guide and invite, while avoiding  
>> getting trapped – nice.
>>
>> In short, it’s not the specific syntax of the tool that matters, in  
>> that specific instance, it’s the ability to create this feature –  
>> along with the collaborative abilities the tool should have to offer.
>>
>> Wish I knew more about this …
>>
>> Wish I knew more about how to code it …
>>
>> Guess that’s the way all this stuff starts out though – I love  
>> TinyMCE’s interface however, and I’d love to see a wiki-like tool  
>> that leverages it, and maintains, diffs, history, permissions etc.
>>
>> Has anybody done a pseudo-wiki with TinyMCE?
>>
>> Charlie
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090718/87e34529/attachment.html 