Jay's complaints (read `suggestions') about the Agenda's HWR and on-screen keyboard

(`HWR' = `handwriting recognition', except where I use it as a verb, where it means `write'.)

Alternative handwriting recognition

There's a third-party project, described at http://agendawiki.com/wiki.pl?HWRProjectPage, to improve, extend, and/or replace the Agenda's built-in HWR and keyboard support. Among other useful things, there's an xmodmap binary which I hope to try soon. The alternate HWR project supports international (accented) characters, and a full-screen mode where no screen real-estate is reserved for HWR.

Handwriting recognition

The letter `e' is particularly frequent, and particularly hard to stroke. There are several unused simple strokes that could be used: vertical from bottom to top (inverse of `i'), and any of the diagonals except for the Return/comma stroke. I have very little trouble with any of the other characters, but I consistently have trouble with `e', and adding an optional straight-line variant would be a tremendous help.
I've recently discovered that I can get pretty consistent recognition of the `e' by drawing a stroke that looks a bit like an upside-down question mark, starting from the top, as in Figure 1 below. Also, I've found that `d' is recognized much more consistently (not mistaken for a `b') if I draw the initial vertical line at a significant slant, and leave the bottom somewhat open, as in Figure 2 below.
The backspace stroke doesn't work in the punctuation box. Also, it would be helpful if the slash (`/') stroke worked in the number and letter boxes as well as punctuation; it doesn't conflict with anything else, and it would make typing pathnames easier. Also useful would be a stroke for Tab.
Some punctuation isn't supported. What I find the lack of most annoying are curly braces (`{' and `}'), which are necessary for shell scripting.
No abbreviations mechanism like PalmOS' Grafitti shortcuts. Grafitti shortcuts made Grafitti pretty comfortable for me, even for composing email. (Things like `[shortcut]bcod' -> `[space]because of the[space]' and `[shortcut]:' -> `http://' save quite a bit of writing.)
No way I've found to HWR a control character (important for Terminal use) or a tab (ditto). This makes Emacs-like editors almost useless in HWR, and seriously hampers shell use. A solution would be to have a little Ctrl button underneath one of the HWR boxes, the way the Esc button is already there. (If the Agenda shipped with xmodmap, I'd see if I could turn one of the hardware shift buttons into a Control key.)
No on-screen cheat-sheet for HWR
No way, even from the on-screen keyboard, to enter ISO-8859-1 high-bit characters. (Actually, if I were Agenda, starting from scratch in 2001, I'd have used Unicode and UTF8 rather than ISO-8859-1, but that's another story. Yeah, there are political issues with it for East Asian languages, but for those languages you certainly can't argue ISO-8859-1 is better!)
No way to type certain ASCII characters, such as curly braces (`{', `}') and square brackets (`[', `]'). This is particularly annoying for writing shell scripts or other code.

Figure 1	Figure 2

consistent `e' stroke	consistent `d' stroke

On-screen keyboard app

When you bring up the keyboard app, whatever widget had the focus in the app you were using (which you just tapped in because you realized you needed to enter text) loses it. Since the keyboard app itself doesn't take keyboard focus, it seems like it would be very helpful to leave the keyboard focus in whatever widget had it before. I've usually already stroked three or four letters before I realize I'm not actually typing anywhere. :-)
When using the on-screen keyboard, inconvenient to cycle through HWR to switch back and forth between numbers/punctuation and letters.
It would be very useful to have `*' (the asterisk) available on the alphabetic keyboard, especially when using ash rather than bash, since `ls /u*/X*/l*' is a lot less writing than `ls /usr/X11R6/lib'.

Cross-application typing/event support

I had written

No OS-provided cut-and-paste support across applications.

but I was wrong. Enzo Dari pointed out to me that Ctrl-x, Ctrl-c, and Ctrl-v work in the PIM apps for cut, copy, and paste, respectively. Presumably this is obvious to people who use Windows. :-) Unfortunately, they don't work in rxvt (the Terminal application), but that's not as big a deal if you use bash. (I don't, because of the memory hit.) It would be a lot more intuitive, though, to have `Cut', `Copy', and `Paste' menu entries as well.

Suggestion for Terminal input

And I'll close with a suggestion for the Terminal application (or other applications that use keyboard input a lot more than they use mouse input, or that can constrain mouse input to a portion of their visible window): It would be great to have an invisible HWR area on the screen. HWR would work normally, just as if you had the HWR `keyboard' up, but it would not be drawn (or perhaps it would be drawn in very light grey), and it would not cause the Terminal to resize or obscure the text in the Terminal. I presume this would require the Terminal application to pass the mouse events to the HWR/keyboard process in some fashion, unless the keyboard app can somehow grab mouse events without being on top of the Terminal window. And the scrollbar would still need mouse events. But all in all, it would make the Terminal a lot more usable.

(Even better would be if this could work in landscape orientation. That would be about 40-60 columns visible, depending on font and scrollbar, which starts to let full-screen tty-based apps feel approximately normal.)

It sounds like the alternate HWR project mentioned at the top of this page supports both of these features! Hopefully Agenda will fold it into their distribution at some point.

last updated 2001.08.28