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

Sat Apr 4 10:36:15 PDT 2009

While we are talking about "basics", one that hasn't been specifically
mentioned is the ability to copy and paste from a word processor and
keep  the formatting. This is a very specific common denominator that
IE8 has broken to a new "level".

Rita Pavolka

On Apr 4, 2009, at 11:30 AM, "Jason Shao (CampusEAI Consortium)" <jason_shao at campuseai.org
 > wrote:

>> From a functionality/architecture point of view, the idea of loosly
>> coupled
> integrations with external services like wikis, or Google Apps, or
> other
> tools seems very attractive.
>
> *however*
>
> There are significant horizontal capability components that while not
> impossible to resolve may complicate that scenario. Initial thoughts:
>
> * TOS - ensuring users understand external, but integrated tools may
> have
> separate terms of service, SLAs, data ownership/retention policies,
> etc.
> * import/export - I think the ability to "package" and port a
> course/site/project or archive it is something that lots of people
> want.
> Again possible (treat external resources as links? Embed their
> content?
> Cry?) but I think it has some strong implications in user experience
> and
> architecture
> * Search - this one might actually be a bit more straightforward
>
> I will make the observation/parallel from the portal world -
> CampusEAI is
> currently heavily involved in building out a social portal, that
> combines
> the integration of enterprise services & applications with natively
> managed
> content like blogs, wikis, discussions, profile, etc. As we continue
> to get
> further down this road, some interesting intersections between user
> expectations and boundaries between external and internal content
> continue
> to present themselves up.
>
> So far the balance we've come up with is largely - some stuff is in,
> some
> stuff is out, but there's continual tension on the boarders of that
> distinction, and I'm not confident that that particular firewall
> will hold
> or be appropriate in the long run.
>
> Not sure I have good answers for you :) Just a brain-dump of my
> internal
> thought processes these days.
>
> Jason
>
> On 4/4/09 11:12 AM, "Nate Angell" <nate.angell at rsmart.com> wrote:
>
>> It is these kind of decisions that I was thinking about in my recent
>> blog post about lessons Sakai might take from Drupal:
>> http://xolotl.org/node319
>>
>> I believe basic content authoring should be part of Sakai's core
>> functionality. Collaborative, wiki-style authoring is also core to
>> Sakai's purposes as recently defined by Michael Korcuska. Wiki
>> requirements are so few above and beyond those for other modes of
>> authoring, I think they could be part of core as John Norman
>> suggests.
>>
>> If we deem wikis outside Sakai core, then the best path is not to
>> choose a single wiki to integrate (woe our integration with *only*
>> the
>> oft-maligned, unfortunately-named FCKeditor), but to make easy
>> integration with *any* external wiki possible.
>>
>> My rule if thumb would be: either core and generic, or pluggable and
>> open.
>>
>> On Apr 4, 2009, at 5:11 AM, DAVID ROLDAN MARTINEZ <darolmar at upvnet.upv.es
>>> wrote:
>>
>>> Yes, very interesting conversation. From my point of view those four
>>> characteristics (simple versioning/rollback, WYSIWYG, easy page
>>> generation and page linking, basic level of access control) should
>>> apply to all ways of content generation in Sakai 3.x as they
>>> contribute to make the environment much more intuitive and usable.
>>>
>>> Relating to integrate existing products within Sakai...Chris, I
>>> completely agree with you.. Diego del Blanco and me were talking
>>> about this last week. There's no sense in develop what is developed
>>> yet. If there is a powerful solution or an application that
>>> everybody use, why don't to get it integrated in Sakai? The problem
>>> then is which criteria follow to determine to-be-integrated app? Do
>>> we integrate only standard-compilant app or do we develop a wrapper
>>> layer to be able to integrate several app?
>>>
>>> David
>>> ________________________________________
>>> De: sakai-ux-bounces at collab.sakaiproject.org
>>> [sakai-ux-bounces at collab.sakaiproject.org
>>> ] En nombre de Christopher D. Coppola [chris.coppola at rsmart.com]
>>> Enviado el: viernes, 03 de abril de 2009 21:56
>>> Para: John Ansorge
>>> CC: Sakai UX; pedagogy Learning
>>> Asunto: Re: [DG: User Experience] [DG: Teaching & Learning] Wiki's
>>> and Sakai
>>>
>>> Interesting conversation. Nate Angell and I were talking about this
>>> the other day and agree that these are the desirable
>>> characteristics. There's a screen cast of a product called Mindtouch
>>> Deki that I think demonstrates these essential elements. They stay
>>> away from calling their product (which is open source) a wiki. It
>>> doesn't use wiki text, it uses standards compliant xhtml. Check out
>>> the screencast: http://www.mindtouch.com/
>>>
>>> Another potential solution at least for the 2.x branch that we've
>>> been talking about is to integrate with an existing product like
>>> this. Anyone else thinking about that?
>>>
>>> /chris
>>> --
>>> rSmart
>>> Chris Coppola | 602.490.0472
>>> blog: coppola.rsmart.com<http://coppola.rsmart.com/>
>>>
>>> On Apr 3, 2009, at 12:07 PM, John Ansorge wrote:
>>>
>>> I completely agree that the Sakai 3 content authoring shows great
>>> promise and it would be great to see a little bit of that
>>> functionality function in 2.x.
>>>
>>> While wiki syntax can be useful, I think for most student and
>>> faculty needs WYSIWYG is far more desirable.  I think what most of
>>> our instructors/students are looking for in the wiki is this:
>>>
>>> *   simple versioning/rollback
>>> *   WYSIWYG
>>> *   easy page generation and page linking
>>> *   basic level of access control (group-aware would be great, but
>>> role-based is ok, too)
>>>
>>> That's enough to allow group collaboration on a project in the wiki
>>> tool without needing to know wiki markup.  The current wiki is
>>> close, but I don't think we should underestimate the learning curve
>>> that wiki-markup presents for many users.  It's really easy for a
>>> typo or small formatting mistake to mess up an entire page when we
>>> leave it to humans to generate markup code.
>>>
>>> John Norman wrote:
>>>
>>> FWIW we see the content authoring solution planned for Sakai 3 as
>>> combining the best of both worlds for site creation and wiki
>>> pages. We
>>> haven't quite figured out what the UX should be to separate out
>>> 'wiki'
>>> use of authoring (i.e. students can edit pages) from 'content
>>> management' use of authoring (site owners - faculty - can edit
>>> pages),
>>> but the technology is there.
>>>
>>> So there are (at least) two options for a collaborative project:
>>> 1. Fix up the nearly done work that exists (should be a small task)
>>> 2. Introduce the content authoring paradigm into the Sakai 2
>>> roadmap.
>>> Mostly working, a step towards Sakai 3, but with a larger QA load
>>> and
>>> requiring JCR to be active in the deployment.
>>>
>>> Michael's Sakai 3 demo (running on Sakai 2.5/K1) shows what this
>>> intermediate solution might look like (focus on the 'create new web
>>> page' parts and imagine you give your students permission to do
>>> this).
>>> There would almost certainly need to be some UX work to make this
>>> work
>>> well for a combined 'content management' and 'wiki' scenario.
>>>
>>> John
>>>
>>> On 2 Apr 2009, at 01:37, Hardman, Gloria wrote:
>>>
>>>
>>>
>>> Hello all
>>>
>>> Our faculty have generally found the Wiki too difficult as well.  A
>>> few have done wonders with it and their students participated with
>>> enthusiasm.     For most, it is too much effort to figure it all
>>> out.
>>>
>>> For those who have used more user-friendly Wiki software it is hard
>>> to understand why we can't offer a more user-friendly solution.
>>>
>>> We were also hoping for a better editor in 2.6.
>>>
>>>
>>> All the best
>>>
>>> Gloria
>>>
>>>
>>> On 4/1/09 4:59 PM, "May, Megan Marie"
>>> <mmmay at indiana.edu><mailto:mmmay at indiana.edu
>>>> wrote:
>>>
>>> Hi everyone,
>>> Here at IU we're disappointed that the WYSIWYG editing capabilities
>>> aren't going to make the 2.6.0 release (see message below for the
>>> announcement/rationale).     We've found that faculty try the wiki
>>> in Sakai but end up switching to free and inexpensive hosted
>>> solutions because they are so much easier to use.   Obviously, the
>>> wysiwyg would greatly improve the user experience but it wouldn't
>>> resolve the 'ease of use' issues we're hearing about.  This has made
>>> us wonder if it might be wise to explore other options, like
>>> integration with existing wiki applications.
>>>
>>> Do other institutions receive similar feedback?   Has anyone looked
>>> into integrating Sakai with a different wiki solution?
>>>
>>> Thanks,
>>> Megan
>>>
>>>
>>>
>>>
>>> From: Pete Peterson [mailto:plpeterson at ucdavis.edu]
>>> Sent: Thursday, March 26, 2009 4:45 PM
>>> To: 'Sakai Developers'; 'Sakai QA';
>>> production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org
>>>>
>>> Cc: Michael Korcuska; Knoop, Peter; Anthony Whyte; Pete Peterson;
>>> May, Megan Marie; Stephen Swinsburg; David Horwitz
>>> Subject: Important information about Sakai 2.6.0 and the rWiki tool
>>>
>>> Greetings Sakai Community,
>>>
>>> We have been unable to resolve a number of issues with the 2.6 rwiki
>>> code, centered around the WYSIWYG editing capabilities and data loss
>>> under certain conditions.  At this point in the release cycle we are
>>> opting to replace it with the 2.5.x version of rwiki, making the
>>> necessary changes to make it compatible with the 2.6 codebase.  We
>>> are also re-applying some of the minor fixes and improvements
>>> intended for the 2.6 version of rwiki to the 2.5.x-based version
>>> (see SAK-15866
>>> <http://jira.sakaiproject.org/jira/browse/SAK-15866><http://jira.sakaiproject
>>> .org/jira/browse/SAK-15866
>>>> <http://jira.sakaiproject.org/jira/browse/SAK-15866
>>>
>>>
>>> for more details).
>>>
>>>
>>> Summary
>>> *        We have rolled the rwiki code back to the 2.5 version which
>>> has proven stable in many production instances.
>>>
>>> ·        Many of the updated rwiki features that are present in
>>> trunk/ the original 2.6 version, have been merged back into this
>>> version. Details of this effort can be viewed at SAK-15866
>>> <http://jira.sakaiproject.org/jira/browse/SAK-15866
>>>
>>>
>>> <http://jira.sakaiproject.org/jira/browse/SAK-15866><http://jira.sakaiproject
>>> .org/jira/browse/SAK-15866
>>>> (many thanks
>>>
>>>
>>> to Steve Swinsburg for his work on this issue).
>>>
>>> *        This new hybrid-rwiki has been tested and seems to work as
>>> expected.
>>>
>>>
>>> With regards to the WYSIWYG editing capabilities for rwiki scheduled
>>> for inclusion in  Sakai 2.6 (SAK-8535
>>> <http://jira.sakaiproject.org/jira/browse/SAK-8535
>>>
>>>
>>> <http://jira.sakaiproject.org/jira/browse/SAK-8535><http://jira.sakaiproject
>>> .
>>> org/jira/browse/SAK-8535
>>>> ), we will
>>>
>>>
>>> continue explore options for implementing such functionality at a
>>> later time.  This is an oft requested features, so if you are
>>> interested in helping us explore and implement possible solutions,
>>> please contact Peter Knoop <mailto:knoop at umich.edu><mailto:knoop at umich.edu
>>>> <mailto:knoop at umich.edu
>>>
>>>
>>> , Sakai Project Coordinator.
>>>
>>>
>>> If you have any questions, comments or suggestions please send them
>>> to us by 3/31/2009.
>>>
>>> Thank you for your time and support,
>>>
>>> Pete Peterson
>>> QA Director, Sakai Foundation
>>> plpeterson at ucdavis.edu<mailto:plpeterson at ucdavis.edu>
>>> Phone: +1-530-754-7259
>>>
>>>
>>> ________________________________
>>>
>>>
>>> This automatic notification message was sent by Oncourse
>>> (https://oncourse.iu.edu/portal
>>> ) from the Support Team site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux at collab.sakaiproject.org<mailto: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
>>> <mailto:sakai-ux-unsubscribe at collab.sakaiproject.org>
>>> with a subject of "unsubscribe"
>>>
>>>
>>> _______________________________________________
>>> pedagogy mailing list
>>> pedagogy at collab.sakaiproject.org<mailto:pedagogy at collab.sakaiproject.org
>>>>
>>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>>
>>> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org
>>> <mailto:pedagogy-unsubscribe at collab.sakaiproject.org> with a subject
>>> of "unsubscribe"
>>>
>>>
>>> _______________________________________________
>>> 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"
>> _______________________________________________
>> 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"
>>
>
> --
> 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"