[DG: Teaching & Learning] [DG: User Experience] Wiki's and Sakai
Michael Feldstein
michael.feldstein at oracle.com
Sun Apr 5 09:26:48 PDT 2009
Unfortunately, this conversation is saddled with several terms that are
not helping us gain clarity. One of them is "content authoring". As has
been discussed already elsewhere, the initiative labeled "content
authoring" in the 3akai design efforts really isn't about content (at
least not primarily), and I'm not really sure that it's about authoring
as we commonly use the term either. It's about creating a flexible
learning environment, where a fusion of both functionality and content
are far more malleable for the instructor than they are in a traditional
LMS. To get at why the content/functionality distinction breaks down,
think about a spreadsheet used for, say, a business class case study of
a business. Is the locus of value of the spreadsheet in the numbers
about the business' financial performance (i.e., the content) or the
formulas that turn those raw numbers into meaningful business metrics
(i.e., the functionality)? It may be a meaningless question. You need
both. Likewise, consider a page of content that is meant to be a
conversation starter for a discussion thread. Whatever we're trying to
do with "content authoring," it's not simply content authoring.
The second misleading word here is "wiki". What seems to be meant by the
term in this conversation is the following set up capabilities:
* Collaborative user editing of hypertext
* Easy linking from one hypertext page to another
* Versioning of content, possibly with rollback
* At least some distinct levels of access and editing permissions
What it may or may not include are the specific trappings of wiki
technologies and conventions, particularly wiki syntax.
An interesting thing happens when you drop the extra baggage that comes
with both of these terms and focus instead on the requirements and
affordances. As has been pointed out, the 3akai "content authoring"
capability already includes at least two of the four "wiki"
requirements, i.e., editing of hypertext and easy linking from one
hypertext page to another. Versioning is something that is supported by
the JCR standard (the current version of which is JSR-170), so it should
be supportable as part of the Sakai 3 core. (There may be some question
regarding whether the current version of JCR is adequate to the need
here or whether the community will need to wait for the next version,
which Jackrabbit will certainly support. That's really beyond my level
of technical competence to address. The main general point is that there
is a relatively obvious path to explore here.) You'd need a UI for
versioning and rollback, but there are plenty of good models for that.
The other element, permissions, strikes me as a minor enhancement (if
even that) of what has to be done anyway for "content authoring" as it
is currently conceived. There are already plans to decide who can edit a
page and who can view a page. The implementation plans may need to be
checked to see if they handle the wiki-like collective authoring use
case efficiently, and there may need to be a permission level added for
version roll-back, but the basics already need to be there.
If you *were* to combine these two requirements sets, what would you
have when you're done? You would have have a versioned and collectively
editable *learning environment*. Maybe it's WLE, a Wiki'ed Learning
Environment. Remember, the versioning and collective editing taking
place would include both text and functionality widgets (or vignettes,
in Sakai parlance). I think this could very powerful.
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.
- m
Nate Angell wrote:
> 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"
>>>
>>>
> _______________________________________________
> 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"
--
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/20090405/67d4bae6/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/20090405/67d4bae6/attachment-0001.gif
More information about the pedagogy
mailing list