The promise and limitations of Dvorak...

by Michael S. Kaplan, published on 2012/10/25 07:15 -04:00, original URI:

The other day, Stanislav asked me a question via email:

Hello Michael,
I got your contact from Dmitri when I asked how to report the following user complain.
I have a friend who became a fan of Dvorak keyboard layout for English. He lives in Russia, so he also uses Russian layout.
So, let’s say he has two layouts: Dvorak + Russian, and no QWERTY.
Let’s say he opens notepad, types something, and then wants to save.
When he is in Dvorak, Ctrl-S (where S is Dvorak S) will do that.
When he is in Russian, Ctrl-S (where S is Dvorak) issues an Open command instead, because O in Qwerty = S in Dvorak.
So, in Russian, the shortcuts being used are based on Qwerty English layout.
All this makes the whole idea of shortcuts unusable for users who love Dvorak and also use a non-latin layout. Because shortcuts start to depend on the active keyboard layout (which is preserved per application, so a switch between application changes current layout, sometimes unexpectedly for a user).
Note, that Russian doesn’t have many Latin letters, e.g. S, so Ctrl-S is naturally from Latin, not Russian. And it is counter-intuitive that S can be taken from a layout that doesn’t exist in the system.
To me this looks like a usability design flaw, but I’m not a specialist here at all.
Also, I’m not sure what the best solution is. I can imagine additional settings, for example a checkbox “Use this layout for standard shortcuts”, or an extra choice of keyboard layout for shortcuts.
I know that the number of users affected is very low, but they are severely affected.
The same problem exists in Mac-OS too. So Microsoft has a chance to be first to resolve this issue 
Is it a known problem? If not, will it be added and tracked? Or are there any plans to resolve it?

Interesting issue!

In fact, the kind of question Dmitri could have asked! 

Ah yes, the Dvorak Simplified Keyboard.

One of its one true and virtually uncontested criticisms is a part of this question.

That Wikipedia article can get the ball rolling. The overview:

The Dvorak layout was designed to replace the QWERTY keyboard layout (the de facto standard keyboard layout, so named for the starting letters in the top row), in which keys are arranged to avoid mechanical jams by slowing down typing on the first generation of economically successful typewriters. The original QWERTY keyboard suffers from many problems that Dvorak himself identified:

Dvorak studied letter frequencies and the physiology of people's hands and created a layout to alleviate the problems he identified with the QWERTY layout. The layout he created adheres to these principles:

Now, to get into the problems Stanislav raises, we'll look to the next paragraph: 

The Dvorak layout is intended for the English language. In other European languages, letter frequencies, letter sequences, and digraphs differ from English. Also, many languages have letters that do not occur in English. For non-English use, these differences lessen the supposed advantages of the original Dvorak keyboard. However, the Dvorak principles have been applied to the design of keyboards for other languages.

 Let's look at the US and Dvorak keyboards:


Looking at them a bit more closely, you'll see one of the main [unstated] design principles.

When one looks at s (U+0073, aka LATIN SMALL LETTER S), whether on the US keyboard:

Or the Dvorak keyboard:

They both use VK_S for the key. 

Now I described these things in Accessibility, Internationalization, and Keyboards (#1: Shortcuts) and Accessibility, Internationalization, and Keyboards (#2: Accelerators), in particular the way the accelerators followed the letters, while the shortcuts follow the VK values.

For those two, the values are kept in sync.

Now, let's look at the Russian keyboard:

This approach is pretty much the same one for all non-Latin keyboards -- the scan code/VK mapping is not maintained.

How could it be?

Plus the  overall lack of serious work to extend the Dvorak layout to other Latin script languages hurts their utility.

Thus it is hard to call it a bug - it looks like a series of Dvorak design limitations....

Random832 on 25 Oct 2012 8:45 AM:

"in which keys are arranged to avoid mechanical jams by slowing down typing on the first generation of economically successful typewriters."

This is a myth. Or, rather, it's half a myth. It did slow down typing (provided you ignore the slowdown caused by jams), but this was before touch-typing was invented, and the _means_ by which typing was slowed down was _by making you alternate between the left and right side of the keyboard_ - which slowed down one-finger hunt-and-peck typing.

Alex Cohn on 28 Oct 2012 3:26 PM:

I guess the remedy could be a Cyrillic keyboard with regular layout, but Dvorak VK mapping. I believe such can easily be prepared with MSKLC.

BTW, the link to the **Shortcuts** post is broken. The right one is:

Alex Cohn on 28 Oct 2012 3:34 PM:

On a similar, unrelated topic: I found a bug in keyboard switching in Windows 7. I could not find a way to report the bug, and when I posted it on some forum I got answers of type "please verify that the problem persists on" [home edition, domain, no domain, with SP, without SP]. So very soon I gave up.

The bug sums up into following: when a user changes password, Windows forgets the keyboard shortcuts to trigger specific input languages (I use Alt-Shift-1 for US English, Alt-Shift-0 for Hebrew). Alt-Shift to cycle around the input languages is remembered.

Matthew Slyman on 16 Apr 2013 1:57 AM:

In my opinion, ergonomically speaking, keyboard shortcuts are inherently broken - especially when you start by trying to associate functional shortcuts with Latin letters which are in turn loosely associated with English words! With this as our starting-point, we are bound to go wrong at some point (and as soon as we start trying to apply the same design principles to shortcuts for other languages, we're going to end up with almost unmanageable conflicts where say three English-oriented shortcuts would ideally require the same two keyboard letters in Italian - when your keyboard is densely packed with shortcuts, this problem gets much worse).

Ideally, key caps should have functional icons (which wouldn't work for application-specific shortcuts unless the keycaps could dynamically display different symbols e.g. via tiny e-ink screens on each one or such like), or for those times when you're repeatedly using shortcuts (cut/copy cells in a messy spreadsheet to tidy it up), there should be separate buttons (perhaps on a separate keypad) for things like "Cut, Copy, Paste... Undo, Redo..." Perhaps eventually most desktop computers will sport a secondary tablet incorporating e-ink/Wacom technology. Thinking as an engineer and an ergonomics enthusiast, I feel that would be my ideal solution! If not for the expense, that's how we'd all be working already.

Matthew Slyman on 16 Apr 2013 1:58 AM:

By now, Mr. Kaplan, you will probably have gathered that I have independently arrived at the same question that Stanislav asked. You appear to have missed a few facts! For starters, most young/modern Russians speak English as a strong second language. They use English on a daily basis for business, social networking, SMS text messaging (there are flaws in SMS system design that bloat the size of non-Latin scripts! There's no good reason why a message in Cyrillic should take twice as many texts as the same message transliterated into the Latin script, but that's what happens.)

So for better or for worse, for good or bad reasons; people are settling on Latin-script and English-language as a sort of lingua-franca for computer technology and everything we do through computers (as well as a lingua-franca for many business and educational purposes). Speakers of Slavic and Germanic languages are generally very good at English (good enough that many of them feel totally comfortable using the English-oriented keyboard shortcuts). This is despite the existing status of Russian as a continental lingua-franca within the old Soviet republics etc. (If we're going to be honest, based on my cursory examination of the ever-reliable Wikipedia, Soviet computers were based partly on reverse-engineered Western designs. There was always some influence there, implicitly at first, and now explicitly.)

Therefore I would suggest that there are three possible approaches to shortcuts:

1. Stick with the Latin-script/English-language/QWERTY based shortcuts, for all languages (take advantage of muscle-memory with constant relationships between position and function, that are preserved regardless of keyboard layout, even if a person moves from Uzbekistan, Hungary or Myanmar to the USA or Canada).

2. Use families of positional shortcuts that generally follow the principles of Point 1, but where there are several options: QWERTY/AZERTY/QWERTZ/Dvorak etc.

3. Customize fully according to language/layout, using the general design principles that brought us the English/Latin/QWERTY based shortcuts. (Monolingual beginners will like this when being taught by local specialists, but otherwise, this is a pretty bad idea, and many people are going to really hate it, such as people like me who switch keyboard layouts/ scripts on a regular basis for multilingual communication or programming, or people who are working in a country they were not educated in using a locked-down installation of Windows in a company where the IT department has their own little kingdom...)

Matthew Slyman on 16 Apr 2013 2:06 AM:

I suggest we should follow the rubric established by Scott Horne (which I discovered after I started trying to do the same thing on a smaller scale). We should do what Stanislav is asking. We can remap the English/Latin/QWERTY shortcuts in a 1-to-1 mapping for the US-English/Latin/Dvorak layout. Then we can create a wide range of layouts with approximate phonetic/positional equivalence to this, and we can use the same shortcuts (and the same muscle-memory and touch-typing skills) regardless of which language/layout we are using. I suggest we should take the middle road: Option 2.

It is already well understood that letter-frequency (and therefore locally optimized layout, e.g. using Dvorak's techniques) depend on language (and even perhaps, dialect). But to optimize keyboard ergonomics in the broader sense, in a modern globalized economy; we're going to have to bring it all together: we're going to require a whole family of international layouts that use the same shortcuts.

I'm going to try to fix my "Dvorak International Scientific" layout according to the principles you have hinted at above, and elsewhere e.g. here:

Will report back on the results... Send an email to the address registered on my MSDN/Passport/partner account, if you want a copy of my layout to BETA test!

Matthew Slyman on 16 Apr 2013 2:22 AM:

One more point I must make now in relation to differences between languages, letter-frequencies, digraph-frequencies and local optimizations...

Despite differences in pronunciation, spelling, orthography etc.; there are fundamental limitations to the range of words that human beings find pronouncable. I don't have any hard scientific evidence of this (I'm not even a "proper" linguist) but based on my impressions as a speaker of English, French, German, Italian, Spanish and Russian (to very varying degrees of competency), I would suggest this: Most fortuitously for the US-Dvorak layout, English letter-frequency (perhaps due to the history of English as a sort of mongrel language) is somewhat typical - it represents a sort of middle road in some respects - between many other languages. So if we take Scott Horne's approach of creating keyboard layouts for other scripts based on phonetic equivalence with the US-Dvorak layout, then this will lead us to create layouts that are not totally unreasonable.

Of course you are going to have SOME PROBLEMS. For example, where to put all the accents, umlauts etc.? (We are just thinking of the LATIN script Horne-type Dvorak layout for now...) French and certain other languages require accents on the home row. Scandinavian languages require vowel digraphs on the home now. Germanic languages require umlauts on the home row. But that's if you do a 100% local optimization... It turns out (based on my usability testing) you can make a VERY GOOD approximation to local optimization, by making an overall-multilingual-frequency-based compromise. It's surprising how comfortable it is to use the AltGr with the vowels, in the flow of regular typing: once you get used to it, it becomes natural. Doing this also confers the bonus benefit that letter composition becomes more logical, and more accessible (I always follow the ergonomic principle explained in one of your other posts, by giving my end-users as many different ways of doing common tasks as possible: they can create umlaut-vowels either by using a dead-key or by AltGr + a vowel key position shifted onto the bottom row).

Finally, before I do some more testing on my experimental layout... Besides modern Russians; modern Germans, Scandinavians, Hungarians and even FRENCH people spend significant amounts of their time listening/speaking/reading/writing in a 2nd, 3rd, 4th or even 5th or 6th language! In central Europe, they'd never get on in life at all (or hold down a job in any kind of trade involving communication) unless they DID! Just don't tell this to the Académie française...

Matthew Slyman on 16 Apr 2013 6:02 AM:

RESULTS of my testing:

By using the correct VK_ entries (patched into my ".klc" file with the generally excellent EmEditor); I now have the correct shortcut behavior for my "Dvorak International Scientific" keyboard layout!

Remaining problems:

1. Keyboard layout is listed in "Add an input method" dialog as, "Keyboard". Not "Dvorak".

2. No "Preview" available!

Is there any way to fix either of these two very minor issues?

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day