Re: Latin-script keyboard layout (was RE: Quick Question About Korean Input Methods)

From: Ed Trager (ed.trager@gmail.com)
Date: Thu Jan 07 2010 - 20:26:48 CST

  • Next message: Doug Ewell: "Re: Latin-script keyboard layout (was RE: Quick Question About Korean Input Methods)"

    Hi, everyone,

    >> But that doesn't take into consideration that this program doesn't
    >> directly work with keyboard output but with what's being typed through
    >> the layout. If you can reach ^ really fast while typing regular text on
    >> AZERTY, that's just dandy. I know that the German QWERTZ keyboard layout
    >> has the ^ key located on the top left - right under Esc, so it can't be
    >> reached as easily as > while typing. The >, which is next to shift on
    >> German QWERTZ, can be reached more quickly in my opinion, so it's good
    >> to have a n-to-1 mapping since different keyboard layouts have the keys
    >> on a different position and are therefore harder or easier to type (on
    >> top of the user not being used to type these sequences most of the time
    >> in the first place).
    >
    > This is a non-issue, or a bad solution for a problem that does not exist with existing layouts. If you want to ignore the existing layouts and try to extend it without taking them into account, you'll just get a layout that will be convenient for nobody.

    I disagree. My problem is this: Often within one day I end up working
    on 3 or more different computers, and not all of them are mine. In
    fact, sometimes none are my computers. So that means *no* control over
    what software is installed. And I don't have the time to take an
    extra hour downloading and configuring input methods. But even on *my
    own* computers, I run into various strange problems that I can't solve
    (or at least I would prefer to not spend hours and hours to solve!),
    such as: (1) an input method for Chinese works fine in one program,
    but not at all in another program (linux problem) or (2) an input
    method for simplified Chinese works fine across programs but the
    complementary input method for traditional Chinese does not work at
    all (mac os x problem).

    So in cases like this, a program like the previously-mentioned Yudit
    (yudit.org) approaches a certain functional ideal: That is to say, I
    can at least count on Yudit to *always* work, on Linux, PCs, and Macs
    alike -- it just works. Yudit may still exhibit other limitations
    (e.g., poor selection of built-in IMEs for Chinese), but to the extent
    that it does work, it works identically and consistently across all 3
    major platforms (plus of course all the other minor *nix variants
    too).

    >
    > so either define a new national standard that completely replaces the existing one and adds the necessary characters
    > you want to add (but beware to the location of basic letters, there's a strong resistance against changing between
    > QWERTY, AZERTY and QWERTZ, and the same resistance to change the shifted or unshifted location of digits, and the
    > location of most basic punctuations.)
    >
    > This does not give you a lot of freedom. The best you can do is to adapt the existing layout and maintaining the
    > compatibility, and taking into account also the different needs for more frequent characters: for example, an
    > extension for the French AZERTY keyboard should absolutely provide convenient mappings for French accents on
    > capitals, for the cedilla on capital C, on the curly apostrophe, and on the French « guillemets ». Other languages
    > have other needs (for example different letters, or different quotation marks).
    >
    > Building a keyboard that maps all languages with a single layout will necessarily lead to unconvenient locations for
    > some characters. I see absolutely no point in developping a pan-languistic extension that takes all the most

    I agree with what you are saying to a certain extent.

    But once again using Yudit as an example, Yudit does not take the "one
    shoe fits all" approach at all. Yudit instead says: "Here is how you
    make a keymap, and here are a bunch of keymaps that people have
    contributed."

    So Yudit comes with a dedicated "French" keymap (which has all of the
    French accents, plus the cedillas, plus the guillemets, and so on that
    every Francophone wants) as well as a "Grand Latin" (aka "Pan
    European") keymap for those times when you need to type some Polish or
    Hungarian or something.

    Most people will agree with you that the "Pan European" keyboard is
    slower for general work. True - no arguments there.

    But when what I want is *not* on the French keyboard, then I usually
    select the "Pan European" keyboard instead. So for most Latin
    languages, I get by with the French keyboard (which does not have
    everything, but I know the layout better) and use the "Pan European"
    as a second choice (which has everything, but I may have to refer to
    the map to figure out how to type what I want).

    > convenient locations, and does not leave enough space for the most wanted characters, just because the pan-
    > linguistic extension will be very difficult to learn for most users (also because there's a near zero chance to see
    > all the associated labels printed on key tops, notably on notebooks where the available space for additoonal labels
    > is very scarce).
    >
    > My opinion is that such attempt will fail, and that it will be the national standards that will be
    > updated
    > invidually, specifying the additional labels that will have to be present,

    Fine. But all standards-making bodies are *slow*. I'm not going to
    wait. If I want to be able to type it today, it is best to have a
    flexible system such as Yudit where I can even write my own custom
    layouts in an hour ...

    (OK, that's definitely not true for CJK input methods, but that's
    another story ... )

    > but not requiring all the labels that the
    > layout may support in some advanced input methods (which may also remain unavailable on smaller keyboards with less
    > keys). For now, there's absolutely no demonstration that any national keyboard needs a Group3 or Level3 selector:
    > four standardized characters per key is MUCH enough for most extensions.
    >
    > And ABSOLUTELY NO pan-linguisitic extension should ever try to use any of these 4 possible assignments (2 "groups"
    > with or without AltGr, and 2 "levels" with or without Shift possibly locked in by CapsLock or NumLock for distinct
    > subsets of keys), strictly reserved for national standards.
    >
    > If you really want it, develop a completely new standard and try to convince PC makers (notably notebooks) to
    > provide models with this completely new layout (but I doubt that they will accept to build such notebooks in masses,
    > it will possibly be easier for separate desktop keyboards sold separately from PCs, or if the PC makers allow users
    > to choose their keyboard, or to replace it very simply at a low cost for notebooks.
    >
    > But note that detaching/changing the keyboard on notebooks is not an easy operation due to the way they are mounted:
    > in most cases you can't change it without invalidating the manufacturer warranty, or risking to loose some tiny
    > screws, or damage the connector, or even break the PC case or the very thin motherboard supporting the keyboard;
    > it's also nearly impossible to change the keycaps without damaging their thin mechanism using fragile molded pires
    > in plastic.
    >
    > Of course you can buy on the Internet a PC built for another country, but generally this requires additional
    > shipping charges, and complicates the use of the warranty (which is already very complicate!). In most malls and
    > shops, you will just find PCs built with the national keyboard only. Desktop users can more simply connect another
    > external keyboard (including on notebooks using a USB connector or wireless USB adaptor).
    >
    > So, the developers of a "universal" Latin layouts are just dreaming: they completely forget usability for most of
    > customers that type nearly 100% of their texts in a single language (and in alphabet that they know and practice)

    Not necessarily. There is a place for "Pan European" layouts, just as
    there is a place for language-specific layouts. And not just in
    Europe. I've also been working on a "Pan African" layout -- but *not*
    to the exclusion of African language-specific layouts. For example,
    I'm working on an Igbo layout. My intuition is that the Igbo layout
    will get used more often than the "Pan African" one because the Igbo
    one is really simple and the Pan-African one is really *not* simple.
    These latter two serve different audiences: Anyone who speaks Igbo and
    can type can learn to use the Igbo layout in a minute, while probably
    only linguistic specialists will have interest in the "Pan African"
    layout.

    Best - Ed

    > and want to type it fast (they can still access very rerely used characters from a program or software addon like a
    > clickable charmap).
    >
    > Philippe.
    >
    >
    >
    >
    >



    This archive was generated by hypermail 2.1.5 : Thu Jan 07 2010 - 20:30:07 CST