No subject
Thu Dec 25 21:32:58 EST 2014
in the access time to the information.
>
>> Overall I miss the great picture on what is going on. There is no meta
>> document that discribes the difference between cursor and reading focus
>> movement and
>> this crucial difference is also not reflected in the terminology of the
>> config files.
> But it's implicitly understood by blind users.
Mh. My brother may not have this inbuild implicit insight you attest all
blind users. :-)
Without my help he had never mastered the focus 14 brltty keybindings.
He is very intelligent - has an absolute memory -- he never forget
anything - and learns at a speed of light.
But without knowing the names of the buttons all the documentation of
the keybindings is useless.
It was not possible even for his genius to fiddle it out by try and fail.
>> You may find a graphical documentation of the BRLTTY Key-Bindings to the
>> physical keys on the FS Focus 14 here:
>>
>> https://inqbus-hosting.de/volker/focus_14_doku.odg/at_download/file
> Including this sort of thing for just one model wouldn't, in and of itself, be
> all that useful. It might be extremely useful, however, were we to have such a
> picture for each and every model (or, for at least most of them). I'm
> wondering, therefore, if you might have the time to put together just such a
> collection.
I would be honored to craft this graphical documentation for the community.
Since I do not have physical access to all the many braille device
brltty support, I will need some help from the community.
Here is my plan:
1) I will get me an overview of the different devices and their key
naming schemes.
2) These I will compare with the brltty keynames in the documentation
and look for differences.
3) The differences I then will publish for the community to give me
hints to correct or complete.
4) I will produce documentation of the devices and name all the buttons,
levers, rockers according to the brltty notation. I will produce these
graphics
in a way that visual impaired people like my mother (10% sight) can
read it at their reading device easily.
5) A judge will review the documentation and will report to the community.
6) The reviewed documentation will then be published
For all this we need
* a judge
* a medium for collaboration. What medium do blind use to work
effectively together on a single document?
We non blind use etherpad for this task but this is using javascript
and does not works with console browsers like links2.
What do you recommend?
>
> It also highlights an interesting "problem". I myself - and, in fact, most of
> us - am unable to even check it out in order to aprove it for web site
> inclusion. You see, most of us (myself included) are fully blind.
Recently I have asked Klaus/Adriane Knopper for assistance. I think they
may be a good judge for the quality of my work.
>
>> Tell me how to contribute more ..
> We'd welcome whatever you may be able to contribute. As mentioned above,
> perhaps you could put together a collection of braille device pictures for us
> that would assist sighted users.
>
> On the issue of key layouts: Some of our key tables already do contain verbal
> descriptions of them. Check out the *.ktb and *.kti files within the
> Tables/Input/*/ subdirectories of the source tree for lines which begin with
> the keyword "note". After installation, these files end up in the /etc/brltty/
> directory. Since verbal descriptions are useful to both blind and sighted
> users, completing these descriptions is something that definitely must be done.
>
I have checked them out. One Idea my wife has was to give every key
binding some optional tags.
Together with sorting and tagging the list of keybindings can be
structured easily and very personally.
Best Regards
Dr Volker Jaenisch
--
======================================================
inqbus it-consulting Dr. Volker Jaenisch
Richard-Strauß-Str. 1 +49(08861) 690 474 0
86956 Schongau-West http://www.inqbus.de
======================================================
--------------090708080800050601060209
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Community!<br>
<br>
<div class="moz-cite-prefix">On 26.12.2014 05:40, Dave Mielke wrote:<br>
</div>
<blockquote cite="mid:20141226044019.GA28762 at beta.private.mielke.cc"
type="cite">
<pre wrap="">The other side of this issue, though, is that adding
that kind of extra verbage all over the place would be nothing but confusing
clutter to a blind user who already understands the context. </pre>
</blockquote>
Why can the blind people be confused by some structured information
they cannot read at all?<br>
As I stated in the subject the information base I like to bring up
is for the non blind AND the <br>
visual impaired people AND the people that may assist the former
noticed people BUT NOT the blind.<br>
<blockquote cite="mid:20141226044019.GA28762 at beta.private.mielke.cc"
type="cite">
<pre wrap="">So, in the end,
especially in this area, the blind dudes tend to win out. </pre>
</blockquote>
Yep. The - I call them - priviledged - blind dudes. Yeah they win.<br>
But there are others - not so priviledged - blind and visual
impaired people out there. Maybe lots of.<br>
And you never ever may hear of them since they are not capable to
even use brltty to communicate with you.<br>
My Brother for instance. And he comes from a rich and educated
country born as a son of a professor.<br>
He is lost. Not because of his capabilities. He has perfect memory -
he knows exactly what happened at 12.14.1980 and he learns as
quickly as hell.<br>
Why he is lost has lots of reasons that are not brltty allone. But
brltty can help him - because it is all he has. <br>
He has no jaws, no windows, only brltty. And he is stuck. -- and who
is helping him?<br>
<br>
Me. And I am not blind. And I have to come clear with brltty. And
out there is legion of People not even understanding brltty. But
they never communicate <br>
with you becouse the are not able to communicate with you at all. <br>
I think our mission is to reach as most people we can - or? <br>
<blockquote type="cite">
<pre wrap="">Now, perhaps, you
have an additional bit of empathy for how blind users feel when they encounter
all those graphically oriented web sites which are almost impossible for them
to use.
As an aside: You bear the title Doctor, so, just perhaps, you've written a book
or two. If not, you surely have colleagues who have. Have you ensured that
those books have adequate and easy-to-understadn wording associated with each
picture so that a blind reader can make sense of it?</pre>
</blockquote>
Rougly you state: "The non blind people do things that we blind
cannot read so why should we blind people produce <br>
things for the non blind?" Sorry, but this argumentation sounds a
bit revanchist to me.<br>
Should we hearing people stop producing music since there are some
deaf people on earth? Should deaf people no longer produce sounds
for us hearing people?<br>
I am sure you find out that your argument is ridiculous.<br>
<blockquote type="cite">
<pre wrap="">I dig into the config of brltty and it all is clear and straight - if
someone knows where the keys "LeftGdf" or "LeftWheelUp"
are located on the physical device.
</pre>
<blockquote
cite="mid:20141226044019.GA28762 at beta.private.mielke.cc"
type="cite">
<pre wrap="">LeftWheelUp should be easy enough to understand. There's a vertically oriented
wheel at the left end of the top of the device. LeftWheelUp means rolling that
wheel in the upward direction, i.e. toward the back of the device. I don't
recall this ever having been a point of confusion in the past.</pre>
</blockquote>
</blockquote>
<b>There is no wheel at this device at all</b>. There are two
rockers (Up/down) together with a pushbutton (Press) left and right
at the top that have take over the function of the former wheel of
older versions.<br>
<blockquote cite="mid:20141226044019.GA28762 at beta.private.mielke.cc"
type="cite">
<pre wrap="">
LeftGDF is a different matter. Yes, it'd be hard to guess which key this one
is. I expect, though, that the documentation for the actual device does explain
it. For the most part, we name the keys the same way the manufacturers have.</pre>
</blockquote>
It is completely ok to have a code internal naming convention which
do not accurately reflect changes in the design of the external
world - as long as the user documentation is according to the
user/producer naming of the buttons on the device. In case of the
Focus 14 blue this is not true. The user documentation is
misleading.
<blockquote cite="mid:20141226044019.GA28762 at beta.private.mielke.cc"
type="cite">
<blockquote type="cite">
<pre wrap="">Also the documentation of the individual key bindings descriptions are
misleading:
go up one line: LeftWheelUp
If I read "go up one line" I imagine the cursor to go up. But in this
case only the reading focus goes up one line but not the cursor.
</pre>
</blockquote>
<pre wrap="">
Yes, that'd be a sighted person's perspective, but it's not a blind person's
perspective. Since these descriptions are meant for quick reference by a blind
person, it's their perspective which must be targeted.
You, as a sighted person, see the whole screen, so, in a single glance, you
kind of know everything it says, where everything is, etc. So, where the cursor
is, which area has special highlighting, etc, is the most important thing you
want to be told about, so it's those areas that you tend to think about when
movement is discussed.</pre>
</blockquote>
The different perception of the world does not change the need for a
clear terminology, <br>
well structured documentation and fast access to the things one
search. <br>
If you do not agree on this fact we should end our discussion.<br>
<br>
To the terminology:<br>
<pre>You write:
go left one window
and :
go to end of line
The first operation moves the window one instance to the left.
The later moves the window to the end of the line, but no "window" is mentioned. Why not mention the "window"at the later?
To the structure and the access:
The list of operations is not structured nor even sorted.
Even the same operations that are represented by more than one key-code have definition listed 50 lines appart. E.g.
go up one line: LeftWheelUp
...
50 lines
...
go up one line: RightRockerUp
A simple sort operation before putting out this lines would improve the readability a lot.
And I am pretty sure that also the blind people will be happy about this.
Additional I would like to see some structure:
* Cursor Movement
* Window Movement
* Searching
* Setting Attributes
etc.
More information about the BRLTTY
mailing list