Re: [orca-list] The SayAll user experience

[Christopher Chaltain <chaltain gmail com>]

I would say my answer to question 1 would be option B, just read the 
document text. I'd also say I feel pretty strongly about this.

For question 3, I think the thing I like most about say all is that it 
pretty much works. Once I get to the start of an article on a web page, 
I can just hit say all and take my hands away from the keyboard. It 
seems to bog down from time to time, but it generally keeps going, and 
it's the most efficient way to read an article or a document.

I think the thing I like least about say all is that it doesn't behave 
like option B in question 1. I have to hear words like "heading" and 
"list" and "link". It also seems to slow down when it gets to certain 
chunks of the web page. These two things make reading an article a bit 
slower and more tedious.

To a lesser degree, I also don't like how the say all command is 
interrupted with live region monitoring and other notifications, 
although this isn't a big deal. Ideally, I could kick off a say all and 
not have it interrupted at all. If it needs to be interrupted, it might 
be nice if a voice change could be used for the notification or maybe a 
beep, so there's a clearer auditory distinction between the text of the 
document and the text of the notification.

I know you said we can't have our cake and eat it too, but for those 
times when I'm reading a document I'm editing, and I want to read it 
pretty closely, maybe there could be a proof reading command that would 
keep some of the structural information while reading out the document. 
For me at least, this would be a lower priority feature request, since I 
could still get this by arrowing around and using structural navigation, 
which I'm going to want to do much of the time any way if I'm editing 
the document.

Thanks for the opportunity to provide the input.

On 11/11/2013 09:19 PM, Joanmarie Diggs wrote:
> 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

--
Christopher (CJ)
chaltain at Gmail