|
Post by Admin on Mar 27, 2020 10:16:18 GMT -5
Hello to all Q Keyboard users, and anyone interested in the subject of enhanced keyboards.
I set out in 2016 to create a keyboard that would, first of all, try to compete with other designs being proposed when France asked AFNOR to redesign the French keyboard. Halfway through the process, I realized that I could make something that might help not just France but have international appeal.
After many, many changes and revisions, the Q Keyboard was "finished" - at least as finished as something like this can get. It took over three years to do, and it's an accomplishment I'm mostly pleased with.
Except ...
Even I think the Q Keyboard is complicated - and I made it. The manual runs some 700 pages. That's a lot. And, it incorporates many modifier levels, requiring some hard-to-hold combinations. Further, in the name of retaining full QWERTY compatibility when extended features are not being used, every non-QWERTY letter or symbol requires at least two keys to be held down at the same time (such as the AA modifier plus O to produce an ö letter). I am mindful of people with dexterity issues, perhaps persons who can only use one hand to type with (or possibly with none, for severely impaired persons forced to use a mouth stick) and my own hands are "talking to me" as I get older and have to deal with a slight arthritis in my fingers.
I have been wondering if there was an easier way ...
Over the last six months, I have been working on a new keyboard. Two of them, actually. But, first things first.
A significant problem for any advanced keyboard is trying to decide who will use it, what they will use it for, and why. For instance, an English-speaking person in the U.S. might rarely or only occasionally need to type out non-English names, addresses, etc. while someone in Europe or Africa or South America may need to use it for everything. Some will require just a few accented letters, and others will type sentences filled with letters having diaeresis, macron, tilde and other marks. It's an issue of having two "use cases" - one only needing simple features and one requiring powerful, extensive facilities.
It seems like we can either make a keyboard to be simple - or powerful - but not both.
Or, could we? Is there a way to accomplish both goals with one keyboard at the same time? I think so.
A while back, I tried an experiment in which the idea of "dead keys" was turned on its head. That is, a "normal" keyboard adds accents by pressing a dead key first, then a letter. So, to get letter ä you press a diaeresis dead key, then the A key. To get á you press the acute accent key, then the A key, and so on. But, suppose you could press the A key first, then decide afterwards what accent you wanted? That's how you have to do it with combining modifiers, but suppose you did that with everything?
The idea was that - somehow - the letters themselves were dead keys, and by typing punctuation keys afterwards, the two would be combined. That would mean there'd be (at least) 52 dead keys, with every letter a-z and A-Z defined as a dead key. Because all letters are dead keys, and they would always be "active" without having to press a modifier like AltGr first, we could say that the letters became All Dead Keys, All The Time. That's where the acronym ADKATT comes from.
Well, this was a crazy idea, to be sure, and it turns out that the keyboard interface in Windows wouldn't really handle it anyway. And, there are problems when you wanted a letter that's NOT accented. It isn't really practical to do this, but it was fun trying. At that point, I filed the ADKATT experiment away and figured that was the end of it.
Two things happened that got me to change my mind.
First, I recalled my experience making the Q Keyboard, and with some work I did enhancing the current French keyboard. To do that, I researched pretty much every Latin-based keyboard ever made. There are non-English keyboards that have what I term "immediate accents". For instance, the German T2 keyboard has two immediate accent dead keys, which are Circumflex and Acute. When you need one of these accents, you don't have to hold AltGr or Shift or Ctrl, or any combination thereof. You just type the accent key, then the letter key. To type a letter like é on that keyboard, you type the Acute immediate accent, which is about where the =+ key is on QWERTY, and then the E key. What is especially nice about immediate accents is that you don't have hold down a modifier like AltGr at the same time you're typing the letter key. That means there is less typing effort needed, and it opens up the possibility of using an international keyboard by persons with limited dexterity or perhaps severe limitations.
Second, the underlying technology has improved. KbdSoft, the company that makes the KbdEdit software used by the Q Keyboard, has updated their product so that it is now possible to "overload" keys like Caps Lock. When that is used in conjunction with a modifier called Kana Lock, it is possible to define a keyboard that operates in two different "modes", almost like having two completely different keyboards and being able to switch between them. (Kana is the modifier used by the Q Keyboard for its CC key.)
When these two factors are combined with the general concept of my ADKATT experiment, we can make a *real* ADKATT keyboard, which is both practical and easy to use, AND can actually be implemented on existing Windows computers.
The result is a new keyboard that operates in one of two modes: QWERTY mode or ADKATT mode. In QWERTY mode, you hold an Alt key and type an accent key, then let go and type a letter. So, to type ö you hold an Alt key and type the ; and then type the O key. That's pretty standard, just like all other Alt/AltGr international keyboards.
In ATKATT mode, you don't need to hold Alt/AltGr. Just type the ; key, let go, and type the O key. That's it. It's easy, it's fast, and requires the least possible effort. In ADKATT mode, every dead key becomes an immediate-accent dead key.
That's great, but it brings up a few questions. Like, if ; is the diaeresis dead key, how do you type a "real" semicolon? There are a few ways to do it. First, if you only need one, type the semicolon key TWICE. When you do that, it's called a LITERAL key. Second, you can hold the Alt key and type the semicolon key, which allows the key to repeat if you wanted it to. All the dead keys work the same way; each has a "literal" way of typing it. You can also switch back to QWERTY mode if you need lots of punctuation or numbers and few accented letters.
(The ADKATT idea of "literals" is different than the Q Keyboard's notion of literals. In the Q Keyboard, a "literal" is a lone character that represents an accent, like a stand-alone tilde or macron. You can still type these, but they are just called non-combining modifiers, not literals, and they are typed differently.)
If you want to add-on an accent, ADKATT does this in a easier way. Suppose you want to type n̈ which is not a Unicode letter. (This is supposed to be a lower case N with Tilde, but based on your browser, it may or may not display correctly.) To do that, first type "n", then the semicolon key, then Spacebar. There's more to it, but that is the idea.
How do you go about switching "modes" between QWERTY and ADKATT? You hold down the Ctrl key, and type Caps Lock. That is part of the new technology that makes all this possible. For now, the keyboard will start up in QWERTY mode. It's certainly possible to make a version that starts in ADKATT mode. If there is sufficient interest I can look into it.
The ADKATT keyboard is intended for Latin languages, but also has complete support for Cyrillic, using a unique design utilizing dead keys. Like the Q Keyboard, the support in ADKATT for Cyrillic is intended to be "secondary" and only for short words and passages. Thus, the proper name of this keyboard is actually ADKATT Latin. With some effort, it is possible to design a Cyrillic keyboard in which Latin usage is secondary. Such a keyboard would be termed ADKATT Cyrillic. That is the second of the two keyboards under development.
Right now, I have a working version of ADKATT Latin, which requires further testing and documentation. Once that is done, I will convert it to an ADKATT Cyrillic keyboard. The Cyrillic version will use the same dead keys and dead-key character tables as ADKATT Latin.
A very large part of what ADKATT is capable of derives directly from the Q Keyboard. However, ADKATT supports two unique modifiers instead of three, having AA and BB, but no CC, in order to simplify its design. So, some Q Keyboard features will have to be omitted. Even so, the vast majority of what you could do with the Q Keyboard will be available on ADKATT. The main features not supported are the full list of math symbols, combining modifiers and archaic letters. There is SOME support for these, but not as much as the Q Keyboard. As far as accented letters go, you should find everything you need is here, and it will be easier to type.
I'm not done with my work, but I wanted all of you know what I have been up to.
I will update this post as ADKATT gets closer to release.
---
In closing, I know we are all living in a crazy and fearful time in this world. Things like designing a keyboard doesn't seem very important at the moment. Still, I would like to encourage everyone out there not to give up. Whatever it is you do that brings meaning to your life and helps others, keep doing it. If this crisis can teach us anything, it's that it is one world, and everyone needs everyone else.
I wish you all the best.
Robert
|
|
|
Post by Admin on Apr 4, 2020 11:10:27 GMT -5
I want to mention that while I am working on the new keyboard, this would be the time to add your comments or suggestions if you have any. I am pretty sure that, barring any major new flaw someone might find, I won't be changing the Q Keyboard any further. I am concentrating my efforts on the ADKATT keyboard now.
Bearing in mind that one of the ADKATT keyboard's goals is to be simpler than the Q Keyboard, I am not going to try to add every conceivable symbol to it, but only what I believe people will actually need.
To determine that, I have (again) made an exhaustive analysis of the Omniglot web site, which is quite a bit larger than when I first started this journey back in 2016. I looked at every Latin and Cyrillic alphabet on file, to make sure that every letter, symbol and punctuation in use by current users of those languages can be typed on ADKATT. I have done that, and the new keyboard will be easier to type and it will be easier to remember where letters are located. You should find it much more intuitive.
However, perhaps an area that might impact some users, I am not planning (yet, anyway) to have exhaustive support for all combining modifiers. I do have a LOT of them, but these are ones that either (a) certainly exist in current languages, or (b) are obvious choices to add.
For instance, key 1 is the Tilde dead key, like the Q Keyboard. If you want to add a tilde to a letter than doesn't already have one, the key sequence is 1 Spacebar. If you want to add a Tilde below, it's 1 then AA+Spacebar. Whenever there is a "primary" accent that has an associated "secondary" that is included with the main dead key. For example, adding an Acute accent is ' plus Spacebar, and Acute Below is ' plus AA+Spacebar.
I am mentioning this because Acute Below is rarely used. But, it is easily added and there's no reason not to have it, so it's there.
However, there are a lot of combining modifiers. Even eliminating ones outside the scope of the keyboard, like ones for Katakana, still leaves over 300. It is not "impossible" to make room for all these, but doing so would be hard. Most of the locations would not be intuitive, and they would hard to type. I have to weigh that against the work of creating entries for all of them, and the limited user response to date.
That's where you would come in. You have a chance to shape what the ADKATT keyboard will contain. Now's the time. If you really need some particular symbols for your documents, speak up now and let me know. Once I'm done with it, I *probably* won't be making further changes to it later.
I can't stress this enough: I really need your feedback now.
OK?
|
|
|
Post by Admin on Apr 5, 2020 19:43:40 GMT -5
To try to give you an idea where the ADKATT keyboard is going, I had recently added "palatal hook" letters to the Hook Above dead key, since it so happens that they completely fit within the Hook Above letters with no conflicts. But in doing further research, I found that there appears to be no natural language that uses Palatal Hook letters (not even African languages, which often 'borrow' phonetic symbols from Unicode to complete their alphabets). They only appear as phonetic symbols used by linguists. Because of that, I backed out this change, and so the ADKATT keyboard will no longer have palatal hooks.
Now, if I heard back from some of you that this was an interest of yours, the final design might reflect that. I know that a number of people visit this site without registering. I don't track users and would never send you annoying email, except for an occasional Hello to keep you updated. So, there's really no down-side to registering as a user. I hope you do, so we can help each other. The point is, there are evidently people that are interested in the keyboard to some extent. If you are one of them, and have some particular interests, please don't sit on the sidelines. Let me know if I can be of help.
I am continuing to refine ADKATT, but I can tell you now that the changes are coming slower and less frequently. The design is nearing its completion. I have to tell you, in terms of what the average user wants and needs on a daily basis to type international languages, ADKATT will have EVERYTHING you need, and it will be MUCH easier to use than the Q Keyboard.
I hope you will all try it out once it is finished.
Robert
|
|
|
Post by Admin on Apr 13, 2020 19:29:52 GMT -5
Hello everyone,
Well, I am getting my first results from the experimental ADKATT Cyrillic keyboard. It is interesting how it is working.
I have a list of dead key tables for each dead key, such as Acute, Macron, etc. Each one takes a basic key, like the A key, and converts it into some accented letter, so 'a' may become ā or ä. In the entry for 'a' there is a numeric code 0061 which is Unicode for that letter.
What I do for the Cyrillic keyboard is I take all of these deadkey tables and translate them so they use the corresponding Cyrillic letter instead. In this case, Latin 'a' is 0061 and Cyrillic 'a' is 0430. By doing this translation process, I only need to maintain one set of tables for both keyboards instead of two (which would be too hard to maintain).
I still have work to do, but it's very encouraging so far.
Robert
|
|
|
Post by Admin on Apr 18, 2020 19:44:10 GMT -5
I now have a working ADKATT Cyrillic keyboard. There is still a lot of testing to do, but so far things are going well. I surveyed the Omniglot web site for all Cyrillic-based languages, which it has 119 of at present. I can type every letter in every language. I can even do languages that are difficult (even for Cyrillic, which is already hard). There are some that have embedded Latin and Greek letters, some have letters with combining modifiers like Г with a Caron added, and some with macrons and modifier letters like ᵸ added. I also spent a bit of time trying to "smooth out" the action, so that even though some characters were "available" I wanted to make them easier. That meant adding alternative key sequences.
All told, there are about 2000 unique characters on the keyboard available as dead keys, plus the "live keys" holding 7 levels x 47 keys = 329 keys, for a total of 2329. So, the keyboard is competitive with the Q Keyboard, which has 2475 unique keys.
Once the big task of documenting all this is done, I will be getting close to putting out an initial release.
One of the tasks that has occupied so much of my time is ensuring that the Cyrillic part is actually usable. My goal is that a native user of a Cyrillic keyboard, such as Russian or Ukrainian or Bulgarian would be able to use the ADKATT Cyrillic and a U.S. QWERTY device and actually LIKE using it.
To give you an idea what letters this will support, here is me actually typing on the keyboard, with all the letters on the QWERTY keyboard as they are mapped to Cyrillic, from top to bottom:
̃` ѥ э з ч һ б ̊̇ ̑ ̆ - = ю ш е я т у ц і о р ф Ӏ \ а ѕ д г ә н ј к л ; ' ж х с п в и м , . /
Here you can see how I have tried to match Cyrillic letters to the QWERTY ones that most closely LOOK the same. This is different from other keyboards that try to match QWERTY based on what letters SOUND like.
There are a couple of problems with the phonetic approach. First, I personally don't KNOW any Cyrillic languages, so I have no idea how many of these sound. Oh, I know a few, but that's all. Second, the sounds vary by language for the same symbol. In contrast, the letter Ш always looks very similar to a Latin W no matter what it sounds like in someone's language. So, I don't *have* to know or be an expert. All I have to do is LOOK at the letters.
Some of the choices you might find amusing. For instance, there is no good letter for Г Ge, which is like a Greek Gamma, but Latin F is pretty close, so that's what I use. Then the Ә Schwa letter is on G, because in my eyes, the Ә is like a G that was flipped over. Same with Я on R, and И on N. Some are a little tricky. There just isn't any good place to put П so I imagine the letter V is turned upside down like Ʌ and then the top got "squared off". You have to use your imagination a little to work with this, but with practice you will get the hang of it.
|
|
|
Post by Admin on Apr 20, 2020 10:29:43 GMT -5
One of the things I wanted to do in developing the ADKATT Cyrillic is to make it as easy as possible to use for native speakers, as much as possible. In surveying all the Cyrillic keyboards that exist now, they all struggle with trying to accommodate their own languages, while adding as many features as they can that they think people will need. That causes certain design choices I have had to cope with.
One is that, for some reason, Cyrillic typists really seem to like the symbol № (the Numero Sign). I have no idea why, since Numero is basically a Latin word for Number, and the letter N doesn't even exist in Cyrillic. (They use H for the N sound, and the somewhat similar И is actually like I in English.) Anyway, their keyboards all seem to have this, and I needed a way to include it. There is also a need for local currency symbols. For Cyrillic-using people, the main ones of interest are the Ruble, of course, as well as some others like the Mongolian Tugrik, the Yen sign, and one called a Hryvnia, which looks like a reversed S with horizontal lines through it.
I have something in this keyboard called a Latin Gateway. It's a way to access all the dead keys associated with the ADKATT Latin keyboard while using the ADKATT Cyrillic one. Using the Latin Gateway, you can type 9 4 P to type the Ruble sign. However, that is a lot of typing; I wanted it to be easier.
So, I simplified the Latin Gateway by only storing the most important Latin dead keys, and freed up letter P. So now, if you are using the ADKATT Cyrillic, you can get to the Ruble by just typing 9 P instead. Using the same technique, the Numero sign is 9 N. Other frequently used currency is done the same way.
|
|
|
Post by Admin on Apr 21, 2020 12:36:54 GMT -5
A task any keyboard designer faces is, "are you sure you really want to do it that way?" Getting a keyboard to "work" is straight-forward, and to an extent, it's a mechanical process. Getting it to work so that someone would actually WANT to use it is something else. Sometimes, typists can be gluttons for punishment. Before France redesigned their keyboard, people were using ALT + the keypad to type the numeric codes for AE and OE and capital letters with accents. What a horrible experience they had.
The ADKATT keyboards are nothing like that. Pretty much everything is easy to do.
Except ...
The Cyrillic alphabet has many challenges. The keyboards that currently exist for it now are not perfect (and, neither is mine, to be honest), but they try to do the best they can.
I have tried to do that as well, but I am now at a point of having a "mid-life crisis" in the design. The biggest difficulty with typing Cyrillic on a keyboard that has the same physical keys as a QWERTY does (and surprisingly, that is nearly ALL keyboards in existence, for EVERY language and script imaginable) is that there are just too many Cyrillic letters. The ADKATT Cyrillic keyboard supports 156 unique letters, each having upper and lower case, for a total of 312 symbols. That's a lot to try to assign to 26 English letter keys.
As a result, native Cyrillic keyboards cram as much as they can into it, and they give up a lot in return. They usually have far fewer kinds of extra punctuation that a U.S. QWERTY does. They almost never have things like @ # $ & [ ] { } etc. I have made a point of making the complete U.S. QWERTY symbols available, so you don't lose anything. Still, somehow I have to accommodate all those letters.
I cannot escape such issues. For me, to make the keyboard usable, you have to give up direct access to the digits and the [ and ] keys. Some of the digits are dead keys, while the rest are used as letters. For instance, the letter in Cyrillic that has the English sound of "B" looks similar to a 6, so that letter is on the 6 key.
Another problem is that Cyrillic has a large number of letters that are very similar. There is a group than resembles "B". They have one that looks like a capital B and a small-caps B, which corresponds to our V. As noted above, the letter pronounced like "B" and looks like a "6" is on key 6. Then there are a number of letters that look like a lower case "b" or "bI". They are called, Soft Sign, Hard Sign, Yeru, Yeru with Back Yer, Yeru with Diaeresis, and so on. There are also "historical" Cyrillic letters that are in Unicode but not seen in everyday use. These are things like Neutral Yer, Yat, and Iotified Yat. And they ALL resemble the letter "b" in one way or another.
All these letters can't possibly be assigned to the same B key. No one would remember them all. Yes, we could put them on the various dead keys, but those dead keys are intended for specific reasons. Assigning Yeru with Diaeresis to the Diaeresis dead key is a "no brainer", but what about Yeru with Back Yer, and Neutral Yer? Where to THEY go? The answers aren't so easy.
Then, there are ergonomic issues. There is a Cyrillic letter that looks like a reversed N with a Breve. I could put that as "Breve N" - and I do. But there is a big problem with that. This letter, Й, is called "Short I". Well, Short I is used a LOT. For typical sentences in Russian, Short I usually appears 2 or 3 times in every sentence - sometimes more. But, the "keying distance" between the Breve dead key on the 0 key - and key N - is pretty large. It's hard to type, EVEN though it's "logical" and makes perfect sense. A native typist would not really CARE that it's "logical". All they would care about is that typing this frequently-used letter is too hard for them.
What to do? I'm working on it ...
More to come.
|
|
|
Post by Admin on Apr 21, 2020 21:57:03 GMT -5
Well, after doing a full survey of Omniglot AGAIN and tallying up every used letter, it turns out that there are just 100 letter pairs (200 with upper and lower case) that are actually USED, not 156 pairs. That means I can focus the available dead keys to things that are in actual use, and use that information to make the keyboard easier to use for the letters people really want.
What about all the *other* letters? I won't remove them, but now I can "put them off to the side". How? By creating "secondary dead keys". When a letter is on a secondary dead key, you have to type TWO dead keys to get to it. That would be a problem if you had to do it all the time, but now that I know which letters are really used and which are not, I can "sideline" all the archaic and discontinued letters into secondary dead keys, and concentrate on the ones people use the most. I am also using this information to re-allocate the "live keys" so that I will no longer dedicate a "live key" to the letter called "Palochka", since it is rarely used. Instead, this will go on a Dead Key, and that will free up the ]} key position for something more important. Most likely this will be the Й letter, which is frequently used.
|
|
|
Post by Admin on Apr 22, 2020 10:52:50 GMT -5
Well, with languages, nothing is ever simple or what you think it is at first. I was sure that the Komi letters were all archaic, but it turns out that ONE language uses ONE letter from Komi.
When you are trying to design something that everyone in the world might possibly use, you can't do everything, nor can you "optimize" things to benefit one group without "de-optimizing" it for another group. That's just the way it is. The guiding principle has to be, Provide the most benefit to the most people. Sometimes, a rarely-used letter simply has to be "put on the side", such that it's a little harder to type, in order for commonly-used letters to be easier.
This is the hardest question in keyboard design: Which letters should be supported, and where do they go? It's not like there is some place you can go, or book you can read. The answer takes research and work and puzzling over the situation. And sometimes, there is no ideal answer, but since you HAVE TO answer the question, you will end up making a choice because you have to, and it might be a compromise. It's really a learning experience. If I knew in advance the answer to that question - what letters to include and where to put them - the keyboard could be designed in a matter of days. It's all the research and decisions that take all the time.
|
|
|
Post by Admin on Apr 22, 2020 20:28:44 GMT -5
I think I have a good solution. There are two dead keys, which I call Miscellaneous and Extra, on keys 8 and 7. These are "catch-all" dead keys, where I put letters that are hard to categorize.
The thing is, when low priority letters, such as archaic ones, were put elsewhere, it freed up a lot of room on 8 and 7. So now, these keys act like "hot keys" in a way. They don't require Shift or Alt or anything to activate, so they are easy to type. I did an analysis of which accented keys are most likely to be required, regardless of the accents they had, and the top two get put on keys 8 and 7. You can still type them the regular way, for the most part, but this design increases the chances that if you want a key with an accent, it might often be found on 8 and 7. This should make it much easier to type.
The downsize to this idea is that there's a whole mishmash of letters on these two dead keys. They are not at ALL intuitive, and you will have to learn them. The good part is, if you needed any of those letters, you WOULD learn them, because you'd use them all the time. Once you remembered where they were, they will be much easier to type, requiring less time and effort than going through their "official" dead key typing sequences.
Right now, all this is theoretical. I will have to test out this theory with some typing practice.
|
|
|
Post by Admin on Apr 23, 2020 14:17:46 GMT -5
A few days ago, I wrote that "there are a number of letters that look like a lower case "b" or "bI". They are called, Soft Sign, Hard Sign, Yeru, Yeru with Back Yer, Yeru with Diaeresis, and so on. There are also "historical" Cyrillic letters that are in Unicode but not seen in everyday use. These are things like Neutral Yer, Yat, and Iotified Yat. And they ALL resemble the letter "b" in one way or another."
Up until now, I haven't figured out a good answer for this. Oh, I have "answers", jut not good ones. There are actually 3 different ways to type these symbols right now, and none of them are all that good. They are OK, but not good.
I have also been trying to figure out what to do with the "]" key, since I am not going to be using it for the Palochka sign any more.
Well, lo and behold, I figured it out.
The "]" key will become a new dead key, the YER key. "YER" is a general term for the hard sign, the soft sign, the Yeru sign, etc. All those symbols that look like "b" or "bI" in some way.
So, if you press "]" twice, you will get the soft sign Ь. Typing ]\ will get the YERU Ы and typing ][ will get the hard sign Ъ. Other related symbols will work in a similar way.
By doing this, all these "b" symbols will be collected in one place and will be easy to type.
Yay! This is going to work.
|
|
|
Post by Admin on Apr 26, 2020 13:28:57 GMT -5
So much for theories :-((
An important part of any keyboard design is to TEST the design. Of course, it's important to test whether the keyboard actually does what you SAY it does. But, proper development habits can ensure most of that. Pretty much if you know what you're doing, you won't make mistakes or design it improperly. The biggest risk is just forgetting something like copying a file, running the processes in the correct order, etc.
No, the biggest part of "testing" involves finding some native text and trying to type it out yourself. You can design something and tell yourself all day long, "oh, that is going to work" but it doesn't. That is, it "works" from a technical standpoint, but it fails in the "real" test.
What is the "real" test? This: Would you be willing to use the design every day if you were forced to, and you had no other way to type things? Applying THAT test, I quickly realized that my YERS solution above didn't work.
Why not?
It is because the b and bI symbols are used SO MUCH, that forcing people to use a dead key all the time is just too much work. Also, having to use key combinations like ]\ and ][ to type letters requires that you take your eyes off the screen or off your work to look at these keys, because they are ones you don't use often, AND they are keys you don't normally type this way. How often do YOU type the keys ]\ in that order? Or the ][ keys in that order? Neither do I.
OK. So, I have a better idea (I hope). Here goes:
The [ key will have the soft sign ь Ь and will not be a dead key The ] key will have the YERU symbol ы Ы and also will not be a dead key
Everything else will be on a dead key. For instance, to get ӹ Ӹ you would use the Diaeresis dead key and type ; ] etc. All the other symbols that look like "b" or "bI" will be typed in the same general way.
I am hopeful this will actually BE the answer. Time (and testing) will tell.
|
|
|
Post by Admin on Apr 27, 2020 21:14:59 GMT -5
I am embarking on what I might call "the great experiment". It involves a fairly major restructuring of the "live" keys. That is, the keys you type with modifiers like AA or BB but not "dead" keys.
Why the change?
Up until now, since the Cyrillic keyboard is implemented on QWERTY hardware, I have always had Latin letters immediately available, both with a "mode shift" and directly using AL and BL modifiers while in Cyrillic mode.
But, I have to consider what the likelihood is that a Cyrillic typist is going to constantly require Latin letters embedded into their documents. To answer that, how often do *I* need Cyrillic letters embedded in my English documents? Other than to compose things like you see in this post, hardly ever. I don't know Russian or any other Cyrillic language. My only extensive typing with it is to copy Russian or other Cyrillic texts verbatim for typing practice without any understanding of what the words are.
And, even with the changes I discussed above, there are things I don't like about the current ADKATT keyboard. One of them is the fact that the "B" letter, б Б in Cyrillic, is on the "6" key because of the resemblance. That's great for learners - but someone who know the keyboard would not like it in the long run, because reaching up to get the "6" is a big stretch. Typing that letter frequently gets old fast.
What to do? With the regular B and all the "b" and "bI" letters, where can I possibly put everything?
As a line from the TV show Babylon 5 said once, "the answer points to itself".
In this case, the answer is to give up immediate access to Latin letters, and go hook, line and sinker with Cyrillic. That frees up two modifier levels, allowing me to put frequently needed letters as "live keys" without requiring dead keys all the time, and without that big reach for key "6".
Here's how the immediate issue gets solved:
1. Key 6 will now have the Hard Sign. Digit 6 kind of looks like ъ Ъ and yet Hard Sign is a less-used symbol - much less than б Б is. So it won't be a big hardship to put it there.
2. We still need to put б Б somewhere. It will end up as AL B and AU B. Even though it will now require a modifier to access, it's less of a reach than the "6" key is. I am *hopeful* this strategy will work. As always, we'll know after testing.
I don't have answers on how every live-key position will be filled in just yet. I'm trying to figure it out as I go along. But, all the existing Dead Key tables will still be there unchanged (more or less). So, even if the Live Keys don't do everything, they don't have to. I have a really good set of dead key tables to start with. They should only require minor tweaking. (Which I have to be careful with, since the same tables are used in ADKATT Latin, so I have to be sure I don't mess this up. :-)
Stay tuned ...
|
|
|
Post by Admin on Apr 28, 2020 9:58:39 GMT -5
One pair of letters that needs to be supported is Che and Ka having Vertical Stroke. They look like this:
ҹ Ҹ ҝ Ҝ
Right now, these letters have their own dead key, which is the \ | key. There is also an "Iotified" dead key on key 1.
At one point, I added the two letters with vertical stroke to the 1 key as a "convenience" so they were easier to type. Then it dawned on me that all "iotified" letters were archaic except for ю Ю and that isn't even considered an "iotified" letter any more, if it ever was; it's just called YU, not "iotified O".
What all this means is that there is no real need for BOTH an "Iotified" dead key and a "Vertical Stroke" dead key. The letter ю Ю will be accessible directly on the Cyrillic side, so a dead key is not needed for that.
This gives me an opening to simplify the design. I may be able to take key 1 from being a dead key to being some other direct-access key. I am still working out the details, but this could take the design in an interesting direction.
|
|
|
Post by Admin on Apr 28, 2020 14:48:44 GMT -5
One of the things that distinguished the ADKATT Latin vs. Cyrillic is not just how the keyboards start up, but how dead keys are used. In ADKATT Latin, you would have had two "modes", one where the keyboard uses standard dead keys and the other where all the dead keys are "hot" all the time. That's where the ADKATT acronym came from.
In the Cyrillic version, I made a decision to ensure that all common punctuation was always available. If you look closely at existing native Cyrillic keyboards, most have a very poor selection of punctuation, because they have so many letters to fit in. As a result, some have barely more than comma and period, and several have no numeric row at all. That design won't work for laptops which usually don't have a numeric row. The result is that users of those languages would have to work with a separate keyboard even when using a laptop, or otherwise they couldn't type properly.
All of the designs I have made so far have taken a hands-off approach to the numeric keypad. I don't alter it - even though I could - except to make sure that it behaves as expected for any additional modifier levels that apply to the keypad. Otherwise, nothing is changed; you don't get any more or any less than a normal keypad would give you.
One of the assumptions of the ADKATT approach (All Dead Keys, All The Time) is that typists would want their accented letters SO MUCH that they'd be willing to give up every punctuation key, like commas and periods, just to be able to accent letters quickly. It's really hard to tell how true that is. One feature of the ADKATT Latin I am pleased with is that it's quite easy to type Vietnamese on it. That is no mean feat for a keyboard not designed from scratch to support it. In ADKATT mode, when all dead keys are "hot" it's surprisingly easy and fast to do. And, one side affect of my approach is that all letters produced are "precomposed", and don't used combining modifiers. It's hard to be sure without having a version of Windows that has Vietnamese as its installed language to be sure, but from what I have been able to determine, it seems like Viet keyboards add all "second" accents as combining marks. This is a simpler approach, and requires smaller keyboard lookup tables, but for any letters requiring dual accents, it doubles the size of the data stream. Perhaps Vietnamese-oriented software takes that into account and "corrects" it, but my design doesn't require any "correction" of the data stream.
Anyway, if I took out the ADKATT idea of "hot" dead keys and only used conventional ones, it opens up an interesting possibility.
It's already pretty clear that the Cyrillic version can't run with all dead keys being "hot". There are just too many resources required as it is; there's just no enough free keys to do everything.
So, suppose we put all that together? What do we get?
The answer is: symmetrical Latin and Cyrillic support.
That is, a keyboard can be made where one mode is fully Latin and one is fully Cyrillic. Then, the only difference between the "two" versions is that one will start up by default in Latin, and one will start up in Cyrillic. Since the "mode switch" involves what is known as Kana Lock, it has the side effect that Caps Lock will only work in the primary (start-up) mode; it's simply not recognized when Kana Lock is on. If your only goal is to quickly write something in the "other" script, that shouldn't be a big issue. Otherwise, if you have some "serious" writing to do in the other script, the best thing would be to go to Windows and select the "other" keyboard, rather than changing modes.
The impact on doing all this should be surprisingly minimal. Both keyboards already contain ALL the dead key tables for both Latin and Cyrillic, and there are the same number of "live" keys as there always was, so there shouldn't be any memory constraint issues.
That way, the "other" keyboard won't be a "compromise" keyboard in any way. The "secondary" mode of both keyboards will be capable of doing everything that the "primary" mode of the other keyboard could do.
It is possible a set of keyboards like this might be of interest to places like Kazakhstan, where they are planning on transitioning from Cyrillic to Latin. In all likelihood, the transition will take a while, and people will need to write with both alphabets for some time. This might be a real help to them.
|
|