Re: [orca-list] The SayAll user experience

["Albert Sten-Clanton" <albert e sten_clanton verizon net>]

Hi, Joanie.

It's close, but my answer to question 1 is a.  Others have given my reasons.
It might be very cool if we could toggle the reading of headings, links, and
other things on and off, as we can live regions, but I know we're already
asking a lot of the keyboard and understand if that's impractical.

I have no braille display, sadly, so I'd better leave question 2 to those
who do.

I can't single out an attribute of SayAll I particularly like, but I use
SayAll a great deal.

Thanks for asking.  Also, as always, thanks for all of your Orca work.

Al 

-----Original Message-----
From: orca-list [mailto:orca-list-bounces gnome org] On Behalf Of Joanmarie
Diggs
Sent: Monday, November 11, 2013 10:20 PM
To: Orca List
Subject: [orca-list] The SayAll user experience

Hey guys.

I was looking at the SayAll code today. Another case where we really need to
get rid of sad hacks, clean things up, eliminate bugs, make the user
experience consistent across scripts, etc., etc. But what the redone version
shall look like depends very heavily on what the desired user experience is,
so I'd like you all to give this some serious consideration. My initial
questions are:

1. The primary purpose of SayAll is:
   A. To present the exact same thing I would hear if I were manually
      arrowing through the document. I just hate those arrow keys.
   B. To present document text and only the document text. If I wanted
      to hear context like heading levels and the number of items in a
      list, I'd arrow through the document or use structural navigation.
      Plus I really hate the pauses that result each time the voice
      changes to present all caps, links, and stuff that is not on
      screen.
   C. Other (please explain in your answer)

   How strongly do you feel about your answer to question 1?

2. The expected behavior of my braille display when using SayAll is:
   A. To keep up at all times with the speech. I can read really fast.
   B. To maintain a totally independent copy of the content being spoken
      so I can scroll through the braille and read one part of the
      document while another part is being spoken.
   C. It's SayAll; not BrailleAll. As long as you update my display
      when SayAll is interrupted or completed, I'm happy.
   D. Other (please explain in your answer)

   How strongly do you feel about your answer to question 2?

   How often do you use a refreshable braille display with Orca?

3. The thing I like most about Orca's current SayAll behavior is.
   (fill in the blank)

   How strongly do you feel about your answer to question 3?

4. The thing I like least about Orca's current SayAll behavior is.
   (fill in the blank)

   How strongly do you feel about your answer to question 4?

The last thing I'd like to ask you to keep in mind is, there's no free
lunch. I can think of use cases for all the choices above and more. But
accomplishing one might necessarily mean not being able to accomplish
another. And the goal is not to make Orca's SayAll do everything under the
sun, but do a merely-ok job of it; instead the goal is to identify the main
thing SayAll should do, and make it do a really good job at that specific
task.

Thanks in advance guys! While you ponder and discuss the above, I'll get
back to all the other refactoring and fixing I'm doing.

--joanie
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca.
The manual is at
http://library.gnome.org/users/gnome-access-guide/nightly/ats-2.html
The FAQ is at http://live.gnome.org/Orca/FrequentlyAskedQuestions
Log bugs and feature requests at http://bugzilla.gnome.org Find out how to
help at http://live.gnome.org/Orca/HowCanIHelp