The Design and Long-Term Use of a Personal Electronic Notebook:
A Reflective Analysis*
Advanced Technology, Apple Computer, Inc.
(now at) firstname.lastname@example.org
Published in Human Factors in Computing: The Proceedings of CHI '96.
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
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" , 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,
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 , a physician's notebook , a prototype
of a biologist's notebook  and NoteCards . If the constraints are relaxed
to allow collaborative systems, other examples appear, such as the Virtual Notebook
System(tm) [4, 11], and Lotus Notes® . 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 . 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
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.
A Note on Method
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
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.
AN OVERVIEW OF THE INTERFACE
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):
- Header area. The top portion of the page has several fields for header information
such as the name of the notebook section and subsection, the date the page
was started, and so on.
- Content area. This is a single scrolling field where almost all information
- Page-Specific Controls. Below the content field is a series of buttons for
commands which apply to the content area. The page-specific controls appear
to be on the same background as the content and header areas.
- Global Controls. Below the page-specific controls, on a darker graphic background,
are controls which support global commands-primarily commands for navigating
around the notebook.
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).
Table of Contents (TOC) Pages
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
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.
Section and Subsection TOCs
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).
HOW I USE PROTEUS
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.
Daily Use as a Work Diary
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
I've developed a fairly consistent daily routine for using Proteus:
- I begin by going to the page of the day.
- I update the To Do list at the top of the page (usually, the To Do list
for that day has already been started).
- I switch out of Proteus and check my email and calendar. This may result
in further additions to the To Do list. Email that has content that I want
to save or that I want to reflect on and answer later, may be pasted into
the content area.
- As the day goes on I usually have Proteus near at hand. I will use Proteus
to update my To Do list, to jot brief notes (e.g. telephone messages; thoughts),
and to compose and send email. When in meetings, I will usually make notes
in Proteus; if the meeting is fairly large and is covering matters that don't
concern me, I'll make notes on other things, update my To Do list, or do email,
while monitoring what's going on in the meeting.
So, in summary, frequent uses of Proteus (ranging from once or twice a week
to many times a day) include:
- Managing my tasks (To Do'ing)
- Recording meeting notes
- Serving as a repository for information
Occasional Use for Reference and Summaries
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:
- Reference. I use the search command to search through Proteus for information
several times a month- occasionally a particular quotation from something
I've read, more often notes from a particular meeting.
- Summarization. Once a month I do a report on my activities; this involves
browsing the last month's worth of Proteus entries. Occasionally, I need to
produce a summary of the results of a series of meetings, and will search
for notes relevant to particular projects.
- Diagramming. A couple times a month I will use Proteus to draw diagrams
or models relevant to meetings or projects in which I'm evolved. (This is
a completely unanticipated use: I hadn't imagined that anyone-let alone me-would
want to draw with a track ball!)
- Capturing Reading Notes. If I read something useful, I'll often transcribe
quotations from it into a special section of Proteus. This activity occurs
in bursts-with several months intervening between bursts.
Ways in Which I Don't Use Proteus
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.
Usage of Proteus versus Paper Notebooks
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.
Contributions to Usefulness
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
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
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
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
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.)
Evolution of the Design
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.
The Pre-History of Proteus
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.
From Linking/Authoring to Messaging and Note Making
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:
- The diary page begins with the date. Initially the date was entered manually.
After a while, I created a "header" button to automatically generate
the date for the day. As of this writing, the working notebook for a new year
is generated, with the diary pages having the date embedded in them.
- As the To Do list became more heavily used, buttons that supported particular
operations on it appeared (e.g., a 'procrastinate button', that moves selected
To Do items to tomorrow's page; a 'to do button' that copies selected text
(usually from notes), and inserts it in the To Do list.)
- A convention of separating different items with dashes was codified with
the "---" button, which automatically drew a line of dashes.
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.
From Generic and Usable to Arcane and Useful
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
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  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
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
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,
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.
* Published in Human Factors in Computing Systems: The Proceedings of CHI 96.
© Copyright 1996 ACM. Permission to make digital or hard copies of part or
all of this work for personal or classroom use is granted without fee provided
that copies are not made or distributed for profit or commercial advantage and
that copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ACM must be honored. Abstracting
with credit is permitted. To copy, otherwise republish, to post on servers or
to redistribute to lists, requires prior specific permission and/or a fee.