[BRLTTY] Braille Display Barrier (was: Re: Braille keyboard layout)

[Boris]

Hello Sébastien, hello the list,

Thanks for starting such a thread.

Papenmeier's Easy Bar is the most efficient navigation mechanism I
have ever used on a Braille display.  With the thumbs, one pushes the
bar in a vertical plane while the indexes keep on reading.  It was
hard to do without it, when I moved to BAUM SuperVario 40 (however my
bag did feel better since the latter was four times smaller at least).

On SuperVario 40, next window key (pseudo-Braille point 5) is very
close to the end of the display.  I press it with the middle finger or
with the ring finger, while my index is finishing reading.  When I
press the key, I extend my hand to start going back to the left side,
where my left hand already is.

In some cases, reversing the navigation keys may give better
efficiency, indeed.  But navigating permanently with reversed commands
rises usability issues.

Few months ago, while reading tons of electronic papers, I wondered
how I could increase my reading speed on a Braille display.  You are
right, the left hand should be busier, but not only to press a key.
By analyzing the gesture of an expert Braille reader, I distinguish
three phases:

  - The left index follows the right index on the line;
  - The left index stops following the right index and goes to the
    beginning of the next line, back to the left side;
  - The left index starts reading the next line, while the right index
    is finishing reading the line.

To support such a gesture on a Braille display, I split my proposal in
two parts: a new BRLTTY key, and its binding on the Braille display.

The new BRLTTY key is simple: it displays the left part of the next
window.  The size of this part has to be defined (a fixed value?  a
function of the size of full windows or of the elapsed time between
two full windows?  a custom value?  both?).

To maximize the benefit of my approach, the binding of the new BRLTTY
key on the Braille display has to be chosen carefully.  This key has
to be pressed by the left hand while the right hand is on the right
side.  Either a key on the left side of the display can be rebound
permanently, or a new mode has to be defined.  In such a mode, the key
to display the previous window would be rebound temporarily.  This
mode would be automatically activated when the key that displays the
next window is called a certain amount of times, consecutively (three
times?  more?), and automatically bound back to the key that displays
the previous window when it is called a certain amount of times,
consecutively (two times?  more?) or after a time-out.

I am pretty sure this approach will significantly increase the reading
speed on Braille displays, at least for expert Braille readers.  As
far as I know, it has not been neither described, nor implemented
anywhere.  I would be pleased to see BRLTTY being the first Braille
display software to jump the Braille Display Barrier!

Any comments are welcome,

Sébastien Hinderer <Sebastien.Hinderer at ens-lyon.org> writes:

> Dear all,
>
> While reading the screen, at least in text mode, the command I use the
> more frequently is doubtlessly the one that displays the next indow on
> the braille display. Assuming that the same should be true for others, I
> am lead to this idea that if there is one thing that must be payed
> attention to when designing a braille keyboard, it is the position of
> the key intended to be bound to this command.
>
> So far, I could work with two braille terminals. The first one had its
> "go to next window key" at the left of the display, where as the second
> one has it at the right end, more precisely under the last cells.
> Between these two, my personal preference goes to the first one. Trying
> to rationalize this, I came to the following explanation:
> when I read braille on paper, my indexes both read, say, the first half
> or one line. Then, the right one reads the second part of the line on
> its own, while the left one locates the beginning of the next line, thus
> helping the rihgt index to join this point of the page to continue
> reading. The first terminal, I felt, was well adapted to this process.
> Indeed, my fingers could work pretty much the same way on the terminal
> and on the paper, the only difference being that the left index had to
> locate the "goto next window" button instead of the beginning of the
> next printed line.
> With a "go to next window" button at the end of the display, though,
> things look different to me: my right index has to both read the end of
> the window on its own and to press the button, while theleft index
> uselessly waits at the beginning of the window.
>
> To sum up: I believe that if the "go to next window" button is located at
> the end (right) of the braille window, I am less efficient in reading
> than when it is placed at the left (beginning) of the braille window.
> The explanation, according to me, is that the latter disposition allows
> a more balanced used of the indexes, whereas the former one leads to the
> left index being underused. Or perhaps it is a matter of being able to
> do things simultaneously or not:  with the key at the left, the wto
> fingers can do things in parallel (the right one reads while the left
> one goes back to the key), whereas with the key at the right, reading
> and finding the key have to be done sequencially.
>
> What do you huys think about all this ?
> Where doyou prefer to have your "go to next" key ?
> Are there alternative systems (like Papenmeier's easy access bar) you
> find adapted ?
>
> Thanks a lot for your opinions.
>
> Sébastien.
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty
>

-- 
Boris Daix