The second chapter of the book “The Power of PenPoint,”
PenPoint is unique in that it is the first operating system designed to
be driven primarily by a pen. Because of this, PenPoint includes many new
elements not found in traditional GUIs. This chapter will provide you with
an understanding of the PenPoint user interface, its design goals, how it
relates to traditional GUIs, and the unique ways PenPoint works with the
pen. It is neither a complete exposition of the interface nor a user manual.
As discussed in Chapter 1,
since mobile, pen-based computers are used
in different ways from desktop systems, they have different user interface
(UI) requirements than desktop PCs. Briefly stated, users of mobile, pen-based
systems require a user interface that is direct and intuitive, yet powerful
Early on, GO Corporation established goals that PenPoint’s UI would have to
|be based on coherent metaphors-the user’s conceptual model is the single
most important element in a good UI.
|fully exploit the pen-UIs would have to be rethought from the ground up,
if necessary, for the real potential of the pen to be unleashed.
|balance visual invitation and visual restraint – visual invitation is
important to encourage the user to touch an element on the screen. But it is
in tension with visual restraint: Good design is uncluttered, and PenPoint’s
users would be accustomed to using pens on uncluttered territory (blank sheets
|strike a balance among simplicity, consistency, and efficiency-that is, “easy
at the beginning, powerful at the end.” Real head room must exist
for users to grow more efficient in their use of PenPoint as they gain experience.
|permit a smooth transition for users of existing GUIs – many PenPoint users would
come from a background of using existing GUIs, and they might continue to
switch between the two systems. PenPoint would have to be “interoperable.”
It would therefore build upon and extend GUIs, not gratuitously reinvent every
UI technique imaginable.
PenPoint’s user interface is the design solution that meets these goals.
It is an immediately graspable user interface, even for the rank novice: Use
a pen for interaction, and organize your information as you would in a notebook.
The simplicity and directness of this user interface are compelling.
PenPoint and Traditional GUIs
If you have used a GUI, you will find many familiar concepts in PenPoint’s
user interface. User interaction techniques such as pointing to a graphics
screen (with a mouse in a traditional GUI, with the pen in PenPoint’s),
scrolling windows, and pull-down menus are all important foundations of
PenPoint. On the inside, application programmers will find that PenPoint has
a modern windowing and graphics subsystem that they must use to render their
screen display and that their applications must be structured in an event-driven
fashion, just as in desktop GUIs.
There is much that is unique about PenPoint’s user interface, and
this chapter’s purpose is to focus on the unique, not the familiar. We
will briefly introduce PenPoint’s more traditional elements and then discuss
those that are unique.
Windows and Their Frames
PenPoint applications run inside of a window and may in fact be sharing
the screen with other applications. These windows are called document frames and
can be resized and repositioned (except when they are a page in the Notebook,
as described later in this chapter). Figure 2-1 shows the standard elements of
a PenPoint document frame. As you can see, the standard elements of a window are there.
|Figure 2-1. Document Frame Showing Standard Elements|
Menus and Option Sheets
PenPoint uses Option Sheets in addition to pull-down menus. (See Figure 2-2).
Menus are typically used for verblike commands, Option Sheets for setting adjective-like
attributes of an object (such as font size). Option Sheets help avoid “menu
overload.” Furthermore, since attribute settings and commands are
different, placing the two in distinct portions of the user interface permits
PenPoint to provide optimum behavior for each. Commands should take effect right
away; consequently, menus dismiss (go away) as soon as you choose a command.
Options, however, are often set several at a time, and the same settings may be
applied to several objects in a row; therefore, Option Sheets allow the user to
set as many options as desired. The Apply button applies settings to the selected
object. The user may then change the selection and continue using the Option
Sheet. The Apply and Close button applies the settings and then dismisses the Option
Sheet. The Close button simply closes the sheet without affecting the selected object.
|Figure 2-2. Typical Option Sheet|
PenPoint includes a wide variety of the basic GUI controls such as buttons,
checklists, and multiple checklists. Of course, to echo the pen-based nature
of the system, PenPoint displays choice settings as check marks (as shown
in Figure 2-3).
|Figure 2-3. Choice Settings Displayed as Check Marks|
Some New Items
PenPoint’s UI Toolkit includes two items not normally found in other GUIs:
notebook tabs and writing pads.
Tabs are a user interface feature that simulates the tabs in a three-ring
binder (as shown in Figure 2-4). In a moment, we’ll describe how these
tabs are used in the notebook metaphor itself. But you can use the same tab
code to create navigational tools in your application (to switch between screens in
a form or sheets in a three-dimensional spreadsheet, for example).
|Figure 2-4. Divider Tab Simulation|
PenPoint’s tabs overlap when there are too many to display in a
single column. In this case, they can be directly manipulated with simple
flicks up and down of the pen tip. A flick left will uncover all the tabs.
Writing pads (see Figure 2-5)
are used to capture handwriting, translate
it into ASCII text, and allow simple editing. The larger writing pad in
Figure 2-5 is an embedded writing pad, while the smaller one is a pop-up edit pad.
|Figure 2-5. Two Types of Writing Pads|
Writing pads provide a natural area for handwriting, since they are similar
to lined paper. Because many people handwrite larger than the size of the
translated text on the screen, the user can adjust the dimensions of
the writing pads. A system preference setting allows the user to choose between
boxed and ruled styles of pads. Boxes require separation of characters
and may ensure higher recognition rates; ruled lines are simple lines on
which the user may write characters more closely together.
The user can cause a writing pad to appear in either of two ways. One
command creates an embedded pad, the other a pop-up pad. Embedded pads
are typically used for larger amounts of text. The application opens up space
around the embedded pad so that the preceding and succeeding context is
still visible while the user writes into the pad. Pop-up pads are
optimized for small amounts of text. They float at or near the location of
the command, and the application does not shift its display. They are great
for inserting, editing, or replacing up to a few words.
All writing pads are essentially the same object appearing with various default
sizes in response to user commands. They are resizable. After handwriting
into the pad, the user presses the OK button. This causes the translated text
to appear in the boxes. The user can write directly into these boxes to
correct any errors. In addition, space can be easily opened up, and characters
can be deleted with a simple gesture. The result is a reliable method
of entering handwriting and correcting it that is easy to learn and use. When
the user presses the OK button again on the translated (and corrected) text,
the pad will empty its text into the underlying application.
Applications can use writing-pad objects as an integral part of their user
interface. They may, for instance, embed pads into on-screen fields so the user
can simply place the pen into the field and begin writing.
Because writing pads provide a rich and comprehensive set of handwriting
entry styles, the result is that applications can simply reuse these PenPoint
objects for almost all their handwriting input. The user benefits because the
user interface for handwriting is consistent across a wide variety of applications.
PenPoint’s Notebook Metaphor
PenPoint’s notebook metaphor is based on the intuitive organizing principles
of pages in a notebook with sections, tabs, and a Table of Contents (see
Figure 2-6). All user data exists as pages.
|Figure 2-6. Notebook Table of Contents|
Pages are numbered in the top-right corner. The user can turn pages with
a tap or a flick of the pen tip on or near the page number. Page turns include
a special graphical effect that looks much like a real page turn.
Notebook tabs appear on the right-hand side of the Notebook and may be attached
to any page or section; touching a tab turns immediately to its location in
the Notebook. If there are more tabs than will fit on the screen, they overlap
and collapse together. Their overlapping can be controlled with flicks of the pen tip.
There are no file load or save commands, nor is there the concept of programs
existing distinct from program data files. Instead, each page of the Notebook
is called a “document” and is viewed by the user as a live
application instance that is always available just as the user last left it.
Behind the scenes, the PenPoint Application Framework associates data files with
installed application code and operating system processes. To the PenPoint
user, a page of the Notebook and a document are synonymous. To a PenPoint
programmer, documents are also synonymous with “application instance.” (In
this book, we’ll use the latter term since our audience is technical.)
Pages may be grouped into sections. Sections may also contain other sections;
arbitrary hierarchies may therefore be created. The first page of the Notebook is
a Table of Contents that looks and operates likes its book equivalent. In
the Table of Contents, the pages and sections are displayed as an indented
outline. Sections may be collapsed and expanded as in an outline processor.
Touching a page number in the Table of Contents turns to that page. All
contents of the Notebook are always visible from the Table of Contents, and pages
may be easily created, moved, copied, deleted, and otherwise manipulated
from that point. Entire sections may be transferred in and out of the
Notebook just as easily as individual pages.
In Figure 2-7, the user has turned to a text document page. When the
page-turning command was given, PenPoint did the following steps:
|Figure 2-7. Display after User Turns to a Text Document Page|
|cleared the screen and displayed a page-turn effect lasting less than a second
|created a process and application object for the destination page being turned to
|sent a message to the destination application object to restore its saved state
from the file system
|sent a message to the destination application object to display itself on the screen
In the background, now that the user is able to view and interact with data
on the destination page, PenPoint sends messages to the original page’s
application to file its data. PenPoint then terminates the process behind the
As you can see from this sequence of steps, it is the PenPoint operating system
that performs the clerical bookkeeping steps of starting and stopping processes
(running applications) and of loading and saving application data. Users simply move
from page to page and always see their data just as they last left it:
scrolled to exactly the same location and with the application seeming to
be still running. In reality, because PenPoint Notebooks can contain hundreds
or thousands of pages, PenPoint automatically starts and stops processes behind
the scenes for the user. Otherwise, if PenPoint actually kept these off-page
processes running, memory would be consumed quickly.
The Notebook metaphor is designed for mobile users who are most often communicating
with other users. Mobile users must be able to focus their attention elsewhere
than on the computer. The Notebook metaphor supports a quick-reference style of
access in which the user must be able to find information with just a few taps of the pen.
Benefits of the Notebook Metaphor
The notebook metaphor stands in stark contrast to the high level of concentration
the desktop metaphor requires. This is not surprising: The desktop metaphor was
designed for desktop users who are alone with the personal computer and
therefore free to concentrate their full attention on the computer. The user
of a desktop system is assumed to be doing nothing else while operating the
computer. The user of a pen-based, mobile system, on the other hand, may
be able to devote only a small portion of conscious attention to the computer.
The notebook metaphor provides these benefits
|It is a physically familiar (like a real notebook) and stable user model
(pages and sections remain in the order and state the user last left them in).
|Users need not learn about the unnecessarily technical-distinction between
programs and data files, because user data in the Notebook simply exists as
live, running documents; there are no file load or save commands to learn.
|Because it is a stable model, users can employ their spatial memory of
the unique ordering of their pages and sections to help find and organize
|The Table of Contents provides an instant overview of Notebook contents; all
organizational tasks (such as create, delete, move, rename, and so forth)
and navigational tasks (page turns) can be performed from the Table of Contents.
|Tabs on any page or section allow the user to maintain a set of
documents so that they are instantly accessible with a single tap.
|Sections allow hierarchies to be formed: According to the user’s preference
and style, the Notebook may either be a simple flat collection of pages
with no sections or a rich and deep hierarchical collection of sections within sections.
|The user can move sequentially through the Notebook simply by turning pages.
|The user can move in random order through the Notebook either by turning
to a Table of Contents and then turning to any other page or by touching on
an attached tab or using Goto buttons for frequently traveled paths. (Note that
the terms Goto buttons and hyperlinks mean the same thing.)
At the bottom of the PenPoint screen is a Bookshelf area in which systemwide
objects and resources are displayed as icons. You can think of the Bookshelf
as the meta-area in which the Notebook is rooted, or resides.
PenPoint’s standard Bookshelf includes icons for these objects
|on-line help system
|In Box and Out Box
|the selected Notebook
A tap of the pen on any of these objects opens it on the screen, floating
over the Notebook.
The power of object-oriented programming is evidenced in PenPoint’s
use of the notebook metaphor in several of these subsystems: The stationery,
reference help, In Box, and Out Box all use floating instances of small,
recursive Notebooks for their user interfaces. The user is able to use
the familiar concepts of a Table of Contents, pages, and sections to
browse through these system services, and PenPoint is able to achieve
tremendous code reuse.
The on-line help system provides context-sensitive and reference-style help screens.
System preferences provide the user with configuration options such as the
choice between writing in all uppercase or mixed upper- and lowercase,
writing-pad styles, system font, portrait or landscape screen orientation,
time and date, and whether to enable sound. The user can also see memory usage
The Tools Palette provides a pop-up window with icons for a variety of
system accessories and tools such as clocks, calculators, and, importantly,
PenPoint’s handwriting training program.
The Stationery Notebook provides a place for the user (as well as installed
applications) to store copies of documents they would like to use as
templates. This provides for a standardized form of application templates to be
fully integrated with PenPoint’s creation user interface.
The Disk Manager allows the user to browse and transfer files to and from
external disk volumes. These may be floppy disks, hard disks, desktop PC
and Macintosh computers, or volumes on network servers. The Disk Manager user
interface is based on the same code as the Notebook’s Table of Contents
and provides a similar outline view that uses the identical core gestures for
all transfer and manipulation of external files.
The software keyboard is a small pop-up image of a keyboard that the user
may tap with the pen tip when a physical keyboard is absent and the user
would prefer to not handwrite.
The Installer manages all installed applications, listing them and their memory
consumption for the user.
The In Box and Out Box queue up incoming and outgoing data transfer operations
until a suitable connection is available (see Chapter 16 for more information
The current Notebook fills the screen but is not the root of the PenPoint
world. Therefore, an icon representing the current Notebook sits on the Bookshelf
alongside the other icons (in the default configuration, it is scrolled out of view).
Because PenPoint ensures that the Notebook contains only user data (and not system
objects), advanced users may want to manage multiple Notebooks in a single PenPoint
machine. These Notebooks would be created by the user or loaded from disk,
and the user would switch between them by choosing their icons on the
Bookshelf. There is nothing to prevent a Notebook from residing on disk.
Besides adding Notebooks to the Bookshelf, the user can also place other
objects such as documents and hyperlink buttons (described later in this
chapter) there. As the Bookshelf fills up, it will automatically wrap the
icons to fill into row order. The bottom of the Notebook has a resize handle
so the user may draw it up to uncover as many rows of icons as the
Gestures: The Pen Builds on the Mouse
The pen builds upon the heritage of the mouse as a pointing device. As
we discussed earlier in this chapter, PenPoint is based on many
traditional GUI principles, including the principle that much of the GUI
screen is responsive to pointing operations. Pointing is much easier with the
pen than with the mouse. With the mouse, you must position the cursor to
the correct location and then click the mouse button. These are skills that
must be learned. With the pen you simply tap on the screen.
But the pen extends well beyond the mouse’s function as a pointing device.
Since people can write and draw well with the pen, it can be used for many more
classes of operations than can the mouse. In fact, PenPoint uses the pen
as its primary input device; it is the only input device the user ever needs
to learn or use.
In PenPoint, the pen is used for pointing, data entry, and gesture commands.
Of all input devices, it is the only one that can be used for all three.
The mouse cannot, because it is too difficult to handwrite with a mouse. The
keyboard cannot, because it is difficult to point with cursor keys and you cannot
draw gesture commands with a keyboard. Even when voice recognition is sufficiently
perfected for unconstrained high-volume data entry and command issuance, it
will still be a horrible pointing device. (Imagine controlling your computer through
voice commands without a pointing device like the pen in hand: “Delete
that word... no, not that one, two to the left... OK, now, see that word “abject”
four lines up? I want you to move it to just before the ...”.)
Because the pen unifies all these input modalities into a single, natural tool,
it is the ideal primary input device for a computer. Keyboards (covered later
in this chapter) and voice recognition become excellent adjuncts to the pen,
to be used in special situations.
Gestures as Commands
The most interesting and useful capability of the pen is not the handwriting
you can perform with it, but the gesture commands you can issue with it.
Gesture commands specify in a single step both a command and the target of
the command. With mouse-based systems, the user must always select the operand
object, then select the command verb. With the pen, users simply draw the
command directly over the intended operand object.
|Figure 2-8. Caret Gesture to Request Writing Space|
The pen is so powerful that intensive editing and data entry tasks can
be performed entirely with it. In Figure
2-8, the user draws a small
caret gesture to request that a “gap” be opened up to write into.
In response, the text opens up a gap and fills it with a writing-pad object
(one of many standard PenPoint support objects). Figure 2-9 shows the
resulting writing pad with some typical hand printing that PenPoint recognizes.
While the user handprints, PenPoint performs the recognition process in the
background, so that the resulting text can be displayed nearly instantly
after the user closes the writing pad. Upon closing, the resulting ASCII text
is passed to the application.
|Figure 2-9. Writing Pad Appears in Response to Gesture|
Under PenPoint, the location of a gesture controls its intended meaning.
For instance, when the letter “O” is drawn in a handwriting area,
it is translated into ASCII 79 (a capital “O”), but when it’s
drawn over application data such as a word, it is translated into the Edit
command. When the “O” is drawn into an object-oriented drawing
program, it is translated into the command to create a circle object (see
figures 2-10 and
2-11). Such location-specific gestures provide an
intuitive “do what I mean” style of interface that is free of the
confusing modes that arise when a mouse is used where a pen would be more natural.
|Figure 2-10. User Draws a Circle Gesture|
Ideas in Conflict
Even though the pen builds on the heritage of the mouse as a
pointing device, it is important to note that the two devices mix together about
as well as oil and water. The mouse requires an on-screen cursor; the pen
abhors this. The mouse does not trail ink on the screen; the pen requires this.
|Figure 2-11. Drawing Program Creates Circle Shape in Response to Gesture|
As a result of these fundamental conflicts, unchanged mouse-based GUI
applications require a mouse cursor. If these applications are running on
the same machine as pen-based applications, the user will be confronted with the
difficult situation of having a pen with a button on it to switch the pen
between mouse mode and pen mode. The user would have to understand the nature
of every window on the screen and ensure the pen was in the correct mode
before touching it to the screen.
Standard Gesture Language
PenPoint provides a standard, rich gestural language based on intuition about
pen editing marks. The heart of the gestural user interface is a set of
core gestures shown in Figure 2-12. These gestures work consistently across
all applications, providing common commands such as Select, Delete, Move,
Copy, Options, and Help. PenPoint provides dozens of additional gestures for
application-specific commands (for example, the same letter “B” that
applies a style of boldface when drawn in a word processor will toggle
document borders on and off if drawn on the title bar of a document).
|Figure 2-12. Core Gestures in PenPoint|
GO has found that a well-designed gesture is highly mnemonic. The choice
of gestures should be driven by two key factors
They should leverage our society’s “collective unconscious”
regarding editing marks; for example, scratch-out and pigtail marks are
intuitive deletion gestures.
They must be easy to draw and make; GO’s user research has found that
many multistroke gestures (those in which the pen tip is typically lifted at
least once during drawing) cause users difficulty.
While virtually all commands and operations in PenPoint are available through menus
and Option Sheets so that users can easily find them, the most frequently
used commands have gesture equivalents. Because these are so direct and
efficient, most users will use them rather than other approaches.
Using the Pen for Data Entry
PenPoint includes a powerful handwriting recognition (HWX) subsystem. This
system is available to all applications. In addition, it is used by a number
of PenPoint objects (such as the writing pads mentioned previously) that are
in turn available to all PenPoint applications.
The initial version of PenPoint is shipped with a HWX system developed
entirely by GO Corporation that has the following characteristics:
|recognizes neatly printed, mixed upper- and lowercase letters, numerals, and punctuation
|gives the user the option of writing into character boxes or on ruled lines
|tolerates characters that overlap or touch
|recognizes characters independently of stroke and time order
|accommodates several users with or without training.
PenPoint supports these features on an impressive list of naturally shaped
characters at very high recognition rates, even when the user is writing
random English text. Typical word accuracy rates are 80 percent or better,
which is equivalent to character accuracy rates of 90 to 97 percent. For
more information on the HWX system see Chapter 13; for more information on
evaluating HWX systems see Appendix C.
Under PenPoint, the pen is clearly a respectable data entry device. With
time, it will only get better, because PenPoint’s HWX is replaceable. HWX
APIs exist as standard programming interfaces regardless of what HWX is currently
installed. Therefore, PenPoint’s algorithms can be continuously improved
without disturbing the growing base of applications.
PenPoint’s HWX subsystem is replaceable, allowing replacement of
GO Corporation’s current English-language HWX with engines developed by third
parties. This supports placement of PenPoint into foreign markets such as
Japan, but it also guarantees that the world’s best HWX can be available
within PenPoint. Several third-party efforts are already underway to port
other HWX technology into PenPoint.
With time, PenPoint will support HWX systems that deliver accuracy rates
higher than today’s and tolerate messier or cursive handwriting. HWX is
a CPU-intensive task, and a better job can typically be done by
expending more processor time. GO Corporation’s algorithms have been
carefully designed to run in real time on current-generation hardware. As
faster processors become available, more ambitious HWX goals can be set.
Furthermore, as the PenPoint market grows, the market for HWX engines will
grow and encourage entrepreneurial development.
PenPoint also supports keyboards for high-volume data entry. When users
are working at a table or desk and they know how to type and they have
a physical keyboard available, nothing beats the keyboard. But it’s
important to point out that where other operating systems tend to use the
keyboard for everything (for example, all commands must be issuable from the
keyboard) and the mouse for some things, PenPoint inverts this former
primacy of the keyboard; in PenPoint every user action can be done with
the pen and the keyboard is supported chiefly for its excellence at high-volume
data entry. That is, PenPoint’s user interface guidelines do not require
the use of Alt key combinations, function keys, or the ESC key.
Besides the notebook metaphor and gestures, PenPoint’s user interface contains
a number of other features not normally found in a traditional GUI.
|a non-traditional move/copy model
|the Stationery Notebook
|scroll margins and scrolling with gestures
|Embedded Document Architecture
Direct Move and Copy
Move and copy operations in traditional GUIs are based on a clipboard model
in which the user must first copy or cut data to an invisible clipboard
and then issue another command to paste the data into the destination
application. In PenPoint, the user employs gestures that immediately
initiate a direct manipulation drag and drop move/copy user interface.
(See Chapter 8 for a more detailed description of how this portion of the
user interface is implemented.) Move and copy work within individual
applications, across application boundaries, and across pages in the Notebook.
PenPoint’s Stationery Notebook unifies the user interface for creating new
blank instances of applications with the user interface for creating copies
of application template documents. It is extensible by applications,
which can bring templates with them at installation time, and by users,
who may add their own templates at any time. All templates (including a blank
one for the creation of blank application instances) are stored in
the Stationery Notebook. An entry in this Notebook with a check mark next
to it will then appear in the Stationery menu, which is a simple menu
that appears in the Table of Contents in response to the insertion gesture.
PenPoint contains relatively traditional scroll bars with up and down
arrows and a scroll handle that is draggable and indicates your current position
in the file. These scroll bars are called scroll margins because they
also contain a thin margin into which you can draw flick gestures.
These are simple up and down flicks (in a vertical scroll margin) or
left and right flicks (in a horizontal scroll margin).
The scroll margins are infrequently used, however, because users may draw
the same scroll flicks in the application window itself. The result is
direct manipulation at its best: To scroll a line to the top of the
window just place the pen tip near it and draw a quick little flick up. Scrolling via
flick gestures is much more efficient than scroll bars because the placement of the
pen tip can be very imprecise and casual; with scroll bars, the placement
of the pen tip (or mouse cursor) must be precise.
The cork margin is a unique standard part of every PenPoint document frame
(although it is turned off by default). It is a simple little border area at
the bottom of the document frame (see Figure
2-13) that can contain
any PenPoint object. It is called the cork margin because you “stick”
things there in a fashion similar to a small cork bulletin board. In
fact, the cork margin’s capabilities as a general-purpose repository are
similar to the Bookshelf, which we previously described. Both cork margins
and the Bookshelf can contain hyperlink buttons, closed documents (appearing as
icons), and other PenPoint objects.
|Figure 2-13. Cork Margin at Bottom of Page|
Because the cork margin is attached to a document frame, it goes wherever
the document goes. You might put several hyperlink buttons in the cork
margin that point to various locations in the document that you want
to mark. Because the Bookshelf is always at the bottom of the screen,
it is global. In essence, the cork margin serves as a local buffer for
objects, and the Bookshelf as a global buffer.
Embedded Document Architecture
One of PenPoint’s most impressive technical capabilities is its Embedded
Document Architecture, in which live applications may be placed inside
each other to produce true compound documents. (This book devotes Chapter 8
to this topic.) While complex software technology is required to implement
this capability, to the user the embedding user interface is straightforward.
To create a document inside of another, the user simply opens the Stationery
menu inside of the host document and chooses the new document type, just
as he or she normally would. Embedded documents may be closed to a small
icon (in which case the application is no longer running) or they may be
open. When the document is open, the user has full control through standard
document Option Sheet settings over whether the document menu bar,
scroll bar, and borders are on or off.
PenPoint includes hyperlink buttons as a first-class, integral part of the
operating system. The user creates these links by selecting the target for
navigation and drawing a simple gesture at the location where the hyperlink
button should be placed. PenPoint creates a button that points directly to
the selected destination. Hyperlink buttons can point to any page in the
Notebook or to locations within pages. When a hyperlink button is pressed,
PenPoint creates an automatic page turn to the destination page. The location
within the destination page is selected and scrolled into view. Hyperlink
buttons are correctly preserved across all filing and other data transfer operations.
Pages in the Notebook may be floated by the user double-tapping on the page
number in the Table of Contents (or on a tab or hyperlink button pointing to
the page). A single tap on any of these goes to the page while a double
tap floats the page. You can think of floating pages as being temporarily “torn
out” of the Notebook, while remembering their original location, to
which they return when the floater is closed.
Floating gives PenPoint a general overlapping window model for those users and situations
in which this is appropriate. In other GUIs, overlapping windows are the
only organizational style, so users simply must learn to use it. In PenPoint,
this style is treated as an advanced approach; users can confine their systems to
the more intuitive page-turning model.
PenPoint includes an extensive set of user interfaces for connectivity. Because
data transfer is so integral to mobile, pen-based computers, PenPoint allows documents
being transferred to queue up in the In Box and Out Box. These services
fill and empty when the appropriate communications connections (for instance,
a connection to a desktop PC or network) are available (see Chapter
16 for more information). Both the In Box and Out Box use small floating
Notebooks as their user interfaces, allowing the user to employ the familiar
organizational power of pages, sections, and the Table of Contents.
The Send command in PenPoint is available from within every application to
send a copy of that document as electronic mail or facsimile (if the appropriate
transfer services are installed). The Send command brings up a standard
addressing user interface that works with a systemwide Send List (a form of
address book for addresses and phone numbers), and the pending transfer operation
is then entered into the Out Box.
User Interface Consistency
PenPoint encourages application user interfaces to be consistent with one
another in several areas. In our previous discussion of gestures, we pointed
out the concept of a core set of approximately one dozen gestures that
all applications implement in a consistent fashion. In addition, there
is a set of Standard Application Menus (SAMs), commands, and Option Sheets
that all applications must implement. (As you may have guessed, the
Application Framework provides default implementations of these features that
are sufficient for most applications.)
SAMS specifies two required menus: a Document menu and an Edit menu. The
Document menu contains (at least) Checkpoint, Revert, Print, Print Setup,
Send, and About commands. The Edit menu contains (at least) Undo, Select All,
Options, Move, Copy, Delete, Find, and Spell. In addition, SAMS provides
standard document Option Sheets that provide option cards to describe document
title and information, access controls, and application information.
To ensure appropriate application UI consistency, the PenPoint Software
Developer’s Kit includes UI Guidelines that specify the full set
of consistency requirements.
This chapter has looked at the PenPoint user interface primarily from the
user’s perspective. While this interface shares many features with existing graphical
user interfaces (GUIs), PenPoint incorporates some new ideas, including
notebook tabs for navigation among documents and writing pads for
insertion of handwritten text.
As we have seen, PenPoint is organized around the concept of a
notebook, including sections, tabs, and a Table of Contents. PenPoint also
includes a Bookshelf area along the bottom of the notebook where system-wide
objects can be stored for easy access regardless of where in the notebook
the user is working.
We have looked at the core gestures and handwriting recognition techniques
that make up one of PenPoint’s most unique and visible user interface
elements. We have noted that the pen is not intended for high-volume data
entry and that PenPoint therefore also supports keyboard data input.