[Tom's Home Page]
[Professional] [Life, Fun, &c] [Tell Me...]
Advanced Technology, Apple Computer, Inc.
(now at) email@example.com
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" , 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 , 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 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,
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
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  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...]