Comment 1 by jteh on 2013-01-26 23:19
One issue that hasn't been covered is whether there are many displays that only have a 6 dot Braille keyboard and whether this presents a challenge for global bindings. The only display I know of that has a 6 dot keyboard is the old Braille Light (which we don't actually support at present).

Comment 2 by ragb (in reply to comment 1) on 2013-01-26 23:28
Replying to jteh:

One issue that hasn't been covered is whether there are many displays that only have a 6 dot Braille keyboard and whether this presents a challenge for global bindings. The only display I know of that has a 6 dot keyboard is the old Braille Light (which we don't actually support at present).

As far as I recall, the only bindings we have with dot7 or dot8 are for emulating enter and backspace keys (in some of the drivers). Does the braillelite have something representing enter or backspace keys? (some displays have enter, esc, and arrow keys, at least).

Comment 3 by nvdakor on 2013-01-27 01:34
Hi,
There are chord commands which are equivalent to dots 7 and 8 on Braille Lite. These are:

• dot 7: B chord
• Dot 8: dots 46 chord or e chord.
  This affects braille Lite 18/2000. Other Braille Lite models have 8 dot keyboard.
  Also, I think we should not bind other key combos with dots 7/8 (with or without spacebar) to reserve them for eight dot braille entry.
  The other issue might be that since some display drivers comes from manufacturers, there might be same commands (same as global ones) that this particular display might use (HIMS drivers are a good example). To solve it, I propose coming up with a database of globally bound script gestures (for braille).
  Also, should we block 808/2439 to this ticket?

Comment 4 by nvdakor on 2013-01-27 01:36
At some point, let us send out a list of possible global gestures so people can comment on them. I'd also be happy to attach known global commands to this ticket as a reference.

Comment 5 by halim on 2013-01-28 14:30
My questions: would these global bindings be customizable?
In other words: can I add more or different bindings (overwrite global ones) if needed in the driver as well?
You are describing only space+dot bindings, afaik some displays have more keys like"left thumb" "right thumb " etc?
What would be the best place to implement / handle these keys?

Comment 6 by aliminator on 2013-01-28 14:56
There seems to be several issues when implementing global key bindings.
However, one of the most important points was not covered which is the user's v view. Maybe this should be discussed in the other mailing list just to get some ideas from their point of view. It should be known whether users using braille input prefer the manufacturer's manualr or screen reader documentation.
If many requests encourage global bindings it should be implemented but overriding should be possible.

Comment 7 by ragb (in reply to comment 5) on 2013-01-28 16:51
Replying to halim:

My questions: would these global bindings be customizable?

Yes. Driver bindings take always precedence. Global ones will only be tried when some dots gesture is not bound in the driver.

In other words: can I add more or different bindings (overwrite global ones) if needed in the driver as well?

Yes.

You are describing only space+dot bindings, afaik some displays have more keys like"left thumb" "right thumb " etc?

What would be the best place to implement / handle these keys?

My suggestion is only related with space+dots bindings, since those are common in various displays, with a known meaning. Ense the idea of making them global.

Braille display specific keys must be bound on the driver, since each displays has its own specific keys, with specific meannings.

Comment 8 by jteh (in reply to comment 3) on 2013-01-29 02:34
Replying to nvdakor:

• dot 7: B chord
• Dot 8: dots 46 chord or e chord.

I think it would be fair to have these bindings globally as well as the dot7/8 ones.

Also, I think we should not bind other key combos with dots 7/8 (with or without spacebar) to reserve them for eight dot braille entry.

Bindings with dot 7/8 are fairly awkward anyway. That said, I don't think we should avoid these because of bugs in specific displays. Those displays can always do display specific bindings.

The other issue might be that since some display drivers comes from manufacturers, there might be same commands (same as global ones) that this particular display might use (HIMS drivers are a good example). To solve it, I propose coming up with a database of globally bound script gestures (for braille).

Imo, this is too complicated. I think we should just come up with global bindings that make sense. If a given display can't use these, the display driver can override those bindings.

Also, should we block 808/2439 to this ticket?

No. While related, those tickets do not depend on this one.

Comment 9 by jteh (in reply to comment 6) on 2013-01-29 02:40
Replying to aliminator:

It should be known whether users using braille input prefer the manufacturer's manualr or screen reader documentation.

The Braille display manuals I've read that include bindings usually do so for specific screen readers, rather than "general" bindings. I haven't seen a display which documents general bindings without mentioning a screen reader name. Is this different for Papenmeier or other displays? How do they account for differences in screen reader concepts?

If many requests encourage global bindings it should be implemented but overriding should be possible.

Overriding is already possible and this won't change. The only question is what we should recommend as a general rule.

Comment 10 by halim (in reply to comment 9) on 2013-01-29 06:31
Replying to jteh:

The Braille display manuals I've read that include bindings usually do so for specific screen readers, rather than "general" bindings. I haven't seen a display which documents general bindings without mentioning a screen reader name. Is this different for Papenmeier or other displays? How do they account for differences in screen reader concepts?

Well braillex Trio is such an example :-).
The display installs a keyboard driver in windows which does not depend on a specific screenreader.
http://www.papenmeier.de/tl_files/en/pdf/eng/Manual%20BRAILLEX%20Trio.pdf

Comment 11 by halim on 2013-02-04 07:50
Currently I am adding braille input support in papenmeier driver. It would be helpfull to define which global bindings we want to add to nvda. So I would suggest following (minimal) bindings:

• dot7 = backspace
• dot8 = enter
• space+dot7 = escape

Feel free to add more here!!!

Comment 12 by ragb (in reply to comment 11) on 2013-02-04 13:08
Replying to halim:

• dot7 = backspace
• dot8 = enter
• space+dot7 = escape

I'd sugest you don't map space+dot7 to escape. Some drivers don't support dot7 alone (i.g. braillenote) and we have to map space+dot7 for this. More important, I believe it is very similar to dot7 alone (bound to backspace) and may arise some confusion.
For escape I'd say space+dot1+dot2 (space+b of back), or space+dot1+dot5 (space+e), however some notetakers use that binding, and some other devices use that for enter. See the focus bidings, I believe they are very standard-wise, and many can be applied right away without conflicts (at least those to enter arrows and so on).

Comment 13 by nvdakor on 2013-03-05 00:21
Hi,
After talking with users on various forums, I gathered the following comments:

• Extra keys: Some users expressed concern about doing the same thing using more than one command via extra keys. This is the case with a number of braille displays which has function keys in addition to braille keyboard (BrailleNote, Braille Edge, Focus, etc.).
• Reading current char/word/line: I'm sure read current line is there, but some users asked that we consider adding read current char and read current word to be bound to braille keys.
• Different gestures for different displays: Some were worried that custom gestures for their braille displays would be lost. I told them that the devs are trying to come up with universal braille key bindings across supported displays, and that there is already facility to override the default ones.
• Ability to reassign braille commands: In keeping with keyboard gesture manager idea (improving keyboard layout managing #64 and other ticket), some users suggested including braille bindings as part of the gestures manager idea.
  As for continuing this discussion, should we ask braille display driver writers and other power users (such as us) to gather their opinions?
  Thanks.
  //JL

Comment 14 by jteh on 2015-07-24 00:09
@dkager, would appreciate your thoughts here if you have time.

Comment 15 by dkager on 2015-07-24 10:27
First and foremost, I have never used braille notetakers so I can't comment on possible conflicts or existing conventions for those products. I should probably also say that because my previous braille displays had dedicated keys for most commands I havne't used chords very extensively until recently.

I agree with a lot of what has already been said. In particular:

• Backwards compatibility. It's impossible to come up with a set of bindings that won't conflict with or break some existing driver's bindings.
• Consistency. I would prefer consistent bindings across multiple displays, but that is personal opinion of course.
• Backspace/Enter. Dot 7 (Backspace) and dot 8 (Enter) sound like intuitive bindings that match other screen readers. It's also what a Perkins brailler would have, except dots 7 and 8 are reversed.
• Documentation. Manufacturers will have to update their docs to avoid confusion. But this is also true if the community decides to update a driver with more/new bindings.

Another topic is redundancy. This too can't be avoided. For example, the Alva BC6 series from Optelec comes in versions with and without braille input module. Users can also remove them ad-hoc. The HumanWare Brailliant displays also have braille input as an option if I remember correctly. In both cases there are alternatives:

• The Alva BC6 has dedicated function keys: arrows, Enter, Tab, Escape, Windows,etc. I believe Optelec took all of these out of their new 'Comfort' products, but the traditional models don't require chords to do all this stuff.
• The Brailliant has six command keys conveniently arranged as a 6-dot braille cell. These can do much the same as chords, e.g. C1 + C3 + C4 + C5 for the NVDA menu.

So there will be multiple key combinations to do the same thing on these displays. I think this is desirable because if we provide only chorded commands we exclude people that chose the model without braille input.

I would rely mostly on 6-dot chords, though. Two reasons:

1. Typing 8-dot chords can be awkward. It's not something you learn on a Perkins brailler and so for me it requires some effort to get them right.
2. Not all displays may have eight keys.

Another observation is that 'b for back' does not necessarily make sense for non-English languages. This isn't something I would consider in choosing bindings, but maybe others would.

Long story short: I use multiple displays, albeit not all with braille input, and would find it very convenient to have the same chords on all of them. But I think we do need to discuss this on the user's list and incubate it for a nice long time.

Comment 16 by dkager (in reply to comment 15) on 2015-08-03 14:30
Replying to dkager:

• Backspace/Enter. Dot 7 (Backspace) and dot 8 (Enter) sound like intuitive bindings that match other screen readers. It's also what a Perkins brailler would have, except dots 7 and 8 are reversed.

In hindsight: I would prefer Backspace/Enter to only be bound to Space+Dot7 and Space+Dot8, not the individual dots. This appears to be how iOS does it, and it is useful because it allows you to type dot 7 and 8. These may be defined by some tables. And adding the spacebar shouldn't be a big deal, ergonomically speaking.

What are the current thoughts about this issue? I wasn't involved in the discussion before, but I think that global key bindings would be an interesting approach. I find them very handy in iOS, for example.

cc @dkager, @bramd, @ragb,

The main challenge here is the fact that some braille displays already bind space+dots combinations. Those would conflict. However, the display bindings would take precedence, so I guess users of such displays don't lose anything and drivers could be updated if users end up preferring NVDA's global commands.

At this point, my feeling is that I'm fine for this to be implemented, pending suggestion of reasonable bindings. @LeonarddeR, do you want to take a stab at coming up with an initial list?

@FelixGruetzmacher: Could you also give your opinion on this subject? I know Handy Tech has quite a lot of these key bindings by default and tries to keep them equal for all screen readers. These bindings might be a good starting point to come up with some decent defaults.