Kevin Fisher wrote:

> Squeak is very much mouse-oriented by default.

> [We] should ask just _what_ the key difference between a pen-based
> and mouse-based environment really is.....this could spark some
> interesting debate.. :)

I agree, Kevin.  Hence this message, in which I attempt to summarize the
collected thoughts posted recently to date, and provide a hook for
discussion.

> Well, in my limited experience with things I can say that Squeak
> certainly offers a fantastic platform to -build- a totally pen-based
> interface..the building-blocks are certainly there.

Again, I agree.  Genie gives every apperance of being completely soft, but
is too complex and un-configured, out of the box, for the typical user.
More polish and better default behavior seems called for, to which Nathanael
Schärli adds that he has gotten a lot of feedback regarding Genie:

> Most [users] said that it was not so easy to understand how to
> configure Genie and get started. One of Genie's design goals
> is flexibility. The user should be able to adapt Genie to his/her
> needs: Creating individual gesture dictionaries, assigning them
> to morphs and using them on different platforms. Although, these
> options and possibilities are very nice for an experienced user,
> they seem to be quite hard to understand and kind of confusing for
> many new users. I have the impression that the reason for that is
> mainly a lack of documentation and that the following would help:

> - An easy to understand (and not so technical) introduction/tutorial
>   that illustrates the basic features with some concrete examples.
> - Better default/example dictionaries
> - Some UI improvements

> I have been started to work on some of these issues, but I haven't
> had the time to finish them yet. Until then, please feel free to ask
> if you have any particular question about Genie.

Nathanael, perhaps you would start a Swiki page for Genie and stylus-centric
UI on Squeak.org?  :-)  You could post links to your work-in-progress there,
and the Swiki page would provide a focal point for people interested in
stylus-centric UI.

I had kicked off this sub-thread on mouse vs stylus-centric UI issues by
commenting, in reply to someone inquiring about using Squeak on tablet PCs,
that:

> Based upon my experiences to-date with the iPAQ, I'd say that Squeak UI
> needs more work on stylus-centric devices before it is entirely usable on
a
> device that lacks a multi-button mouse and/or a keyboard with which to
> simulate the effect.  Right now there are too many things that require a
> 3-button mouse and/or keyboard to manipulate the UI.  Images with Genie
just
> don't seem to be mature enough, yet.  If someone is aware of some useful
> change sets, please let me know.

Kevin Fisher commented that:

> [Using] the pen in the default setup is more akin to "simulating"
> a mouse, since the standard Squeak environment is focused more
> towards mice (with the exception of Genie, of course). I don't
> think there have been any changesets that will convert the
> standard Squeak environment into a totally pen-focused environment (yet!).

The "yet!" is the part that we should focus upon, and talk about what
changes should be made to improve a stylus-centric Squeak UI.  Dan Ingalls
replied that there are two issues with respect to the current Squeak UI:

> One is how to do it all with one mouse button, and I think that's
> not so hard.  The other is how to do it without pen-up tracking.
> This is also do-able, but a number of places in Squeak need to be
> rethought in this regard.

Ned Konz has kindly posted a version of the code mentioned by Dan Ingalls to
change mouse handling to require holding a button to register mouse events,
so as to simulate a stylus with a mouse.  This should make it easier to
experiment with stylus-centric UI changes.

I started this note with Kevin's suggestion that we inquire into what are
the key differences between a mouse-centric UI, and a stylus-centric UI.
So?  What are they?  The following list of observations is certainly neither
original nor brilliant, but it should serve as a discussion point:

- As observed by Dan Ingalls, pressure on the stylus is treated as mouse
down.  Software accepts a stylus press as both positioning and mouse down,
stylus movement as mouse-move with mouse-down, and releasing the stylus as
mouse-up.

- A completely soft gesture reader is nice, but a standard set of gestures
should be pre-configured as part of the basic distribution; corporations and
individuals can always replace them with their own gesture dictionaries.
The standard gestures (in concert with standard decorations/controls) should
include everything necessary to control Squeak; it should not be necessary
to use any other input device to control Squeak.

- Standard gestures need to be easily distinguished from one another, since
they need to operate without, or prior to, training.

- Easily added pre-configured gesture dictionaries for block characters and
graffiti could be provided for when users don't have or want to use standard
input controls, such as the WinCE SIP.

- A gesture engine should not be exclusive, and should co-exist with other
possible character recognizers, perhaps owning specific screen regions, such
as a Smalltalk version of the NYU Quikwriting input scheme:
http://mrl.nyu.edu/projects/quikwriting/.  [Nathanael, is Genie soft enough
to handle the quikwriting layout directly?]

- UI input UNDO needs to be supported (duh! :-)).

- The UI must be able to handle such UI behavior as press-and-hold, as
distinguished from a tap or tap-and-move.

- Rather than have multiple menus, each on a different mouse button, perhaps
a menu could be configured such the pop-up has the most common items USED by
the user (initialized with some default list), with other items under
sub-menus.

- A gesture browser should start with at least the ease of use of the
Newton/CalliGrapher control panel, and then extend it to allow complete edit
control of all gestures.  Said browser should allow EASY review of active
gesture dictionaries, as well as adding/removing gesture dictionaries from
the both the active and available sets.

All of the above notwidthstanding, the UI should be SIMPLE and ELEGANT.  And
it should work on today's screen limited PocketPCs (min 320x240 color
resolution).  :-)

This is just a starting point for discussion.

	--- Noel