ddotdash design notes

ddotdash is an experiment in morse code touchtyping for mobile phones. Stop laughing.

Design Goals

  1. less than 25% of screen area
  2. touchtyping -- use only muscle memory
  3. well-balanced left and right
  4. audio and visual feedback
  5. lowish learning curve
  6. 3 characters per second
  7. 3 or fewer button presses per character
  8. full latin-1 character set
  9. good support for punctuation and numbers

less than 25% of screen area

Most virtual mobile "qwerty" keyboards take up half of the screen. Can we cut that in half?

touchtyping -- use only muscle memory

The slowness and error rate of mobile qwerty is mainly due to the precise tapping involved. Novice users resort to hunt 'n peck. Expert users tend to use a combination of defocused vision and muscle memory. If you have large or flat fingers the tiny keys are a constant pain (see: Pointy-Fingered-Elf Conspiracy). So our "keys" should be at least 1cm square -- big enough to mash without needing to look.

well-balanced left and right

Standard Morse code has a bias towards codes with more dots than dashes, for obvious reasons. This means there is prime real-estate available on the dash side of the tree. But it also means a strong bias towards whichever side of the keyboad holds the dot buttons. That's a tricky problem.

audio and visual feedback

Visual feedback to tell you what character will be inserted, and what characters different key sequences will produce. Audio feedback can help associate movements with motion. (NB: mobile Safari does not repeat does not allow embedded audio. Audio files appear as large floating buttons which open quicktime player. A pity.)

lowish learning curve

A game-like feedback loop combining audible, visual and tactile clues along with the possibility of failure can greatly improve learning times (see: Magic Ink, Everything Bad is Good for You)

3 characters per second

That works out to about 30wpm.

3 or fewer button presses per character

Standard Morse codes can become ridiculous, epecially since tapping a glass square with the edge of your thumb is very different from an ergonomic, spring-loaded, telegraph arm. Distingushing from dits and dahs is non-trivial. And it's be a shame to waste the second thumb. The optimal keyboard seems to be 4 or 6 keys: [.] [..] [.-] [-] [--] and [-.]

full latin-1 character set

Morse code is variable-length, so codes up to six bits yield 2 + 4 + 8 + 16 + 32 + 64 = 126 possible characters. Throw in a Shift mode and you're up to 252. We have a separate space bar and Shift+space is tab. Latin-1 actually doesn't define codes between 7F and 9F so we've got plenty of headroom even if we throw in the control characters (00-1F).

good support for punctuation and numbers

These have always been a bugbear on mobile qwerty. Apple's number and symbol shifts are nice but still tiresome. If possible, define the left-brackets ( { [ < in terms of buttons on the left and right brackets on the right. Use easy unused sequences like [-.][-.][-.] for punctuation. If necessary, evict non-Roman characters like CH [--][--] in favor of punctuation.