[WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities and Accessibility

Ken Petri petri.1 at osu.edu
Wed Nov 11 15:23:17 PST 2009 

Link to MarkItUp: http://markitup.jaysalvat.com/home/


On Wed, Nov 11, 2009 at 6:22 PM, Ken Petri <petri.1 at osu.edu> wrote:

> Adding to implementations, an editor that does wiki, markdown, and textile
> is Jay Salvat's MarkItUp (). It is interesting in particular because it
> provides set of keyboard shortcuts and buttons for generating these
> syntaxes, thereby reducing the learning curve.
>
> As to the CK v. Tiny debate: It was mentioned in another thread that it
> might be worth Sakai revisiting the choice of Tiny. The points from Brian,
> Joe, and Mary, and Margaret's investigation are well-taken. Still, in a
> head-to-head, I'm not sure Tiny fairs much better, and may fair worse. For
> example, the implementation of drop-downs in Tiny is no better and often
> much worse and the "tab through toolbar controls" metaphor that Tiny uses is
> less true to a desktop WYSIWYG than the "arrow key" approach CK takes. The
> problem that CK has with not telling the user how to get to the toolbar
> controls can be overcome with a small bit of text announcing the
> functionality.
>
> The point may be moot, though, if you decide to go with the recommended
> "user chooses" model of text-based/markdown/textile/wiki or WYSIWYG or
> upload.
>
> My two cents,
> ken
> ----
>
>
>
> On Fri, Nov 6, 2009 at 2:59 PM, Richwine, Brian L <brichwin at indiana.edu>wrote:
>
>> > Is Markup known as the dominant
>> > syntax in the world of accessible
>> > editors, or was it just an example?
>>
>> In our experience, there isn't a dominant syntax for an accessible markup
>> language, nor is there a dominant accessible WYSIWYG/GUI/Rich Text Editor.
>>
>> The conversation seems to be running between choosing a single
>> "accessible" editor, or providing a choice of editor and/or upload option.
>> The answer seems larger than just the accessibility concerns, but concerns
>> of both usability and product design specification as well. A well designed
>> user experience study to test between the usability of the WYSIWYG editors
>> and the text-based/wiki style editors would yield important information to
>> aid in making the decision. Obviously there are other concerns (technical,
>> user feature requests,...), but as there doesn't seem to be a consensus in
>> the community we think such a study would be of value.
>>
>> If it was seen as valuable, the ATC is happy to help with performing such
>> a usability study and welcomes others to help.
>>
>> Are current feeling is that having both editor options (WYSIWYG and
>> text-based) along with the option for uploading content is best.
>>
>>
>> -Joe Humbert, Margaret Londergan, Brian Richwine, Mary Stores
>>
>> Adaptive Technology and Accessibility Centers
>> Indiana University - Bloomington/Indianapolis
>> http://iuadapts.indiana.edu
>> (812) 856-4112
>>
>>
>>
>> -----Original Message-----
>> From: accessibility-bounces at collab.sakaiproject.org [mailto:
>> accessibility-bounces at collab.sakaiproject.org] On Behalf Of John Norman
>> Sent: Friday, November 06, 2009 11:21 AM
>> To: Michael S Elledge
>> Cc: management; pedagogy Learning; Sakai Accessibility WG
>> Subject: Re: [WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities
>> and Accessibility
>>
>> 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"
>> >>
>> >>
>> >>
>>
>> _______________________________________________
>> 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"
>> _______________________________________________
>> 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"
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20091111/52d7e942/attachment-0001.html

More information about the accessibility mailing list