Ideas about a command-mode character (ESC)
I have been thinking about dasher while reading a book about Open Source.
I suggest the following plan for "control while dashing"
1. Have an option to add an "ESC" character to the alphabet.
a) in all contexts
b) only in post-punctuation contexts
Option b means that the ESC character has very near zero
probability when the latest character is a..zA..Z
or any other letter in that class.
In other contexts, the ESC character is given a probability
at least pESCmin (eg 1/100), and possibly larger, depending
on how strong the predns are in the current context.
If the lang model makes a strong prediction (eg it knows what
word is coming next) then we don't want to spoil this
predn by filling the screen with ESC. But in a bland
context, maybe as much as 1/15 could be ESC.
2. Show the ESC character by a special colour box,
located at the top of the alphabet before a.
Note, this will solve the aaaa problem, perhaps.
3. Inside the ESC box, provide a set of equal probability boxes
emulating a menu of control options.
If necessary have some options lead to sub options.
Have the control options be identical to the optins
available by clicking buttons off the dasher canvas.
For crucial actions such as "close dasher", "new file",
have a confirm dialog, "yes"/"no", all implemented
by regular dashing dynamics.
For all appropriate menus, have the bottom item in the
list be an "abort command mode" option, coloured a special
colour, which takes one back to writing in the
Discussion of when text is committed to the text box
djcm to djw:
Iain was asking whether there is any particular reason for
the distinction between the two boundaries in pocketPC dasher -
text that has fallen off the LHS goes into the text box when writing;
when not writing, text to the left of halfway goes in the text box. I
am used to this and it doesn't bother me, but Iain was suggesting an
alternate procedure of putting stuff in the text box when it has passed
halfway and corresponds to a box that contains the crosshair.
My guess is that your rationale was to only put stuff in the text box
has been definitely committed. (except when the user stops writing)
This probably is a good rationale, since otherwise users will start to
about thinking they have written something and trying to undo it when
in fact they simply clipped a big box on the way to their intended
It might be helpful if you told us your thinking on this.
A possible problem with the LHS rule is that if the user wishes to
use a large left-hand context on screen (as can be done in 168 with the
controls) then there is a big delay before stuff goes to the text box.
djw to djcm:
I intended that version 2 should always display the text upto the
crosshair and not just dump it out when you lift the pen. See version
168 for the behaviour I prefer.
However, the LHS is significant for me because that's when I add
characters to the language model (also where I prune the data structure
but that's just implementation). If you add what ever appears under the
cross-hair to the LM then you end up feeding part-gibberish into it.
But my method of adding to the LM can also break if you are allowed to
zoom out or edit text. Removing stuff from the LM would be very tedious.
So there are some things to think about.
How Dasher would operate as a conventinal keyboard is not
straightforward. E.g. if you write
into your shell, when does it execute the command? What if I zoom out -
can I undo my command!!!
djcm to djw:
I would suggest this:
whenever there is a character which is the final character
in a command of some sort (eg in rm * )
this character should contain within it a special coloured
sub-square, of size (say) 1/3, padded on either side by
two alternate "abort" squares, so that the user is unlikely to
accidentally pass the special "do it!" subsquare, which is central,
over the crosshair.
The "abort" squares could be functionless squares that just
act as padding, or they could have an appropriate function (equiv to C-C, say)