GroupStorm SketchClient is a hardware and software setup that allows a user to quickly and effortlessly send a freehand sketch to the PostBrainstorm system for display on the Mural (or other PostBrainstorm output device.)
SketchClient's components are the control computer, the Wacom tablet, and the Sketcher program.
All of the user's interaction with the system are through the Wacom tablet and through three of the tablet's macro buttons, which are labeled "Send & Clear", "Send", and "Clear". At no point does the user interact with the computer or software itself; there is no monitor as part of this setup.
To make a drawing, the user places a piece of paper on the tablet's writing area, and draws using a Wacom inking stylus. The user's stroke inputs are recorded by the Sketcher program. When the user is finished, the user presses the "Send & Clear" button at the top of tablet, and replaces the piece of paper with a clean sheet in preparation for the next drawing.
The "Send & Clear" button prompts the Sketcher program to compile its recorded stroke inputs into a form usable by PostBrainstorm. It then sends the sketch to PostBrainstorm for display. It then clears its memory of stroke data in preparation for a new user drawing.
While making a drawing, a user may wish to discard his current sketch without sending it to the main board. In that case he presses the "Clear" button, which prompts the Sketcher program to clear its memory of stroke data in preparation for a new user drawing. The "Clear" button does not send any information to PostBrainstorm.
While making a drawing, a user may wish to send a drawing to PostBrainstorm without subsequently discarding the sketch information, for example in order to illustrate a work-in-progress. In that case he presses the "Send" button, which prompts the Sketcher program to compile its recorded stroke inputs into a form usable by PostBrainstorm. It then sends the sketch to PostBrainstorm for display. The "Send" button does not clear the Sketcher program's accumulated input, which allows the user to continue to edit the current sketch.
(Rationale for a separate "Send & Clear" button: The most typical user action will be to make quick sketches and immediately proceed to the next drawing, in which case hitting one button is faster than two. Also, if a user "Sends" and forgets to hit "Clear", the resulting sketch will be a garbled combination of old and new, and certainly not what is desired. Furthermore, we don't want users to get into a habit of always hitting "Clear" immediately after hitting "Send", because then on those occasions when a user sends data up with the intention of continuing to edit it, it is all too easy to reflexively clear it.)
The control computer will initially be a Mac OS X-based computer, for no other reason than that it's our preferred development platform. Ultimately, the control computer could be any platform capable of running Java2 applications, capable of accepting inputs from a USB tablet, and capable of interacting with the Event Heap and other components of the iRoom network.
The Sketcher Application will be written in Java, using the most current and/or convenient versions of the Java API's. In order to record pressure, angle, and related information from the Wacom tablet, it will likely prove necessary to write a translation layer utilizing the JNI API. The translation layer will have to be platform-specific; this is an unfortunate side-effect of the fact that the Wacom drivers are themselves platform-specific.
The Sketcher Application will communicate with the PostBrainstorm system using the Event Heap in the same way that Brian's iRoomApplet does. That applet can send a JPEG image to be displayed on the Mural. Initially, we will do the same; that is, the Sketcher Application will create a JPEG depiction of the user's stroke data, and send it to the Mural.
As we further refine Sketcher, we will want to represent the user's stroke data in some sort of vector format (for ease of scaling and manipulation, as well as for the smaller size associated with vector data vs. image data.) We are considering using the SVG (Scaleable Vector Graphics) format for this data. This would require modifying PostBrainstorm so that it can display an SVG image.
GroupStorm SketchClient poses some unusual difficulties, in that it includes no way for the Sketcher Application to give any direct feedback to the user. While this is sort of the point – the system is intended to be as simple and straightforward as possible – it poses the following problem scenario: There is no way for the user to tell whether or not the Sketcher Application has any accumulated stroke input. If a user draws a sketch while the Sketcher Application still has some older stroke input "lying around", the resulting sketch will not appear as desired. A solution is to press "Clear" whenever you start a new sketch, in order to clear out any old data, but this could result in a cautious user hitting "Clear" a great many times, "to be sure it worked". This isn't very elegant, and it undermines the user's belief that this system actually works. One solution would be to mount an LED light on the tablet that is "on" while there is some amount of accumulated stroke data, and "off" otherwise, to give quick and immediate feedback as to the program's state. A problem with this is that it may requre far more engineering than it's worth. A USB LED perhaps?
A PL-500 based version of GroupStorm SketchClient could incorporate a variety of other features found in conventional drawing applications, including erasers, multiple colors, and multiple brush shapes. Further, it could incorporate the ability to drag-and-drop images and other files into the Sketch, which would then be composited into the information sent to the PostBrainstorm system.
One of the future projects that has been mentioned is to do a platform-independent rewrite of the PostBrainstorm system. Current versions of PostBrainstorm use OpenGL or its variants; If SVG is promising enough, it might serve as an excellent core component of a future version.
Jan Borchers <borchers@stanford.edu> • Last modified Sep 7, 2001 6:38 PM