[DG: Teaching & Learning] [WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities and Accessibility
John Norman
john at caret.cam.ac.uk
Fri Nov 6 08:20:42 PST 2009
I'm out of my depth here, but does the TinyMCE example 9 (implementing
BBCode syntax) indicate a way forward? I confess I had never heard of
markdown, so I Googled TinyMCE and Markdown to find:
http://www.sitepoint.com/forums/showthread.php?t=590572
Then Wikipedia on Markdown
http://en.wikipedia.org/wiki/Markdown
Which led me to a JS implementation, Showdown:
http://attacklab.net/showdown/
So now I have the idea that Markdown is both a syntax and an editor
and the editor stores information in non-html form. This seems to be
very similar to using wiki markup and I found this page on lightweight
markup which suggests MediaWiki syntax and BBCode are in the same family
http://en.wikipedia.org/wiki/Lightweight_markup_language
Armed with this picture of what Mike may be suggesting, I get to his
question: Do we know how often a rich text editor is used and needed?
My response is based on the Wiki in Sakai 2. We discussed (and even
did proof of concept) for inserting gadgets into wiki pages. The main
reason we chose to use TinyMCE instead, was the preponderance of
Faculty demand for WYSIWYG *or* html editing. Comments like "why are
you making me learn some new markup, when I know html?" and "why can't
I just edit it like a word document?" were common. There were only a
few who expressed "I encourage students to learn Wiki markup because
it is useful for them to know how Wiki's work". Now of course, Wiki
markup was available so you wouldn't expect many requests for it, but
it seems (anecdotally) like a minority sport.
My guess would be that if BBCode can be supported in TinyMCE (now that
I know Markup is lightweight markup, like BBCode) then that would be
the easiest way to go. I imagine that we will need to do work to
implement the extensions/plugins we have used to insert gadgets in the
page. And it seems like an important choice might be: which
lightweight syntax to implement? Is Markup known as the dominant
syntax in the world of accessible editors, or was it just an example?
Sorry for taking you through my ignorance, but I thought it might be
useful for fellow novices. Corrections welcome.
John
On 6 Nov 2009, at 15:27, Michael S Elledge wrote:
> Hi Eli (and everyone)--
>
> It sounds like providing a text-based editor (with markdown or wiki
> markup) and using TinyMC as the rich text editor (rather than
> CKeditor) is the way to go, per our conference call yesterday on
> accessibility, Indiana University's testing and John Norman's
> comments about Sakai 3 plans (to replace FCK with Tiny).
>
> I wonder if we shouldn't make the text-based editor the default,
> with rich text editing the option, instead of the other way around.
> Do we know often a rich text editor is used and needed?
>
> What do you think?
>
> Mike
>
> Daphne Ogle wrote:
>> On Nov 5, 2009, at 9:10 AM, Eli Cochran wrote:
>>
>>
>>> But really, all we really need are simply stated accessibility goals
>>> for Sakai 3.
>>>
>> We started a new sheet for usability/design goals. They aren't
>> pedagogical goals yet in discussion we felt we didn't want lose
>> the ideas. I think accessibility goals would fit nicely on that
>> sheet too.
>>
>> -Daphne
>>
>>> - Eli
>>>
>>>
>>> On Nov 4, 2009, at 10:34 AM, kamann at stanford.edu wrote:
>>>
>>>
>>>> Hi,
>>>> I was on the T&L call where people were talking about this Learning
>>>> Capabilities matrix
>>>> https://spreadsheets.google.com/ccc?key=0AlfbHxo2qpHEdHRuSnowVGMwWE9HY1MtVjFpY1dtS0E&hl=en
>>>>
>>>> Clay sent a notes saying the list started out around learning and
>>>> teaching goals, but there were a few entries that jumped ahead to
>>>> the technnology like "Allow me to listen to class readings with a
>>>> screen reader." This was written from the perspective a persona
>>>> from
>>>> the Fluid project with low vision. We were struggling with what the
>>>> goal during the call and I'm not sure we got there, but we knew her
>>>> goal wasn't to use a screen reader. On further reflection, the
>>>> visually impaired student's goals here is the same as any other
>>>> student:
>>>>
>>>> "Easily review class readings and materials"
>>>>
>>>> This is actually not yet a row in the list, but I'll add it --
>>>> perhaps the accessibility considerations should be called out as an
>>>> additional column?
>>>>
>>>> I mentioned that this reminded me of another thread from the
>>>> management list -- it's posted below. Nate Angell, in response I
>>>> believe to John Norman's Manifesto for Grading and Rating, began a
>>>> list of what he's also calling "capabilities" such as
>>>> accessibility,
>>>> discoverability, searchability, and tagability
>>>>
>>>> http://wiki.sakaiproject.org/display/MGT/Sakai+3+Capabilities
>>>>
>>>> These capabilities seem more like technological principles that cut
>>>> across at right angles to the list that T&L is putting together--
>>>> that is, that the way these learning capabilities will manifest
>>>> themselves will be by employing these general principles, that Nate
>>>> has started to outline. That may be overly simplified, but it kind
>>>> of looks that way.
>>>>
>>>>
>>>> Keli
>>>>
>>>> ----- Forwarded Message -----
>>>> From: "Eli Cochran" <eli at media.berkeley.edu>
>>>> To: "Nate Angell" <nate.angell at rsmart.com>
>>>> Cc: management at collab.sakaiproject.org, "sakai-dev Developers" <sakai-dev at collab.sakaiproject.org
>>>> Sent: Monday, November 2, 2009 9:22:10 AM GMT -08:00 US/
>>>> Canada Pacific
>>>> Subject: Re: [Management] Sakai 3 Capabilities
>>>>
>>>> Nate,
>>>> Very helpful. I love the idea of having it all in one place.
>>>>
>>>> At first I wanted to pull some of the items like "accessibility"
>>>> and
>>>> "rights and permissions" into their own list. They seem
>>>> different than
>>>> functionality that specifically supports teaching and learning.
>>>>
>>>> But the more I think about it the more I like the one list to rule
>>>> them all. It supports the idea that most of these concepts should
>>>> be,
>>>> like "Grading/Ranking/Rating/Reviewing/Evaluating", pervasive and
>>>> omnipresent -- baked in everywhere -- in the same way that
>>>> accessibility should be baked in everywhere and supported by the
>>>> underlying architecture.
>>>>
>>>> Thanks,
>>>> Eli
>>>>
>>>> On Oct 28, 2009, at 2:38 AM, Nate Angell wrote:
>>>>
>>>>
>>>>> Like many of you, I've been frustrated by my ability to put my
>>>>> head
>>>>> around the conversations and intersections around Sakai 3.
>>>>>
>>>>> After a conversation with Clay, I decided to put together a
>>>>> stab at a
>>>>> wiki presentation of a Sakai 3 dashboard that might help us
>>>>> organize
>>>>> and better understand our work.
>>>>>
>>>>> Accordingly, I've posted the bones of an example below, where I've
>>>>> begun a list of capabilities already under discussion for Sakai 3:
>>>>> http://wiki.sakaiproject.org/display/MGT/Sakai+3+Capabilities
>>>>>
>>>>> And I began to flesh out one example capability: Grading:
>>>>> http://wiki.sakaiproject.org/display/MGT/Gradability
>>>>>
>>>>> Still missing from Gradability are examples of actual (user)
>>>>> experiences and technologies used to deliver this capability.
>>>>>
>>>>> There are at least a couple of limitations I see already to this
>>>>> format, but I'm open to suggestions and modifications:
>>>>>
>>>>> 1) Sakai 3 work is highly relational, yet it's handy to see
>>>>> material
>>>>> in context. I already found myself cutting and pasting material
>>>>> that
>>>>> might appear in more than one place.
>>>>>
>>>>> 2) The wiki format doesn't allow a preview of the "card" format,
>>>>> yet
>>>>> the card format allows chunks of info to surface at the top of the
>>>>> page.
>>>>>
>>>>> --
>>>>> Nate Angell
>>>>> Client Evangelist
>>>>> @xolotl = twitter
>>>>> http://www.rsmart.com
>>>>>
>>>>> _______________________________________________
>>>>> management mailing list
>>>>> management at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>>>
>>>>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
>>>>> with a subject of "unsubscribe"
>>>>>
>>>> . . . . . . . . . . . . . . . . . . .
>>>>
>>>> Eli Cochran
>>>> user interaction developer
>>>> ETS, UC Berkeley
>>>>
>>>>
>>>> _______________________________________________
>>>> management mailing list
>>>> management at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>>
>>>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
>>>> with a subject of "unsubscribe"
>>>> _______________________________________________
>>>> management mailing list
>>>> management at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>>
>>>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
>>>> with a subject of "unsubscribe"
>>>>
>>> . . . . . . . . . . . . . . . . . . .
>>>
>>> Eli Cochran
>>> user interaction developer
>>> ETS, UC Berkeley
>>>
>>>
>>> _______________________________________________
>>> accessibility mailing list
>>> accessibility at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>>
>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>>
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at media.berkeley.edu
>> cell (925)348-4372
>>
>>
>>
>>
>> _______________________________________________
>> accessibility mailing list
>> accessibility at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>
>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>>
>>
>>
More information about the pedagogy
mailing list