midibraille-development — Development discussion - coding and functionality

[Midibraille-development] Announcing markings that use a combination of two or more cells

[David G. <dr...@gm...>]

Just a point of discussion - when you have a symbol that uses a combination
of two or more cells (tie symbol for example), we want midibraille to
announce it when navigating the edit control. A few things need to be
considered here though:

When the user navigates to the next 'cell', should the cursor jump over the
2nd cell that was already announced as part of the first one, so as not to
confuse the user (i.e if the system says 'tie symbol', then dot 1-4 the user
may think the have an extra dot 1-4 in place)
When the user wants to remove the symbol, should both cells be removed when
they press backspace or just one at a time

Anything else you can think of as a point of contention regarding this?

-drgoo

Re: [Midibraille-development] One handed braille entry

[David G. <dr...@gm...>]

One other possibility, is to have the ESC key act as a backspace key as
well. For lefties, they should be able to move their wrist a bit and reach
with their little finger, for righties the backspace key - all without
having to lose their place on the keyboard. Of course when people can set
their own key bindings, they could set any key they preferred to be the
backspace key also. But we do need to decide on the factory settings.

Again as with everything we're doing, the toggle can be an option the user
can enable, if they prefer to have it that way. Its safe to say that many
people are going to have their own individual style for doing things, and it
is going to be good to cater for as many as possible.

As for the question mark button putting in dot 2-3-6 well thats a whole
different kettle of fish eh? Perhaps advanced users may want the convenience
of pressing one button to achieve common symbols - this belongs on the
roadmap for future releases I think.

On Sun, Sep 27, 2009 at 1:10 AM, Ross de Vent <ro...@de...> wrote:

>  That is genious. I was automatically going to say that pressing backspace
> is the most logical option. When you think about it though, pressing
> backspace means that you have an extra movement which restricts the user, it
> should be as seamless as possible. But if you can have each key act as a
> toggle this takes away that extra movement. The only exception would be the
> spacebar which puts an empty cell when you press it twice. Need to think
> about this a bit more, but I’ve just been experimenting with which keys are
> best for one-handed mode. I suspect that the keys you want to use will
> change depending on which hand is your strongest. First question: can we
> leave it up to the user which keys they want to use? We could have suggested
> possibilities, but ultimately it would be up to the user. I was thinking
> that we may have to restrict it to the alphabet, but seeing as this is
> braille music and the signs all change anyway from literary braille to
> braille music, for example dots 2-3-6 is question mark and staccato sign.
> Initially I was thinking that maybe we should leave these other signs as
> they are but I don’t think so.
>
>
>
> It occurs to me too, that since the beginning of braille music there has
> been slight formatting changes, for example bar over bar versus bar after
> bar for piano music. As the wickipedia article regarding braille music
> states betty crolick’s 1997 version of the braille music dictionary is the
> current one that people are supposed to stick to. However, it would be cool
> if we could include the various other formatting standards that have existed
> in the past as options.
>
>
>
> Ross.
>
>
>
> *From:* David Goodes [mailto:dr...@gm...]
> *Sent:* Sunday, 20 September 2009 11:56 PM
> *To:* mid...@li...
> *Subject:* [Midibraille-development] One handed braille entry
>
>
>
> Hi,
>
> As we had discussed, one handed entry works as follows:
> User types one or more of the predetermined keys to represent each dot,
> then presses the spacebar to signify that the cell is complete and should be
> placed.
>
> A few questions regarding this, as I have completed the braille entry (two
> handed) and want to get this one done:
>
> Pressing the spacebar twice means putting an empty cell up, yes?
> If the user presses a key by mistake, should they press 'space' and then
> 'backspace' to correct it, or will pressing the same key again work as a
> 'toggle'?
>
> For example: key 'Y' represents dot 1 on a cell. In one-handed mode, the
> user accidentally presses this key. Dot 1 will be placed if the user presses
> the space bar. Can they press 'Y' again to turn this dot 'off' again, before
> pressing space?
>
> -drgoo
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Midibraille-development mailing list
> Mid...@li...
> https://lists.sourceforge.net/lists/listinfo/midibraille-development
>
>

Re: [Midibraille-development] One handed braille entry

[Ross de V. <ro...@de...>]

That is genious. I was automatically going to say that pressing backspace is
the most logical option. When you think about it though, pressing backspace
means that you have an extra movement which restricts the user, it should be
as seamless as possible. But if you can have each key act as a toggle this
takes away that extra movement. The only exception would be the spacebar
which puts an empty cell when you press it twice. Need to think about this a
bit more, but I've just been experimenting with which keys are best for
one-handed mode. I suspect that the keys you want to use will change
depending on which hand is your strongest. First question: can we leave it
up to the user which keys they want to use? We could have suggested
possibilities, but ultimately it would be up to the user. I was thinking
that we may have to restrict it to the alphabet, but seeing as this is
braille music and the signs all change anyway from literary braille to
braille music, for example dots 2-3-6 is question mark and staccato sign.
Initially I was thinking that maybe we should leave these other signs as
they are but I don't think so.

 

It occurs to me too, that since the beginning of braille music there has
been slight formatting changes, for example bar over bar versus bar after
bar for piano music. As the wickipedia article regarding braille music
states betty crolick's 1997 version of the braille music dictionary is the
current one that people are supposed to stick to. However, it would be cool
if we could include the various other formatting standards that have existed
in the past as options.

 

Ross.

 

From: David Goodes [mailto:dr...@gm...] 
Sent: Sunday, 20 September 2009 11:56 PM
To: mid...@li...
Subject: [Midibraille-development] One handed braille entry

 

Hi,

As we had discussed, one handed entry works as follows:
User types one or more of the predetermined keys to represent each dot, then
presses the spacebar to signify that the cell is complete and should be
placed.

A few questions regarding this, as I have completed the braille entry (two
handed) and want to get this one done:

Pressing the spacebar twice means putting an empty cell up, yes?
If the user presses a key by mistake, should they press 'space' and then
'backspace' to correct it, or will pressing the same key again work as a
'toggle'?

For example: key 'Y' represents dot 1 on a cell. In one-handed mode, the
user accidentally presses this key. Dot 1 will be placed if the user presses
the space bar. Can they press 'Y' again to turn this dot 'off' again, before
pressing space?

-drgoo

[Midibraille-development] One handed braille entry

[David G. <dr...@gm...>]

Hi,

As we had discussed, one handed entry works as follows:
User types one or more of the predetermined keys to represent each dot, then
presses the spacebar to signify that the cell is complete and should be
placed.

A few questions regarding this, as I have completed the braille entry (two
handed) and want to get this one done:

Pressing the spacebar twice means putting an empty cell up, yes?
If the user presses a key by mistake, should they press 'space' and then
'backspace' to correct it, or will pressing the same key again work as a
'toggle'?

For example: key 'Y' represents dot 1 on a cell. In one-handed mode, the
user accidentally presses this key. Dot 1 will be placed if the user presses
the space bar. Can they press 'Y' again to turn this dot 'off' again, before
pressing space?

-drgoo

Re: [Midibraille-development] Conflicts between midibraille's own synthesis of speech and JAWS or NVDA

[David G. <dr...@gm...>]

I have placed a support request with freedom scientific, and sent an email
to the developers of NVDA. We'll see what they suggest, but the function to
mute the jaws voice sounds like a good option.

-drgoo

On Sat, Sep 5, 2009 at 3:58 PM, Ross de Vent <ro...@de...> wrote:

>  Yes could work I suppose but not preferable. Magic is the other program
> which freedomscientific produce for vision impaired people. Windoweyes is
> the other major screen reading software. I don’t know much about windoweyes
> or magic . Self voicing is a good idea. Look at: www.gamesfortheblind.com
>
> As it mentions on the website these games use the Eloquence speech
> synthasizer. I do not know who owns Eloquence. As this developer seems to be
> self-employed maybe we could make contact with him to ask what he does and
> how he gets around it. I have some of these games on my computer although I
> haven’t bought them. I was incorrect in thinking that the game takes over as
> the major screen reader. Instead there was two voices, the one from the game
> and the other which was the jaws voice. Both were reading the menu item for
> the game menu at the same time. I do know that there is a function built
> into jaws which mutes the jaws voice but still has it running. I’m presume
> windoweyes, nvda and magic all have the same function. Maybe that could be
> an option.
>
>
>
> *Ross.*
>
> *From:* David Goodes [mailto:dr...@gm...]
> *Sent:* Saturday, 5 September 2009 2:59 PM
> *To:* mid...@li...
> *Subject:* Re: [Midibraille-development] Conflicts between midibraille's
> own synthesis of speech and JAWS or NVDA
>
>
>
> one thought I just had is to see if we can set the nvda/jaws software
> volume to 0 for the duration +5seconds (for any delay in synthesis) of the
> item we wish to speak, and then setting it back. This isn't the best
> solution but may be a workaround in the meantime.
>
> -drgoo
>

Re: [Midibraille-development] Conflicts between midibraille's own synthesis of speech and JAWS or NVDA

[David G. <dr...@gm...>]

one thought I just had is to see if we can set the nvda/jaws software volume
to 0 for the duration +5seconds (for any delay in synthesis) of the item we
wish to speak, and then setting it back. This isn't the best solution but
may be a workaround in the meantime.

-drgoo

[Midibraille-development] Conflicts between midibraille's own synthesis of speech and JAWS or NVDA

[David G. <dr...@gm...>]

I have discovered a way to have midibraille generate its own speech output,
using the already created and open source eSpeak code. This gives us greater
flexibility and makes it less dependant on commercial software (such as
JAWS).

The only thing I am unsure about however, is how this will conflict when a
user has their own screen reading software installed on their system. I see
us implementing this in a few ways, and was keen to have your thoughts:

1) Complete speech generation for the software program (all key presses and
screen reading)
-This will require a greater level of programming, and will require the user
to disable their own screen reading software while using the program (unless
we can discover a way of telling JAWS/NVDA not to read anything from this
program while it is running). I will enquire with NVDA/JAWS as to whether
that is possible.
-Program will be less dependant on commercial software.

2) Speech generation for specific components JAWS/NVDA will not interpret
accurately (braille music etc).
-Less implementation of screen reading and key trapping for reading menu's
and other items.
-Research on JAWS scripting and other software's methods for specific and
directed interpretation.

Of course the ultimate option is to implement both, so the user can use the
method that works best for them. I suppose just wondering which direction
you thought it might be best to go down initially.

-drgoo