Re: presentations

[Bill Haneman <Bill Haneman Sun COM>]

On Wed, 2003-10-29 at 13:28, Guylhem Aznar wrote:
> On Fri, 17 Oct 2003 18:21:07 +0100
> Bill Haneman <Bill Haneman Sun COM> wrote:
> > I would think that Dasher might be a nice interface for this, as Matthew
> > suggests.  It isn't very keyboard-like, however. 
> 
> Dasher is a possibility. But you need stats, and current text in signwriting are
> all but standards. Some use .gif pics of the symbols and put them in a html
> file, other do xml based entries, etc. It should be possible to get some texts
> and analyse them but it would be very complicated.

OK, that's an obstacle all right.  
(see below)
> I think
> 
> > Also, GOK (gnome onscreen keyboard) might make a nice platform for this,
> > and I believe it might be relatively easy to integrate signwriting
> > support into GOK.  GOK can support multiple shift-levels, etc. on its
> > virtual compose keyboards, and also can now support keys with images (as
> > opposed to text-only) on their virtual "key caps".
> 
> I'm exploring the keyboard option, but this is very complex : I'd have to try to
> fit more than 7 symbols on each of the 60 keys (F1->F12, numbers, letters, ...)
> It would be very difficult to learn and use (ctrl-alt-shift-whatever...)

There's no reason to use 60 keys, GOK keyboards can have from one to
<infinity> keys.

> Another possibility would be using group keys switching between each family of
> symbols, ie the keys meaning would change once such a switch is toggled, but
> that would leave the complexity of the keyboard layout. 7 tiny symbols printed
> on each key with 7 switching key to use each symbol would still sound very
> complex.

Well, I would propose that this be implemented via branching keyboards;
meaning that multiple symbols would NOT appear on each key.  (see below
for some more explanation of what I mean by 'branching keyboards'.)
 
> > GOK includes a 'keyboard editor' for creating new keyboards, though it
> > doesn't include a UI for adding images yet.  That would be a nice
> > enhancement, since the image feature is supported by GOK already, just
> > not by the keyboard editor.
> 
> I'm likely to support iso 9995-7 (symbols for function keys : shift become a
> arrows, ctrl a wheel ...) so that will be fixed if I implement a keyboard.

I presume you are referring to the fact that you want to remove
dependencies on literacy in alphabetic text from the keyboard.  But I
think the right place to do this is generally in GOK (i.e. allow ISO
995-7 for all 'compose' keyboards), not in a specific keyboard; it's
worth doing for everybody.  But in a way, this issue is tangential to
you problem... I hope you understand why after reading the paragraph
below.

These GOK 'keyboards' are not like physical keyboards.  You seem to be
thinking in terms of physical keyboards, i.e. a replacement for keycaps
or a special keymap.  What I had in mind was much more general; GOK
keyboards are not, in general mappings of physical keyboards and they
need not be connected to the physical keyboard.    In fact most of GOK's
"keyboards" are really command-lists.  In other words, if you look at
the XML files which define most of GOK's keyboards, you will see that
"keys" may either branch to other keyboards, carry out special actions
or commands, exec something, or synthesize one or more piece of
"keyboard input" (i.e. synthetic keystrokes).   Presumably you want to
eventually generate synthetic keystrokes, but you don't need to do that
at every stage in the selection process, only once the user has
indicated what s/he wishes to "say" or do.  Thus, if you can indeed
break the signs down into groupings, the first entry point in the sign
"compose" keyboard branches to one of several group keyboards, etc.
until the user selects what is in effect a "leaf" which does something
useful such as synthesize a string corresponding to the selected sign,
or uses some other means of transmitting the user's selection (for
instance you could create GOK keys that spoke the selected word instead
of "spelling" it and synthesizing the appropriate keystrokes).

To take a non-signing example of branching keyboards and how they could
be used in text composition, we could (for instance) easily define a
branching text keyboard which contained selections "alpha", "numpad",
"arrows", "functions", and each of these 'keys' could branch to a
virtual keyboard containing a subset of the possible individual
key-codes.  Further, one could build a simple alphanumeric keyboard
which contained not only "leaf" keys for a-z and 0-9, ( and common keys
such as Spacebar, BackSpace, Enter), but branch keys for the numberpad
and function keys.  In other words keyboards can contain a mixture of
branching and 'action' keys of various types.  Also, keys can be
associated with synthesis of strings rather than single characters, and
there is a word-completion/prediction mechanism built into GOK which
could be extended for your needs, which means that common choices could
appear on "prediction" keys on the top of the various branching
keyboards.

Although modifiers could be used to advantage, it might be best to limit
their use, to keep the confusion and amount of information that the user
needed to remember under control.

- Bill
 
> Guylhem
> 
> -- 
> * externe net ![guylhem oeil qc ca->@metalab.unc.edu->@ibiblio.org->@7un.org]
> http://externe.net/geekcode http://externe.net/photos http://externe.net/zaurus
> GPG: 92EnB37C1 DD11C9C9 20519D01 E8FA1B11 42975AF7     http://externe.net/pubkey