[DG: Teaching & Learning] [WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities and Accessibility

Eli Cochran eli at media.berkeley.edu
Fri Nov 6 08:44:58 PST 2009


Mike,
I'm not sure that I came to same conclusion by the end of the meeting.

We did hear very compelling first-person experiences that stated that  
A) TinyMCE was still better overall to CKeditor, and B) that the  
overhead of learning and remembering text-based markup was less  
onerous than the constant context switching required to use a rich- 
text editor.

On point B, I'm still very concerned about two issues that came up  
yesterday: markup formats are hard to learn and remember and each one  
is different. Learning and remembering one markup language is fine if  
you use it often but if you're a casual user then it's a pretty steep  
learning curve. If you use more than one then you not only have learn  
each one and remember it, but you have to then remember which  
environment you're in and which one to apply.

But perhaps I am being too cautious... users with disabilities are a  
hardy and dedicated lot -- they have to be to succeed -- and when you  
live in a world with out visual clues there are many things that you  
routinely have to remember. As a sighted user, I continually stand in  
awe each time I watch someone use a screen reader; what a convoluted  
and complex interface just to interact with the complex and convoluted  
interfaces that sighted users must navigate.

I'd like to hear from more folks in the accessibility community on  
both A and B.

My own personal opinion is that the GUI should be the default. It is  
still better for most users. But switching to the text-based editor  
should be very easy to find and easy to do and must be sticky, either  
through a cookie or (ideally) through a user preference.

My two cents,
Eli


On Nov 6, 2009, at 7:27 AM, 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"
>>
>>
>>

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley




More information about the pedagogy mailing list