[DG: Teaching & Learning] [DG: User Experience] Wiki's and Sakai
Nate Angell
nate.angell at rsmart.com
Sun Apr 5 08:22:49 PDT 2009
I'm all for plugability, but even setting aside the complexities
Jason, Steven & Sean raise, I still think the fundamental question is
whether content authoring should be a core Sakai function.
I think the answer is yes. And if we are to have content authoring,
collaborative, wiki-like authoring should be part of it too.
Once there were a standard for authoring/wikis like JSR-170 offers for
storage, we might consider supporting it, but that's a long way off I
believe.
Even so, Sakai OOTB should always enable me to author without having
to run a separate service.
That's where I'd draw the boundaries ;)
On Apr 5, 2009, at 5:41 AM, Sean Keesler <sean at keesler.org> wrote:
> Add to Jason't list "reports", which may be like "Search" but has
> enterprise implications.
> If "everything is content" and the content is enterprise related and
> categorized with tags that have meaning (possibly at the enterprise
> level), it would seem that you want the ability to warehouse that data
> for use later.
>
> Sean
>
>
>
> On Sat, 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"
>>
More information about the pedagogy
mailing list