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

[Ed Garay]

I would prioritize the built-in use of wikis in Sakai as follows:

   1) make the wiki as easy-to-use as possible
      including a simple yet flexible WYSIWYG editor, intuitive gradebook
      integration, history mgmt, supporting personal, group and class wikis

   2) eventually the wiki GUI should be Sakai's
      perhaps, as an interim first-phase solution, go ahead and retrofit
      someone else's wiki with Sakai for quick integration, but ideally,
      using the wiki in Sakai should not feel like being elsewhere
      except being in Sakai

   3) externalize the Sakai wiki for non-teaching applications
      Not that I believe in one-size-fits-all solutions but there is value
      in having Sakai work sites and Sakai wikis (and blogs and ...) used
      for miscellaneous higher Ed applications other than for classes.

      The Sakai wiki may never be as comprehensive as confluence or twiki,
      for example, because doing so might make it not too user-friendly to
      mere mortals (i.e. non-technical academics), and it may never be as
      powerful and yet as easy to use as Socialtext, ...but it would be good
      to give university folks the option to re-purpose what they already
      know how to use and actually use the Sakai wiki for non-teaching apps
      instead of running something else or opting for one of those free
      off-campus hosted third-party services

Greetings from Chicago,
--- Ed Garay, UIC

At Sunday 4/5/2009 01:50 PM, Michael Feldstein wrote:

>>>One more note on implementation. I have suggested so far that this is
>>>something that could and possibly should be built into the Sakai core. But,
>>>as I have brought up several times before on these lists, there is a second
>>>way to achieve this aim--one that may require little or even no coding. If
>>>every page in the Sakai 3 UI is simply HTML and Javascript, then every page
>>>can be managed in a standard web content management system, which would
>>>bring page versioning, rollback, and granular access privileges for free,
>>>along with some other capabilities such as the ability to require different
>>>access privileges for editing different portions of the page, approval
>>>workflows, and other good stuff. My current instincts on the best way to go
>>>here has evolved somewhat; I now believe that it's a good idea to take the
>>>first route (i.e., building the basics into core) but also to make sure that
>>>the conventions followed facilitate individual adoptees taking the second
>>>route for the extra value added where that makes sense for them.
>>>
>>
>>On that implementation note, what if it what were deeply rooted in
>>Sakai was a 3rd-party framework for providing (scriptable) RESTful
>>access to content?  It seems to me that would offer the promise of
>>accomplishing the various aims you lay out, doing so in a unified way,
>>and not having to write the core functionality ourselves.  "Sakai
>>core" itself might be a misnomer where it's really specializations
>>(especially in the way of authorization complexities) riding on top of
>>something more generic.  I think K2 is heading this direction.
>>
>Yes, this is also consistent with suggestions I have made in the past. In 
>a world where plenty of decent web content management systems exist, I 
>think you have to make a compelling case for building yet another one 
>rather than re-using one that already exists. Maybe that case can be made, 
>but if so, it should be made as an alternative to one or more real, 
>existing WCM systems that somebody in the community has investigated for 
>this purpose.
>
>The trick will be to find something that, in addition to having the right 
>license and adequate support from its home community, is low-level and 
>lightweight enough that it can integrate comfortably into another system 
>without bringing a lot of extra baggage. One significant challenge will be 
>UI. Whatever WCM system is adopted should either let you hide the UI or 
>have a UI that is simple and compatible as an overlay to the current 
>"content authoring" capability. That may not be as difficult as it sounds. 
>The current style for "content authoring" is mostly an editable page 
>underneath a WYSIWYG editor, which is a common convention that most WCM 
>systems should be able to handle. Where you may run into more dissonance 
>is on site authoring (i.e., adding and managing multiple pages) and more 
>complex functionality (e.g., workflow).
>
>Ideally, whether the community chooses a third-party component to handle 
>WCM or builds its own capabilities, it would be done in such a way that 
>other alternatives could be swapped in (either by an individual adoptee or 
>by the community, should the third-party component chosen become less 
>desirable down the road) with a manageable amount of work.
>
>- m
>
>
>--
>
>
>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
>
>
>>>
>>>
>>>One more note on implementation. I have suggested so far that this is
>>>something that could and possibly should be built into the Sakai core. But,
>>>as I have brought up several times before on these lists, there is a second
>>>way to achieve this aim--one that may require little or even no coding. If
>>>every page in the Sakai 3 UI is simply HTML and Javascript, then every page
>>>can be managed in a standard web content management system, which would
>>>bring page versioning, rollback, and granular access privileges for free,
>>>along with some other capabilities such as the ability to require different
>>>access privileges for editing different portions of the page, approval
>>>workflows, and other good stuff. My current instincts on the best way to go
>>>here has evolved somewhat; I now believe that it's a good idea to take the
>>>first route (i.e., building the basics into core) but also to make sure that
>>>the conventions followed facilitate individual adoptees taking the second
>>>route for the extra value added where that makes sense for them.
>>>
>>
>>
>>
>>On that implementation note, what if it what were deeply rooted in
>>Sakai was a 3rd-party framework for providing (scriptable) RESTful
>>access to content?  It seems to me that would offer the promise of
>>accomplishing the various aims you lay out, doing so in a unified way,
>>and not having to write the core functionality ourselves.  "Sakai
>>core" itself might be a misnomer where it's really specializations
>>(especially in the way of authorization complexities) riding on top of
>>something more generic.  I think K2 is heading this direction.
>>
>Yes, this is also consistent with suggestions I have made in the past. In 
>a world where plenty of decent web content management systems exist, I 
>think you have to make a compelling case for building yet another one 
>rather than re-using one that already exists. Maybe that case can be made, 
>but if so, it should be made as an alternative to one or more real, 
>existing WCM systems that somebody in the community has investigated for 
>this purpose.
>
>The trick will be to find something that, in addition to having the right 
>license and adequate support from its home community, is low-level and 
>lightweight enough that it can integrate comfortably into another system 
>without bringing a lot of extra baggage. One significant challenge will be 
>UI. Whatever WCM system is adopted should either let you hide the UI or 
>have a UI that is simple and compatible as an overlay to the current 
>"content authoring" capability. That may not be as difficult as it sounds. 
>The current style for "content authoring" is mostly an editable page 
>underneath a WYSIWYG editor, which is a common convention that most WCM 
>systems should be able to handle. Where you may run into more dissonance 
>is on site authoring (i.e., adding and managing multiple pages) and more 
>complex functionality (e.g., workflow).
>
>Ideally, whether the community chooses a third-party component to handle 
>WCM or builds its own capabilities, it would be done in such a way that 
>other alternatives could be swapped in (either by an individual adoptee or 
>by the community, should the third-party component chosen become less 
>desirable down the road) with a manageable amount of work.
>
>- m
>
>
>--
>
>
><http://www.oracle.com>
>Oracle
>
>Michael Feldstein | Principal Product Manager | +1.818.817.2925
>Oracle Academic Enterprise Solutions Group
>23A Glendale Road, Glendale, MA 01229
>_______________________________________________
>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"

--
-- Ed Garay  ITL Blog: www.accc.uic.edu/itl/blog
    Assistant Director for Academic Computing

    University of Illinois at Chicago
    Academic Computing and Communications Center
    ACCC Instructional Technology Lab (ITL)
    www.accc.uic.edu/itl

    Learn something new today!
    Try Lynda.com online tutorials (free) to everyone at UIC
    Visit www.accc.uic.edu/training.html or email workshops at uic.edu