From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Thu Dec 20 2007 - 03:35:27 CST
On 12/19/2007 11:46 AM, Karl Pentzlin wrote:
> As a (new) member of DIN NA 043-01-35-01 GAK, a German group
> related to ISO/IEC JTC 1/SC 35/WG 1, I am concerned with the
> ISO/IEC 9995 standard, Keyboard layouts for text and office systems.
>
> Before I do any detailed statements in the standard group, I want to
> discuss my general ideas in the public.
> Any comments or hints are welcome.
>
> In the current version of Part 2 of the aforementioned ISO 9995 is stated:
> For the input of graphic character repertoire of collection 281
> (titled MES-1) as specified in amendment 1 to ISO/IEC 10646:1-2000,
> a Common Secondary Group Layout (to be used as group 2) is specified
> in ISO/IEC 9995-3...
> In my opinion, this character collection is [ill-]suited as base
> for a standardized keyboard layout, for the following reasons:
> ...
>
> Thus, I propose to use the more complete set of collection 282
> (MES-2) of ISO 10646, with some modifications as enumerated below.
> It is of course a somewhat complicated task to put these characters into
> a concise keyboard design, but the "Europatastatur" (European Keyboard
> as shown on http://www.europatastatur.de , in German; an English
> presentation is found on http://www.europatastatur.de/presentation1/ )
> shows that such things can be done.
>
> The collection 282 (MES-2) is:
> ...
> I propose to use a set based on collection 282, without Greek and
> Cyrillic (i.e. Latin script only), without block graphics (as their use
> is very limited nowadays), and without any legacy ballast, namely
>
>
> - Karl Pentzlin
>
>
>
Karl,
these are some interesting ideas. The problem with keyboards that
command a very large set of characters is that typists have problems
remembering the key-bindings. For people that speak a given language,
learning to type the (limited set of) additional characters for that
language is a manageable task, and the convenience of having a
particular "universal" keyboard layout available on any workstation in a
large organization (and not just on their own desk) can be a benefit.
However, when it comes to typing mathematics, it's not clear that this
is the correct approach. The number of symbols needed is too large and
their use is too varied for most users to get the necessary
reinforcement that would allow them to learn arbitrary key-bindings. For
such needs, some form of input method that translates a mnemonic string,
such as \sum into the proper symbol is likely to be a better match.
There are other schemes for quick symbol selection as well.
Moreover, mathematics cannot be typed without Greek, so your decision to
leave out Greek immediately means that whatever scheme you put into
place has little to offer to the serious user - as a result, you are
better off simplifying the design to what is needed for natural
languages (including the needs of commercial/legal documents).
(For a list of characters used for mathematics, see for example, UTR#25
at http://www.unicode.org/reports/tr25/ )
For users that need to enter names and other information in native
spelling, i.e. in languages that they are not familiar with, the problem
is that locating a key on a keyboard (even a virtual keyboard) can be
more cumbersome than using a well-designed pick-list, for example. To
address the problem of the Dutch secretary who suddenly has an Azeri
boss and needs to frequently use some special character for that one
name, a system would need to provide a combined on-screen and keyboard
oriented approach, whereby the user can locate an unfamiliar character
in a well-designed list and if the character is used frequently enough,
can easily find out and learn the keyboard shortcut for it.
A well-designed list would be set up to help users with quick access to
characters and give enough information to help avoid misidentification
among similar characters. A keyboard layout cannot do that (look no
further than the scrambled letters of Basic Latin to see what I mean).
I think this is an area where the existing designs can all be improved upon.
Hope you find some of these thoughts useful as you begin your active
contribution to the standardization process.
A./
PS: an aside on MES-1 and MES-2. The criteria by which these were
designed have always seemed less than satisfactory. But apart from that,
the real issue with these collections is that, at best, they are sets
for "systems coverage", that is, sets that a system is supposed to
support for input, processing and display - but from that it doesn't
follow that they are the proper sets to consider for _keyboard_ input at
the exclusion of other forms of input methods.
>
>
This archive was generated by hypermail 2.1.5 : Thu Dec 20 2007 - 03:38:05 CST