Re: [orca-list] Calling all braille users. I need your opinions.

[Jacob Schmude <j schmude gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi
Well, I use braille as a supplement to speech, so I'm not sure how valid
my opinions are from a purely Braille perspective. But anyway...
On 05/09/2010 08:18 PM, Joanmarie Diggs wrote:
> Action item 1: I will add the ability to specify the duration to the
> Preferences dialog.
>
> Question 1a: I think seconds is preferable to milliseconds as far as a
> dialog box is concerned. What about y'all? 
Agreed.
> Question 1b: If the consensus is to prefer seconds in the Preferences
> dialog, how much granularity do you want? (i.e. ones, tenths,
> hundredths)
I think single seconds would be enough. However, you don't have to
present them in a list. You could make it a floating point number that
converts to the appropriate number of ms, so if I want 2.5 seconds for
example I could just enter 2.5. I'd probably change the default length
of 5 seconds to perhaps 3 seconds, unless we can press a key to
interrupt flashed messages. 5 seconds is usually a bit long to wait.
> Keeping in mind that you can configure/disable this setting on a per
> script basis, and that any message I "flash" to you will disappear so
> you can resume working without having to press any keys....
However, we should be able to interrupt the flashed message with a key
if we choose to.
> Action item 2: I am planning to locate all places where we are speaking
> a message but brailling absolutely nothing and changing that. <smile>
>
> Examples:
>
> * Structural navigation where there is not a match ("No more headings
> found"). It's only spoken; I propose that same string be flashed as well
> to confirm that it tried to find something but failed to locate it. (As
> opposed to the command was broken and a bug needs to be filed.)
>
> * Keys which change settings on the fly ("bypass mode enabled").
Don't forget Openoffice help. Orca isn't brailling any of the items in
the tree view there. Sometimes the string "TREE LEVEL 1" gets brailled
but nothing more than that.
> Question 2a: What about keys which change a speech-only setting on the
> fly, e.g. to toggle the speaking of indentation and justification?
> Should we flash it in the spirit of fully equally speech and braille, or
> not display it in braille because if you toggled the speaking of
> indentation and justification, you are probably also using speech and
> were able to hear the message?
I would still flash the appropriate message, since you may have hit that
key by accident and if you were using braille only you wouldn't realize
you'd inadvertently hit the wrong key or changed a setting you didn't
intend to change.
> Note that I think toggling speech enabled/disabled should always be
> flashed because it wouldn't be redundant if something had gone wrong
> with your synthesizer.
Agreed.
> * Progressy updates. There are two such categories: Spoken messages to
> let you know an app is busy ("loading please wait", "finished loading")
> and actual progress bars. Personally, I'd flash the former
> automatically; I'd flash the latter at the same time we were speaking
> the percentage.
Agree on this one. We can always rest the flat review on a progress bar
if we want to see realtime updating.
> * Text formatting (i.e. when you press Orca+F). Orca does allow you to
> underline desired attributes in braille. But if you want to know if
> something is bold versus underlined, you currently have to ask Orca with
> Orca+F -- and currently you have to be able to hear because we only
> speak that info. There are, in my mind, two issues here: We should have
> an efficient way of marking up text and optionally showing the
> formatting in braille without your having to read through everything
> Orca+F outputs. But given that at the moment, that's not in place, I'm
> very strongly leaning towards Orca+F displaying the same thing it
> speaks.
Sounds like a good compromise until we get mark-up capabilities.
> Action Item 3: I plan to go back and review all the areas where the code
> suggests we are presenting in braille but implemented before Flash
> messages.
>
> Example: If you read the status bar or the title bar, the code would
> suggest that we're presenting that in braille. When I try it, however,
> it seems that we're continuing to show the locusOfFocus. Which makes
> sense in a certain frame of mind, but.... I've got a lot of spot
> checking to do.
Actually, these are rather erratic. Sometimes it will braille the title
bar and not speak it, other times it will speak it but not braille it.
Take Totem, GNOME's movie player. Use the title and status bar keys, and
nothing gets brailled even though the proper information is spoken. Now,
take gnome-mplayer. The title and status bar keys braille it, but they
don't speak it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvn3VYACgkQybLrVJs+Wi4PMwCeLWxizgA+DyG2xwnFb+siooeS
7JYAn2Fiez/P25AhAPOc8VMnviI5ZHVE
=8fvT
-----END PGP SIGNATURE-----