Thomas Erickson
Advanced Technology, Apple Computer, Inc.
(now at) snowfall@acm.org
This article describes the design and use of a personal electronic notebook. The findings provide a useful data point for those interested in the issue of how to design highly customizable systems for managing personal information. After a description of the notebook's interface and the usage practices that have co-evolved with the interface, I discuss some of the features which have made the notebook useful over the long term, and trends in the evolution of its design.
Electronic notebooks, personal information management, customization, tailoring, longitudinal study, reflective analysis, co-evolution of design and practice
Notebooks are a well known tool for those involved in practices which
involve observation, reflection, analysis, and synthesis. John-Steiner,
in her wide- ranging study of "experienced thinkers" [6], observes
that one of the central challenges of creative work is the capture of images
and other forms of "condensed thought," and the development of
this private language into public, expressive language. She notes the frequent
use of notebooks for this purpose, not only by writers and scientists, but
by painters, composers, and choreographers.
Given the well recognized role of such personal notebooks in intellectual
and artistic endeavors, it is rather surprising that there are only a few
examples of computer-based applications that are designed specifically to
act as personal notebooks. These include Notes [9], a physician's notebook
[1], a prototype of a biologist's notebook [10] and NoteCards [5]. If the
constraints are relaxed to allow collaborative systems, other examples appear,
such as the Virtual Notebook System(tm) [4, 11], and Lotus Notes® [3].
We will not consider systems tailored to support specific tasks, such as
capturing and elaborating on design rationale (e.g., [2, 13]); their degree
of structure and formality make them quite different from systems directed
towards the easy capture, management, and transformation of personal information
which is our focus of interest. The term notebook is also applied to some
types of hardware. Indeed, "notebook" serves as the new generic
term for laptop computer, with "sub-notebook" being used to describe
the new, smaller generation of laptops. However, in both cases the primary
connotation of the name seems to be that of size-such systems exhibit no
particular specialization for personal information management. Perhaps a
better fit are personal digital assistants (PDA's)-exemplified by the Apple
Newton® and the Sharp Wizard®-hand held devices that are explicitly
aimed at helping users manage their personal information.
Personal electronic notebooks pose an interesting challenge for designers
and developers. A general design problem is discovering how to make something
useful, as opposed to just usable. This problem is particularly acute for
systems like electronic notebooks that support the capture, use, and management
of personal information. Unlike conventional applications such as word processors
or spreadsheets, a notebook is very personal: it only becomes useful over
time-months or years-as it becomes the repository of more and more personally
relevant information. While it is straightforward to study usability-that
is, how easy it is to learn and use various features of the notebook-it
is much more of a challenge to understand which features, and which modes
of use, would make such a notebook useful.
Very little evaluation of the use of notebook-like applications or devices
has been done. Typically, if evaluation has been done at all, it is at the
level of usability testing, and is rarely described in detail. The only
example of longitudinal evaluation that I can find is NoteCards [12]. NoteCards
has undergone considerable evaluation, including longitudinal studies of
use over periods up to seven months [7, 8]. However, at least in the longitudinal
studies, NoteCards was used to support the collection and organization of
research notes and the production of a particular paper, rather than as
a more general system for managing personal information. Clearly, there
is much more to be learned.
Several years ago I participated in a project that involved the design
of a working prototype of a personal notebook. As noted above, while it
is easy to study the usability of such a notebook, it is more difficult
to understand which features would contribute to its usefulness over the
long term. In this case, fragility of both the software and hardware prototypes
frustrated any attempts at longitudinal evaluation.
One approach is to study how people manage their personal information today.
In fact, we began our project by looking at how people used artifacts such
as notebooks, calendars, post-it notes, and computers. This proved to be
a rich source of ideas, and particularly drove home the point that different
people did very different things. But it doesn't fully address the question.
An electronic device for managing personal information will have properties
that are very different from those of paper-based artifacts, and will therefore
be used in different ways. So, the question remains: how can we learn about
the ways in which an electronic personal information manager will really
be used over a long period of time?
My response was to build my own electronic notebook, which I refer
to as Proteus. My original intent was to force myself to use it on a daily
basis for two months, keep track of how it evolved to support my work practices,
and to make note of its benefits and drawbacks. Proteus turned out to be
sufficiently useful that little discipline was required to accomplish this.
As of this writing I've been using Proteus on a daily basis for three years.
The occasional periods when I am forced to do without it because of mechanical
or logistical problems reveal that it has become the primary tool by which
I manage my work and professional life.
In more objective terms, Proteus is a HyperCard®-based application that
is designed for use on a PowerBook®. In terms of content, Proteus consists
of approximately 1500 pages of personally meaningful information, collected
over the course of five years (some preexisting information was imported
into Proteus). In terms of technology, Proteus is a collection of 9 HyperCard
stacks taking up about 6 megabytes of disk space; it consists of about 80
handlers, and a few commonly available X-commands.
While I have drawn upon a number of sources of data for this account-a
change diary I kept about modifications to Proteus and the rationale behind
them, archives of notebook versions and their contents, and an automatically-
generated log of notebook commands-the fact remains that this is essentially
a subjective account of my experience. Where possible, I have used analysis
of portions of the notebook contents and the command log to confirm basic
facts such as the approximate frequency of usage. But this has not revealed
any surprises. The most interesting aspects of this account-claims about
why certain features succeeded or failed, what accounts for the notebook's
usefulness, the co- evolution of work practice and functionality-can not
be verified by analyzing command logs or content.
Objections to this approach to exploring design issues include concerns
about subjectivity, and the lack of generality of any findings. While I
do not contest these objections-indeed, they are quite reasonable-I would
note that no method is so sound as to allow designers to confidently proceed
from the findings of one or even a few studies done within its scope. I
believe that the sort of reflective analysis exemplified by this paper is
well-suited to the inherently personal nature of this topic. Reflective
analysis can yield much of value if it is carried out carefully, and if
designers also draw upon other methodologies to inform their work.
I begin with an overview of the Proteus interface, and then discuss the ways in which I actually use Proteus. Finally I describe some of the lessons I've learned from this experience. Throughout this paper I maintain a deliberately casual, first-person style, as a reminder that the findings being described are based on a population of one.
It is difficult to describe Proteus because it has changed over time.
What I'll do is describe the interface as it was in June 1994; at that time,
most of the features discussed had been stable for about a year.
Proteus can be thought of as a series of notebooks. There is a primary notebook
called the "working notebook" that is almost always open. In addition,
a "bookshelf" menu gives access to secondary notebooks (e.g.,
a notebook of reading quotations, working notes for 1993, etc.) and reference
stacks (e.g., a company phone directory).
Notebooks contain two types of pages: content pages where notes are made,
and table of contents (TOC) pages which provide structural overviews of
the notebook.
A content page contains four areas (figure 1):
Figure 1. A content page. The large scrolling field is where the
content is entered. The area at the top of the page is for various types
of header information. And at the bottom of the page are page-specific and
global controls (on light and dark backgrounds, respectively).
The other type of page is the table of contents page (TOC)-it provides structural overviews of the notebook or parts of the notebook. The structure of the notebook is quite simple: it is divided into sections, the sections are divided into subsections, and the subsections consist of pages. Each level of hierarchy has its own TOC page. That is, there is a global TOC for the whole notebook, and there are separate TOCs for each section and for each subsection. Typically, a TOC will only show the next lower level in the hierarchy, although this can be overridden. The TOC for a subsection will show the first line from the content area of each of its content pages.
The global TOC (figure 2) has browser-like properties: selecting a section
name from one of the upper panes in the window will show a list of its subsections
(and sometimes subsection contents) in the lower pane. Clicking on any item
in the lower pane will take you to that page.
Figure 2. The global table of contents permits users
to browse the contents of sections. Here, the "Daily Notes" section
(in the upper right field) is selected, and its subsections displayed in
the lower pane.
The section and subsection TOCs are simply lists of their contents. The
section TOC contains a list of subsections, and the subsection TOC contains
a list of pages (where each page is represented by the first line of its
contents). Clicking on any item in the TOC will take you to the appropriate
page. Figure 3 shows an example of a subsection TOC (the "May '94"
subsection of the "Daily Notes" section ). (Over time a convention
has evolved of summarizing a content page's important entries on its first
line, enabling the TOC page to function as a sort of abstract or summary
of its subsection.)
Figure 3. An example of a subsection TOC. Each entry
is the first line of the content field of the page; clicking on an entry
takes you to that page.
Most of the functionality of Proteus is accessed through page-specific
and global controls arrayed along the bottom of the page. Page-specific
controls (see figure 1) typically act on the contents of a page, and are
used for common actions such drawing a dashed line to separate entries,
prepending selected lines of text with >'s (for preparing responses to
email), and turning selected lines of text into an email message.
Global controls are for navigating around the notebook, or for altering
the notebook's structure. Examples of global controls include buttons for
jumping to the global TOC, today's notes page, and the next section, as
well as buttons searching, creating stamps, and making new pages.
Other mechanisms for accessing functionality include a "Bookshelf"
menu for navigating between notebooks, and key shortcuts for commonly done
actions (e.g., hide notebook; jump to Finder; go to next page).
Proteus evolved to support me, and therefore it is appropriate to say a few words about my inclinations and activities before describing how I use Proteus. As with the interface description, I focus on the period centered on June, 1994, when my job had been stable for about a year, and my commuting situation had been stable for about three months.
My work situation in June, 1994, was that I was part of a small, 3 person
group located in Cupertino, California. My activities involved communicating
closely with my colleagues, and with groups scattered across the organization.
I was involved-at least at a peripheral level-in many tasks at once. In
general, my roles included acting as a researcher, designer, strategist,
and consultant.
I commute to my California office from Minnesota, flying in for one week
a month. The week that I'm in town is focused on meetings-approximately
a dozen formal (scheduled) meetings, and lots of informal visits and hallway
conversations. When I work from my Minnesota office, I attend one or two
meetings a week by phone, but focus more on tasks like reading, writing,
and analysis. At the time being discussed, I sent perhaps 10 email messages
a day, and received about 30 (the majority not personally addressed to me),
regardless of geographic location.
In general, I am a very text-oriented person with a variety of interleaved,
on-going activities. I read a lot, and write a lot. Writing includes papers,
email, and notes about meetings, projects and design issues. In a very real
sense writing is my way of thinking about things: I work out ideas and their
implications in the process of making notes, writing email, and authoring
papers.
The principle function of Proteus is as a work diary. I use it to maintain
a To Do list, to keep notes on meetings, to compose and send email, and
as a repository for information (e.g., email messages) on which I want to
reflect or act later on. I keep all the information for a day on one page
in a long scrolling field (see figure 4).
Figure 4. Detail of a content page: A: Section and Subsection
titles. B: Page date (daily notes section only). C: First line of contents
field (appears in tables of contents). D: To Do list E: Beginning of notes
for first meeting.
So, in summary, frequent uses of Proteus (ranging from once or twice a week to many times a day) include:
I use Proteus for a number of other tasks, although their frequency is in the range of from once a week to once a month. These include:
It is interesting to note that I do not use Proteus in the way I originally thought I would. The motivation behind transforming Proteus from a stack of quotations into a full-featured electronic notebook was the vision of being able to make notes for a paper, and link the notes to the relevant quotations. However, after finishing the work of programming Proteus, I quickly abandoned this use. I found that jumping to the quotations caused a disruptive context shift, and that the functionality provided by HyperCard text fields was insufficient. What I really wanted (and soon switched to) was an outliner into which I could copy my quotations, and where I could interleave them with notes and writing fragments. In general, I do not use Proteus to author structured documents.
Before Proteus I was a heavy user of paper notebooks. As with Proteus, I used paper notebooks as a sort of work diary: I started each day on a new page, kept a To Do list, meeting notes, and used it as a repository for other information. However, there are couple of striking differences (besides the obvious one that I didn't use it for composing email). First, I find that I make many more notes in Proteus-in part this is because I find typing easier and faster than writing, and in part because of synergetic effects I describe in the next section. Second, I rarely looked back through my paper notebooks-and when I did, I only tended to look at recent entries. In contrast, I re-read entries in Proteus frequently. There are several reasons for this: it is easier to search and browse; the content is more legible; and when I find something useful it can be copied and re-used.
Although there are many ways in which Proteus is quite useful, two are so important as to make it an essential part of my work activity.
Probably the most significant impact of Proteus is a sort of synergy among the activities of note making, reference, and messaging. Messaging drives this synergy. I write notes more often-and my notes are of higher quality-because I know that I am more likely to email them to others. Because the quality of my notes is higher, I reference (and reuse) them more when I'm writing a relevant message or paper. Also, the increased quality means that I am more likely to understand them when I look back at them after six months. In turn, the increased frequency of reference also drives note making and messaging: the more use I get out of them, the more effort I'm willing to put into them. Thus, there is a curious sort of ambiguity when writing in Proteus: my proximate goal may be keeping notes on an interesting meeting, but I also know in the back of my mind that they may also turn into a message or serve as grist for a future paper.
The other major aspect of Proteus' usefulness has to do with its portability,
and with the amount of personally relevant information in it. I typically
carry Proteus with me and so I always have a variety of tasks of various
sizes that I can work on. If I arrive at a meeting early, I can compose
a message, review notes, or update my To Do list while waiting for others
to arrive.
This has changed my behavior. I am more willing to go to large meetings
where some or all of the content is of unknown relevance: if the meeting
is relevant, I pay attention and take notes; if parts are irrelevant, I
can work on other things while keeping half an ear on the meeting. I have
had extremely productive work sessions when 'stuck' in the middle of a row
in the auditorium. While this may sound like a small thing, the degree to
which it alleviates irritation at late-starting meetings, and anxiety about
being stuck in irrelevant meetings, makes a significant difference in my
life.
Although note making, messaging, and activity management are the primary uses of Proteus, information storage and retrieval plays an important role in supporting these tasks, as well as being useful independently. Proteus supports a variety of ways of searching for things. One can use text search, browse using the section and subsection TOCs, or search for items that have been specially marked in various ways.
One of the putative benefits of an electronic notebook is that you can
use text search. This is not as useful as it might seem. There are three
problems: First, a fact of life for me, and I suspect for most electronic
notebook users, is that notes are written hastily, and hence contain frequent
misspellings, typos, and abbreviations. Thus, standard keyword searches
are not very effective in finding words which have been mistyped or hastily
abbreviated. Second, I use many words much more frequently than I'm aware
of. Words like object, metaphor, interface, and communications are so frequent
as to not be worth searching for, as are common project names. In this respect
the use of To Do lists is a drawback, as important projects and items tend
to recur in To Do lists and generate hit after hit when searching. Finally,
the limitations of HyperCard's search mechanism (it takes you to the card,
and shows only the first word of the first instance that matches) exacerbates
the above problems. A search mechanism that would generate a list of fuzzy
hits (so that when searching for PowerTalk, you'd also get PowerTlk, and
PwerTalk), shown with surrounding context, would be far more useful.
As a consequence of this, text search in Proteus is primarily useful when:
1) trying to put together a summary of what has happened on a project (i.e.,
many hits are just what you want); 2) when searching for a relatively unique
target that is probably spelled correctly (e.g., part of an email address
string such as "boombox"; or 3) when the approximate location
of the item is known, so that the search can be limited to that neighborhood.
A second strategy for finding is to mark things when you think you may
want to find them later. Proteus provides two mechanisms for this: stamps
and dog-ears. A stamp is a way of providing a sort of topic-specific book
mark- Proteus had stamps for addresses, reference citations, and 'interesting
items.' The user can select a type of stamp and can then jump from one stamp
to the next. Dog-ears are similar to stamps except a bit simpler: they are
the analog of folding over the corner of a page. Like stamps, the user can
jump from one dog-ear to the next.
I use dog-ears several times a month; however, I rarely use stamps. One
reason for this has to do with overhead. While stamps are easy to use, requiring
no more than a click to stamp something, if I'm engaged in my current activity
I don't think about the desirability of stamping the item, or if I do, I
often don't want to interrupt my flow of activity. If I do decide to interrupt
myself, I still tend not to use stamps. Stamps are primarily a way of deferring
actions until later: I stamp addresses so I can enter them in my address
file; I stamp citations so I can put those in a special place; and
so on. If I decide to interrupt my activity, I typically just go ahead
and do the whole thing.
However, this doesn't explain why dog-ears are used so much more frequently
than stamps, since they are logically and functionally equivalent, both
requiring a click to create, and both requiring clicking a button to search
for. I believe that the explanation is that stamping something seems to
require more cognitive overhead. In stamping something, the user is basically
making the decision to apply a particular label to a particular piece of
content. In contrast, marking a page with a dog-ear is simply saying 'I
may want to look at something on this page again.' Dog-ears are more light
weight than stamps.
Proteus succeeds best at search by browsing. That is, a common strategy
for finding something-if its approximate location is known-is to browse
the appropriate table of contents. I may recognize what I'm searching for,
and can then jump directly to it. Or I may see something which reminds me
of the context, and thus generates more cues about what I'm searching for.
The decision to include the first line of each content page in the subsection
TOCs turned out to be a good one.
(Of course, it should be noted that TOCs were not designed with this use
in mind. TOCs evolved in the context of the original quotations stack (see
next subsection), and the idea of using the first line of each page was
derived from an analogy to the indices of poetry and quotation anthologies.)
One interesting facet of Proteus is that it has changed considerably over time, both in terms of its underlying structure and function, and in how it was used.
Proteus did not spring into existence as an electronic notebook, or as
a vehicle for exploring issues about customization and long term usefulness.
Rather, it went through a gradual evolution.
Proteus began as a stack of quotations and notes (my practice is to copy
down quotes from favorite books or articles). After a year or so, I had
enough entries that using them became cumbersome, and so I added a table
of contents that could be recompiled when new quotations were added. As
more cards were added it became desirable to break it into subsections and
to have a hierarchical table of contents.
About this time, I realized that with 'just a little more work' I could
have an electronic notebook that would allow me to explore on a personal
level some of the frustrating issues already described. I also had a concrete
task in mind for Proteus: I had been wanting to write a paper that drew
upon a number of the quotations I had collected in the stack, and I thought
it would be very useful to be able to outline the paper, and link parts
of it to relevant quotations.
Personal electronic notebooks have a paradoxical aspect to them: they
really don't become useful until considerable material has been entered,
and yet how many people will exert the effort needed to enter material,
before the utility is evident? I call this the start up problem. While it
is dangerous to generalize from a population of one, the case of Proteus
suggests an interesting answer to the start up problem.
Initially, Proteus tried to solve the start up problem by cheating, in that
it began with a large number of quotations that had been gradually built
up over a couple of years. However, this failed, in that the initially envisioned
authoring/linking use for Proteus didn't pan out: it was too cumbersome.
Instead, what saved Proteus from being abandoned was its use as a diary,
and that in turn was driven by the incorporation of messaging functionality.
Messaging added collaborative value to the note making functionality of
Proteus, and permitted it to be useful (and encouraged the entry of information),
until there was enough information to make Proteus useful for reference
purposes.
(As in the case of TOCs, the full importance of messaging was not anticipated.
Messaging was originally incorporated in Proteus only because it was easy
to add. I already had an X-command and script for messaging that I had used
in another stack, the electronic edition of a newsletter I edit. Ironically,
messaging was a failure in that context; fewer than a dozen people ever
made use of it.)
When working on the predecessor to Proteus (the original, working prototype
of an electronic notebook), I had a running debate with another designer
over how much structure people wanted in an electronic notebook. What I
wanted, I claimed, was something very simple: just a temporally-ordered
set of pages. People remember things by time, I said, and if you allow them
to move pages around, and create sections, they'll just start losing things,
and we'll have to introduce all sorts of functionality for organizing and
navigating the notebook.
As Proteus evolved, it quickly became apparent that I was wrong. While I
don't find it surprising when my intuitions about what other people want
are wrong, I was surprised to discover that my intuitions about what I wanted
were wrong. But it's incontestable. The most obvious trend in the evolution
of Proteus is the gradual addition of more and more layers of structure.
Proteus started out as one notebook; after a bit it was broken into sections,
each with their own table of contents. After a bit longer subsections and
subsection TOCs were added. And finally major sections of the notebooks
were broken apart into separate notebooks which can be accessed through
a bookshelf menu.
At the same time, it is important to note that at the beginning I neither
wanted nor needed the structure. It was only as time went on, and I added
more and more information, and begin to develop specialized ways of interacting
with it, that the increased structure became useful for supporting access
and browsing, and for segregating functionality.
This brings us to the next trend in the evolution of Proteus: the increasing degree of task-specific specialization. As I began using Proteus in new ways, after a while I would develop functionality that support the new mode of use. For example, the use of Proteus as a diary started out fairly simply: text was simply entered onto a blank, unspecialized content page. But as time went on I developed various conventions, and then eventually implemented functionality to support and reinforce those conventions. Some instances:
These are all minor things. However, they do use up significant amounts
of the limited space for controls, and contribute to the transformation
of pages in the "daily notes" section from generic content pages
to diary-specific pages. The appearance of task-specific controls also increased
the pressure to split off the diary portion of the notebook into its own
notebook. Perhaps most importantly, the appearance of task-specific functionality
resulted in new structural features of the notebook which could then be
used to support the development of more task-specific functionality. For
example, once the "---" button for separating items was implemented,
it was easy to create a button to jump from one item to the next because
the system could tell that a new item was marked by the appearance of a
particular number of dashes; prior to that, when dashed separators were
generated manually and might have any number of dashes, the task of writing
a script to distinguish separators from other uses of dashes was more work
than seemed justified.
Similar stories can be told about other uses of Proteus. The quotation reference
section of Proteus became more specialized, and was split off into its own
notebook. A section of Proteus that started out to support scheduling, gradually
became more complex and specialized, until it was replaced with links to
an external, calendar application. The global Table of Contents began as
a regular TOC (as in figure 3), and only gradually developed the browser-like
structure shown in figure 2. Again and again there was a move from generality
and simplicity towards specialization and complexity. And while there are
many instances of periods of simplification (e.g., the removal of unused
functionality), these simplifications were often triggered by the desire
to make room for new functionality.
When I began using Proteus, I had a relatively simple application
that was easy to use and to explain to others. Now, Proteus is much more
complex; it has quite a few features that are useful only to me, and that
make the interface more complex and difficult to learn for anyone else.
In the process of being customized for my purposes, Proteus has shifted
from being usable (by anyone) to being useful (to me).
This raises some interesting questions. How general is this tradeoff between
simplicity and usability on the one hand, and specialization and complexity
on the other? Will technologies like OpenDoc, which promise to support customization,
manifest this trend? Or, less generally, suppose that three years ago I
had been magically given Proteus as it is structured today: would I have
found it either usable or useful? I suspect the answer is no. My guess is
that my work practices had to gradually evolve in consonance with the structure
and function of Proteus. That is, rather than this being a process of me
gradually customizing Proteus to my needs, it feels more like a process
of co-evolution in which the electronic notebook and my work practices have
mutually conditioned one another. For example, as previously noted, the
use of Proteus resulted in me being more willing to attend large meetings,
and in turn, more frequent use of Proteus in large meetings resulted in
various adaptations for more effective use in such situations (e.g., an
easy way to turn the sound off).
It's important to note that Proteus evolved only because HyperCard provided such a flexible and readily-customizable environment. Three things seem of importance. First, the ability to change small things-graphics, buttons, handlers-made Proteus feel like a truly malleable environment. It got me into the habit of tweaking things. Another important factor was the availability of modules of functionality that could be imported from elsewhere. Scripts created both by myself and by others were often incorporated into Proteus. This greatly decreased the overhead involved in adding functionality, and made it much easier to experiment. For example, it took me less than twenty minutes from conception to working implementation to add voice notes into Proteus (and this is fortunate because I never used them). Finally, the aforementioned context independence provided by Proteus also applied to its customization. That is, at any time I encountered a problem or thought of a way Proteus could be tuned to better support my practices, I could do it. A number of small but important features were implemented while waiting for people to show up, or while 'stuck' in large meetings. This practice was so prevalent during the early stages of developing Proteus, that I built in a special command key combination to jump into the HyperTalk Reference stack.
There are a number of reasons Proteus is a useful tool for me. One is
simply that it supports the representations with which I work. Proteus is
good at dealing with text, and many of the ways in which I reflect, communicate,
and act, are entwined with textual representations. A person for whom other
representations of information were more critical, would probably not find
Proteus a useful tool.
A less obvious point is that Proteus is useful because of the synergy between
note making and messaging. As noted, the messaging built into Proteus increases
the potential utility (and quality) of note making, and the note making
in turn provides grist for messages and other re-uses of content. Re-use
of content is facilitated, in its turn, by the malleable nature of text,
and by the support for browsing provided by the subsection tables of contents.
And browsing itself is made easier because the normally ephemeral information
that is captured - To Do lists, email messages, notes - provide more cues
about what is being searched for. Interestingly, the synergy I've observed
between note making and messaging resonates with John-Steiner's [6] characterization
of paper notebooks as a means of capturing "condensed thought",
and as an aid to transforming it into public language. (It is humbling to
note that two of the more critical features in supporting this synergy-messaging,
and the subsection tables of contents-were developed with different applications
in mind, and without any suspicion of their ultimate usefulness.)
Finally, the fact that the portability of Proteus enables me to perform
many tasks-reflection, communication, activity management-anywhere, has
proved to be very useful. While this result was by no means unanticipated,
the second order effects such as my increased willingness to attend large
meetings were not expected.
Proteus is also interesting as an illustration of evolution through customization.
Over the course of three years Proteus exhibited consistent trends towards
specialization, task-specific functionality, and greater complexity. In
addition, there was a pronounced tendency for Proteus and my work practices
to co-evolve-it seems doubtful that starting out with the final version
of Proteus would have been useful.
Finally, there are striking parallels between the design of Proteus, and
design in the large. Common beliefs about designing products for users-that
designers' intuitions aren't to be trusted, that designers are poor at predicting
how a technology will be used, that iteration is an inherent part of design,
that features will be used in unanticipated ways, that users are poor at
articulating what they really need-carry over even to the case where the
designer and the user are one.
Thanks to a number of anonymous reviewers for suggestions and comments.
HyperCard, Newton, and PowerBook are registered trademarks of Apple Computer.
The Virtual Notebook System is a trademark of Baylor College of Medicine
and the ForeFront Group. Lotus Notes is a registered trademark of Lotus
Development Corporation. Wizard is a registered trademark of Sharp.
1. Assimacopoulos, A., Revillard, C., Herrmann, F., Borst, F., Paschoud,
N. and Scherrer, J. R. An Electronic Notebook for Problem Oriented Patient
Progress Notes: Testing a Concept. Proceedings of the 6th Annual Conference
on Medical Informatics (1989), pp. 813-817.
2. Conklin, J. and Begeman, M. L. gIBIS: A Hypertext Tool for Exploratory
Policy Discussion. Proceedings of CSCW '88 , (1988), ACM Press.
3. Dejan, D. and Dejan, S. B. Lotus Notes at Work. Lotus Books,
New York, 1991.
4. Fowler, J., Baker, D. G., Dargahi, R., Kouramajian, V., Gilson, H., Long,
K. B., Petermann, C., and Gorry, A. G. Experience with the Virtual Notebook
System: Abstraction in Hypertext. Proceedings of CSCW '94.
(1994). ACM Press, pp. 133-143.
5. Halasz, F., Moran, T. P., and Trigg, R. H. NoteCards in a Nutshell. Proceedings
of CHI + GI 1987 (1987), ACM Press, pp. 45-52.
6. John-Steiner, V. Notebooks of the Mind: Explorations of Thinking.
Harper & Row, New York, 1985.
7. Monty, M. L. Issues for Supporting Notetaking and Note Using in
the Computer Environment. (1990) Unpublished Dissertation, Department
of Psychology, University of California, San Diego.
8. Monty, M. L. and Moran, T. P. A Longitudinal Study of Authoring Using
NoteCards. SIGCHI Bulletin 18, 2 (1986), pp. 59- 60.
9. Neuwirth, C., Kaufer, D., Chimera, R., and Gillespie, T. The Notes Program:
A Hypertext Application for Writing from Source Texts: Experiences and Writing.
Proceedings of the Hypertext '87 Conference, (1987), ACM Press,
pp. 121-141
10 Schnase, J. L. and Leggett, J. J. Computational Hypertext in Biological
Modeling Applications. Proceedings of the Hypertext '89 Conference,
(1989), ACM Press, pp. 181-197.
11 Shipman, F. M., Chaney, R. J., and Gorry, G. A.. Distributed Hypertext
for Collaborative Research: The Virtual Notebook System. Proceedings
of the Hypertext '89 Conference, (1989), ACM Press, pp. 129- 135.
12 Trigg, R. H. and Irish, P. M. Hypertext Habitats: Experiences of Writers
in NoteCards: Proceedings of the Hypertext '87 Conference,
(1987), ACM Press, pp. 89-108
13 Twidale, M., Rodden, T., and Sommerville, I. The Designers' Notepad:
Supporting and Understanding Cooperative Design. Proceedings of the
Third European Conference on Computer-Supported Cooperative Work (1993),
pp. 93-107.
[Tom's Home Page]
[Professional] [Life,
Fun, &c] [Tell Me...]