orientations and IMWA

[Sandy Fleming]

Charles,

As I said, this prototype program is 2 or 3 years old now and I've no
intention of developing it further. Rather, I'd start from scratch using
the lessons learned (one of which was, don't write in Perl!).

This makes sense because I don't just want to write a SW editor and
leave it at that: I want to make sure that the core engine of the editor
can easily be used in other programs to encourage other programmers to
write different kinds of SignWriting software without having to
re-program the wheel  :)

So it's important to start again, I think, to ensure that the program
structure will be suitable for plugging in to other types of programs.

As I also said, I've simplified the keyboard so that (if I'm right) it's
not really going to be that much harder to learn than an ordinary
alphabetic keyboard.

Instead of a 26 or 36 letter keyboard, I plan a hybrid of the two based
on the observation that in sign languages (unless it's just BSL!)
handshapes representing numbers are often _only_ used for numbers (even
though these are incorporated into signs in various ways), and that
numbers handshapes often vary between dialects.

So what I have in mind now is a keyboard where, as far as typing
handshapes goes, number handshapes are typed by typing the digit
keypresses: 1234567890, and other handshapes in the language are typed
by pressing the letter keys: abcdefgh...

This won't actually give us enough handshapes to represent a complete
sign language. In the original keyboard I solved this by allowing up to
two keypresses to type one handshape. For example, you might type the
"L" handshape with the "l" keypress, and then add the thumb by pressing
the "t", if you wanted a thumb. But I now realise that this would be
difficult to learn.

So instead, I've thought about what people find acceptable in typing on
an alphabetic keyboard and I think that one thing that can be used to
extend the keyboard easily is to type double letters. So instead of
typing the L hand with thumb as say "lt", we should just type it as
"ll".

Thus every handshape can be done either using a number key, a single
letter keypress or a double letter keypress. This would give us up to 62
handshapes for any given language. This seems to me adequate for BSL.
Our big dictionary specifies something like 87 handshapes but on the
other hand Mary Brennan's book "Words in Hand" specifies far fewer (but
she seems to have missed some). I think the truth lies somewhere in
between, where this sort of keyboard design will be able to cope. And if
not, there are a few more tricks we can resort to!

As you can see, I'm only interested in offering one language at a time.
I don't think it's feasible to have a straightforward typing system for
the whole ISWA: that would be like insisting on having a keyboard for
the whole International Phonetic Alphabet instead of just one for the
language currently being typed, though of course languages can be
switched, or extended keyboard functions can be used, analogous to those
things as we have them now for alphabetic keyboards.

I wouldn't worry about the fact that I'm programming up in BSL (because
it's what I know), and you want ASL. Setting up an ASL (or any other
language) keyboard will just be a matter of supplying the necessary data
about which SSS symbol you want attached to which keys and suchlike. Of
course we could hope that, like most languages that use the same
alphabet, these would have a lot in common and at least some of the more
fundamental symbols would be placed in the same way from keyboard to
keyboard. It would be important not to fall for the mistake of using
oral-language letter cues for the handshapes associated with a keypress
(although perhaps basing it on the French-style fingerspelling would
make sense to a lot of people).

I say all this just to make it clear that the prototype program is too
complicated compared to what I now see we could have, and you shouldn't
try to actually learn these keyboards or anything.

Above all, remember that things like this are written into programs in
the form of tables and that nothing needs to be written in stone: we can
experiment a lot by changing tabular data.

You may wonder how I would fit all the movement, contact, head, shoulder
and hip symbols onto the keyboard as well. The answer is that the
program always knows in which "channel" the cursor is currently placed,
and it takes keypresses to mean whatever they represent in that channel.
For example "o" might mean the circle hand when the cursor is placed to
type a hand, but bug eyes when the cursor is placed to type something in
the head. Actions (this is what I call movements, contacts and dynamics
collectively) don't fit into this scheme which is why I've reserved
capital letters (ie the shift key) for typing them!

You're right, the light blue mannikin is something the user should be
able to switch on and off at the screen: it's just an aid, which perhaps
advanced typists would rather do without. It would never be printed to
paper, even if it was shown at the screen. It would also possibly be
useful to have a grid of light blue squares that the user could switch
on if he felt he needed a positioning guide.

Val was saying that few signs actually use the full body anyway. This is
OK because the mannikin is only used to help with typing the current
sign. The program in its full form would keep track of the "extent" of
the sign (ie the space it takes up on the page), and when the sign was
completely typed and entered, it would be moved up to make the spacing
between signs even. As with any editor or word processor, the software
would manage the layout and keep it consistent.

Yes, having the centre of rotation at the wrist is a must for
handshapes, anything else would be confusing for the typist. In the
prototype program I had the wrist point centre of rotation at the edge
of the wrist, but I now think that it should be at the middle of the
wrist line, both logically and for easier programming.

Well, I went on a bit there!

Sandy