Re: [orca-list] The SayAll user experience

[Fernando Botelho <fernando botelho f123 org>]

I agree with most of this.

I like to use Say All to read something from beginning to end and the 
times it slows down are annoying. I also do not need any information 
about structure etc while using say all.

I would also like it to not be interrupted with live region monitoring, 
although I understand how this might be important for some people in 
some situations. So maybe the way to go here is just for me and others 
to turn live region monitoring off.

Thanks for asking us for feedback,

Fernando



On 11/12/2013 03:34 AM, Christopher Chaltain wrote:
> 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