GNOME Bugzilla – Bug 438333
Need to speak progress bar activity
Last modified: 2008-07-22 19:27:50 UTC
There has been quite a bit of discussion recently on the Orca list regarding the presentation of progress bar activity. I will post excerpts from that discussion as a comment to this bug.
Krishnakant proposed that progress bar information in two ways: Flat review and periodic increments via speech. (http://mail.gnome.org/archives/orca-list/2007-May/msg00049.html). Reactions to periodic announcements were largely (and vociferously) negative. The alternative proposed and largely supported by the group was the use of tones, such as is done by the open source Windows screen reader NVDA. SUPPORTERS * Michael Whapples: http://mail.gnome.org/archives/orca-list/2007-May/msg00050.html * Krishnakant, who rescinded his initial proposal: http://mail.gnome.org/archives/orca-list/2007-May/msg00052.html * Lorenzo: http://mail.gnome.org/archives/orca-list/2007-May/msg00054.html * Krister: http://mail.gnome.org/archives/orca-list/2007-May/msg00055.html CONCERNS * Halim: "Nvda beeps on a progress bar but think about two or three blind in one office and you can have a nervous breakdown." http://mail.gnome.org/archives/orca-list/2007-May/msg00056.html OTHER DISCUSSION * Lorenzo: "This is probably why the NVDA developers felt that the beeps should be able to be turned on and off. So just my opinion, but this is where Orca should copy NVDA. We should have a beeping progress bar that can be turned on and off. And something really cool for Orca and NVDA to do would be to have a 'progress' key that would speak the status of a progress bar on demand if the beep is turned off. The only problem I can see with the key approach is which progress bar to speak if there are multiple progress bars or if speaking all of them how to differentiate one from another." http://mail.gnome.org/archives/orca-list/2007-May/msg00059.html * Hermann: "Sorry folks, but no bells and wizzles! I've to listen to the speech all day long, and it can sometimes be a bit stressful. So I personally don't want to feel like sitting in a comic movie. I think if it would be possible to get into flat review at once, instead of waiting a minute or more, as I often have to do, and then quickly navigate to the progress bar, and finally pressing Orca+Numpad-5, would do the job." http://mail.gnome.org/archives/orca-list/2007-May/msg00063.html * Will, on an approach he considered: "... The idea was that braille would keep updating as progress was made, but speech would just speak complete sentences... The behavior was something like this: On the braille display, you'd see the percentage value update in real time. For speech, however, you might hear "2 percent" "23 percent" "57 percent" "83 percent" "100 percent", where all intervening percentage changes would not be spoken because speech was currently busy. In looking at the code, it looks like I also had it speaking the label of the progress bar, presumably to handle windows similar to Evolution's send/receive dialog that presents two simultaneously changing progress bars, or perhaps Firefox's download window that presents the status of simultaneous downloads." http://mail.gnome.org/archives/orca-list/2007-May/msg00061.html The response to real-time braille updating was limited but positive. As for the beeps/tones: * Krister reiterated his desire for "beepomania" because it is faster than speech. http://mail.gnome.org/archives/orca-list/2007-May/msg00064.html * Hermann reiterated his desire to be able to adjust/configure the beepomania should we go that route. http://mail.gnome.org/archives/orca-list/2007-May/msg00065.html * Lorenzo: "I still prefer the rising beeps or possibly the glass filling with water if such a sound can in fact reflect the actual percentage on the progress bar. NVDA's beep starts low and gets higher as the percentage on the progress bar gets higher. And the beep doesn't have to be loud, it just has to be audible. Something like a background sound. I hope this properly explains my preference. I guess the non-busy speaking of percentages may be preferable to some people, so there maybe should be a preference to use one or the other or neither, something like a realtime progress bar status option with radio buttons for speech, beep or off." http://mail.gnome.org/archives/orca-list/2007-May/msg00067.html
For clarification: The users still want access to progress bar information via flat review as well. :-)
Okay, I've read all the discussion. Will, how do you want me to implement this?
(In reply to comment #3) > Okay, I've read all the discussion. Will, how do you want me to implement this? > Please make some suggestions for what you think might address the various concerns expressed by the users. If needed, you and Mike should probably work on this together..
Will spoke to Mike, who is going to spec this out.
The following information pertains to speech only. Braille will be handled at another time. We'll want to add a "speeck progress bar updates" edit field to the speech page of the orca config UI. This value will be noted in seconds. The default value will be 10. With the value of 10 the following should happen. If a progress bar appears in the application with focus its current value should be read every 10 seconds. Orca should only speak however if the value of the progress bar has changed from the last time it was spoken. If the value is set to "0" progress bar updates should not be spoken at all. If the application with the progress bar does not have focus the progress bar changes should not be spoken.
Created attachment 90278 [details] [review] Patch to implement speech. Implementation of speech support for progress bars as outlined by Mike in comment #6, plus the following changes (per email from Will): - Adjust the GUI for this particular feature to have a checkbox and a separate label/spin button. ie.: [ ] Speak Progress Bar Updates Update Interval: ( 10 ) where the label/spin button pair would be inactivate/grayed if the checkbox wasn't checked, and the interval spin button went from 1 upwards in intervals of 1 with a default value of 10. - When progress bar is at 100%, we should present it, regardless of the interval. - There may be cases when more than one progress bar is updating at the same time in a window. If the last progress bar update wasn't for the current progress bar, speak the label (if any) of this progress bar as well as the value. Note that the progress bar currentValue isn't always a value in the range 0-100. You need to look at the minimumValue and the maximumValue to determine the range. Also fixed speechgenerator._getSpeechForProgressBar to reflect this. One thing that should be noted here is that in the different instances where this was tested (sound-juicer, update manager, Firefox, Thunderbird), none of the progress bars had labels. This means that we probably need to come up with a better way of differentiating between multiple progress bars in the same application. One possible way is just to number them, so that Orca would speak something like: "Progress bar 1. 4 percent" "Progress bar 2. 35 percent" ... If there is only one progress bar, then this "label" wouldn't be spoken (i.e. you just get "4 percent").
So far this is really cool. It's nice to actually get an idea what is going on when copying large files across the network. I'll try other apps but so far I like it. I'm OK with your proposal for multiple progressbars as well. thanks
I've given this some more testing and am still quite happy with it. Lets change the default to checked though.
Created attachment 90290 [details] [review] Revised patch. Revised patch makes the following changes: 1/ Checkbox state is initially on. 2/ Now prepends "Progress bar <n>." when there are multiple progress bars going at the same time. One thing to note here, is that if the progress bar gets to 100%, then we can nicely remove it from the dictionaries of known progress bars. If the user just cancels the operation that invoked a progress bar, this can't be done. All this really means is that we will have a "bogus" entry in the progress bar dictionary, and from then on, you will always get the progress bar index value spoken. If anybody can suggest a way to improve this, I'm all ears. The other thing to note is that I'm now keeping a "last time" and a "last value" for each progress bar. So you will get updates spoken for each progress bar, as if it was a single progress bar. In other words, by default every ten seconds if the application with the progress bars has focus. This nicely simplified the program logic and seems to be more sensible to me. If this needs to be changed, let me know.
> > One thing to note here, is that if the progress bar gets to 100%, > then we can nicely remove it from the dictionaries of known progress > bars. If the user just cancels the operation that invoked a progress > bar, this can't be done. All this really means is that we will have a > "bogus" entry in the progress bar dictionary, and from then on, you > will always get the progress bar index value spoken. If anybody can > suggest a way to improve this, I'm all ears. I'm confused when will I actually here this bogus value spoken? > > The other thing to note is that I'm now keeping a "last time" and a > "last value" for each progress bar. So you will get updates spoken > for each progress bar, as if it was a single progress bar. In other > words, by default every ten seconds if the application with the progress > bars has focus. This nicely simplified the program logic and seems to > be more sensible to me. If this needs to be changed, let me know. > This sounds like a good idea. Do you have a test case with multiple progress bars where I can test this?
> I'm confused when will I actually here this bogus value spoken? If you ever have had two progress bars and you didn't let them go to completition, then from then on, whenever you have another progress bar, irrespective of whether it's the only one, it'll speak "Progress bar <n>" (where <n> is the number of cancelled progress bars) before it speaks the "<whatever> percent". > This sounds like a good idea. Do you have a test case with multiple > progress bars where I can test this? Joanie has a good one. "If you copy two really large files in Nautilus, but do them as separate tasks, you'll get two physical windows but functionally I believe it's the same condition you're looking for because there are two progress bars from the same app. The way I tested this is to enter an ftp site in the location entry: ftp://cdimage.ubuntu.com/cdimage/releases/gutsy/tribe-1 Then I dragged the icon for one CD image to my Desktop, and then did the same for another image." I'm not sure what the keyboard equivalent of dragging is, but you get the idea.
> bars. If the user just cancels the operation that invoked a progress > bar, this can't be done. What about this: In handleProgressBarUpdate() if it's time to do an update, first do a check on the state for each item in one of your two dictionaries. If the item's state is STATE_DEFUNCT (which it seems it will be if you cancel the operation that invoked the progress bar), delete it from both dictionaries.
Sounds good. Will just said something like that too. I'll add it into the next patch (this afternoon). Thanks.
Created attachment 90299 [details] [review] Further revised patch. After discussing this with Will, the simplest thing is to not to try to delete the entries when they complete or become defunct, as the index number you use the identify progress bars that are still in operation will potentially reduce by one. Here's a revised patch to remove the deletion code for the 100% case.
Created attachment 90305 [details] [review] Even further revised patch. We now determine for Firefox whether this progress bar event should be spoken or not. For Firefox, we don't want to speak the small "page load" progress bar. All other Firefox progress bars get passed onto the parent class for handling. Mike, please test.
This is now sounding good to me.
Okay. Patch committed. Do we have a separate bug for the braille support or will you add it here Mike?
We'll handle braille elsewhere because it will fall out of some other work Will is doing.
> We'll handle braille elsewhere because it will fall out of some other work Will > is doing. Putting the bug in a "[pending]" state then.
(In reply to comment #19) > We'll handle braille elsewhere because it will fall out of some other work Will > is doing. What work is that? :-)
I think the work you are doing with flat review as well as phisical mode are going to make the spec here a lot different than speech. I say this because I'l like to seperate speech from braille until this other work is done.
Works great
Closing as FIXED if we aren't doing braille support at this time. We can open another bug report for that when the time is right. Adjusting the bug Summary through to better reflect what has been done here.