 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The present invention relates to techniques for preparing a record of
operations performed by a data processing system. More specifically, the
invention relates to the preparation of a record through which a user can
obtain access to data affected by the operations described in the record.
Trigg, R. H., Suchman, L. A., and Halasz, F. G., "Supporting Collaboration
in NoteCards," Proceedings of the Conference on Computer-Supported
Cooperative Work, Austin, Tex. Dec. 3-5, 1986, pp. 153-162, describe
NoteCards, a hypertext-based idea structuring system in which the basic
object is an electronic notecard. (Underlying features of NoteCards are
described in greater detail in Halasz, F. G., Moran, T., and Trigg, R. H.,
"NoteCards in a Nutshell," CHI+GI'87 Conference, Toronto, Canada, Apr.
5-9, 1987, incorporated herein by reference.) Page 153 states that
annotative and procedural activities are necessary to maintain mutual
intelligibility between collaborators. Pages 156-158 describe
collaboration through draft passing, in which History cards keep records
of each entry into a notefile of notecards and of the changes made during
a collaborative session. A History card is created for each session,
titled with the date and initialed by each participating collaborator. As
shown and described in relation to FIG. 1, the card's text contains brief
descriptions of the work done in that session and links to the cards that
were created or modified. All history cards are filed in a history filebox
and are kept in chronological order, allowing one collaborator to review
the work done by another and follow links to the affected cards.
Halasz, F. G., "Reflections on NoteCards: Seven Issues for the Next
Generation of Hypermedia Systems," Hypertext '87 Papers, Chapel Hill,
N.C., Nov. 13-15, 1987, pp. 345-365, describes the NoteCards system as
well as a number of design issues for future hypermedia systems. Pages
361-362 discuss the issue of versioning, and mentions several types of
histories, including linear version threads or other version graphs for
individual nodes and links or for a set of nodes, a version history for
all entities in a hypermedia network, and a layer mechanism collecting a
number of changes. Pages 362-363 discuss the issue of collaborative work,
mentioning automatic maintenance of change histories.
Jensen, A-M. S., Jordan, D. S., and Russell, D. M., "The IDE System for
Creating Instruction," presented to Applications of Artificial
Intelligence and CD-ROM in Education and Training Conference, Arlington,
Va., October 1987, describe the Instructional Design Environment (IDE)
built on the NoteCards system. Section 2.2 describes Autolink buttons that
are used to make link connections between cards, reducing the number of
mouse clicks required for link connection; an Autolink button can be set
up to automatically create links to blank cards. Section 2.3 describes
templates, which are cards of a type having a predetermined format.
Copending, coassigned U.S. Patent Application Ser. No. 195,230, entitled
"Accelerating Link Creation," filed May 18, 1988, now U.S. Pat. No.
4,982,344 which is issued on Jan. 1, 1991 ("the Autolink application"),
and incorporated herein by reference, describes Autolink buttons and
templates in greater detail.
Goodman, D., "The Complete HyperCard Handbook," Bantam Books, New York,
1987, pp. 32-34, 65-67 and 185-192, describes the Recent navigation aid
and linking in HyperCard. Pages 32-33 show how Recent shows miniature
representations of the last forty-two unique cards viewed; the user can go
to any of the represented cards by providing a mouse click on that card's
representation. Page 67 points out that a link can take extra steps to
eliminate manual searching on a user's part. Pages 187-188 describe hard
links that take the browser from one card to another without any other
kind of action and soft links performed by a HyperTalk script. The section
starting at page 188 describes link creation using the Link To . . .
button and the Button Info dialog box.
Garrett, L. N., Smith, K. E., and Meyrowitz, N., "Intermedia: Issues,
Strategies, and Tactics in the Design of a Hypermedia Document System,"
Proceedings of the Conference on Computer-Supported Cooperative Work,
Austin, Tex., Dec. 3-5, 1986, pp. 163-174, describe Intermedia, a
hypermedia system for multiple users. Section 2 on pages 163-164 describes
links between selections within documents, explaining how an instructor
reading a report can leave comments, criticism, and suggestions for
revision through annotation links, which the student who prepared the
report can then see while revising the report. Section 5.4 on page 173
describes several possible ways a system could respond to a user's changes
in documents, including passive notification via a facility such as
electronic mail, informing users that there had been changes to documents
since they last opened them.
Lewis, B. T. and Hodges J. D., "Shared Books: Collaborative Publication
Management for an Office Information System,"ACM Conference on Office
Information Systems, Mar. 23-25, 1988, pp. 197-204 describe collaborative
publication management for an office information system. Page 198 states
that publications have a revision history, and that it is desirable for a
publication management system to be able to reproduce older revisions of a
document. Pages 199-200 describes the Shared Book window, shown in FIG. 1,
in which information is displayed including an entry's lock status,
revision number, creation date, and notes such as status information or
comments entered by a worker. A change on one workstation is not
immediately broadcast to all others, but updating occurs on the next user
action. The Entry Details property sheet, providing detailed information
about an entry, is shown in FIG. 2 and described on page 200. Page 201
describes an automatically managed data file in the remote Shared Book
that supplies the data displayed in the Shared Book window. Page 202
describes job management functions, including Notes and Reasons fields
that can be used to hold both procedural and annotative information.
Kasperski, R., Chang, E., and Mellon, L., "Cantata: Group Protocols in a
Conferencing Environment," IEEE International Conference on Systems, Man,
and Cybernetics, Vol. 2, 1986, pp. 1343-1346, describes a multi-person
message exchange system called Cantata. As described at pages 1343-1344,
each Cantata participant has a complete history of the conversation, and a
new participant entering a conversation is given a complete history of the
conversation among the other participants. A participant may review by
scrolling within a window.
Stefik, M., Bobrow, D. G., Foster, G. Lanning, S., and Tatar, D., "WYSIWIS
Revised: Early Experiences with Multiuser Interfaces," ACM Transactions on
Office Information Systems, Vol. 5, No. 2, April 1987, pp. 147-167,
describe multiuser interface techniques including meeting tools called
Boardnoter and Cognoter. Page 159 describes features of Cognoter that use
reduced scale stamps to show when changes are made in corresponding
full-scale windows; a bar attached along an edge of a stamp can be
initially white and can become progressively darker as changes accumulate.
To identify recent changes when a participant refocusses on a window,
recent changes can be highlighted. Page 162 describes an overview room
with miniaturized active images of rooms in which subgroups are working,
with indicators showing how much change there has been and where the
activity is from moment to moment. Page 163 describes a facility for
highlighting recent changes in a room, making it possible to overlay
privately needed annotations on information in public windows.
Leblang, D. B. and Chase, R. P., Jr., "Computer-Aided Software Engineering
in a Distributed Workstation Environment," in Henderson, P., (Ed.),
Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on
Practical Software Development Environments, Pittsburgh, Pa., Apr. 23-24,
1984, describe DSEE, a software development environment. Beginning on the
second page, a section describes history management, explaining how a
History Manager inquires about the reasons behind a change made by a user,
then records that information, along with the date/time, node id, and
person's name in the history database. The third page describes how
history files are stamped with an object type unique identifier (UID).
SUMMARY OF THE INVENTION
The present invention provides techniques for automatically creating a
record of operations from which the user can access a data unit on which
the operations were performed. Furthermore, a record prepared according to
the invention can be presented with a pointer icon that provides one-way
access to the affected data unit, permitting efficient editing by a user;
when editing is completed, the pointer icon can be converted to a link
icon providing two-way access.
One aspect of the invention is based on the recognition of a basic problem
in the preparation of a record of operations from which data affected by
the operations can be accessed. In the NoteCards system, operations are
typically performed by creating a data unit, called an object, that
corresponds to a card or by modifying the data in a card's object.
Information about the operation that was performed is necessary for
preparation of a useful record, and a data processing system can obtain
such information by keeping a history, such as a running log of operations
performed. This history could include data indicating a card's title, the
operations that created the card, the sequence of steps taken to modify
its contents, and other relevant data. This history data is not enough,
however, to permit access from the operations record to the affected card.
This aspect is further based on the recognition that this problem can be
solved by obtaining an operations history that includes, for an operation
that is performed, data indicating a unique identifier (UID) of each card
affected by that operation. Each affected card's UID is included in
history data describing the operation affecting it and the history data is
included within the operations history. The operations history is scanned,
and when the scan reaches the history data, the history data is accessed.
Data corresponding to the history data is included in a history card's
data unit. Data indicating the UID is associated with the history card's
object, so that the affected card can be accessed from the history card.
A closely related aspect is based on the recognition that the preparation
of an operations record from which affected data units can be accessed
usually requires some user input. For example, in response to a user
request, a history log could be scanned, with the system automatically
including appropriate history data in a history card's data unit and
associating UID data appropriately so that the affected cards can be
accessed from the history card through link icons in the history card.
Then, the user may wish to create link icons providing access from the
history card to additional cards, or may wish to delete some previously
created link icons. The conventional process of creating or deleting a
link icon is cumbersome, however, so that it is inefficient to create a
link icon and then delete it unnecessarily.
This aspect is further based on the recognition that this problem can be
solved by dividing the process of providing access to an affected card
into two stages. In the first stage, an icon or other selectable display
feature is presented in the history card to provide one-way access to an
affected card; when the icon is selected, the affected card is presented,
but no linking data unit or other arrangement is set up to provide two-way
access from the affected card back to the history card. In the second
stage, two-way access is provided, so that a user can also access the
history card from the affected card.
This solution promotes efficiency because the automatically generated
contents of the history card can, in the first stage, include only icons
that provide one-way access; these icons are referred to herein as
"pointer icons" because, in contrast with link icons, the corresponding
data units contain little besides data indicating the UID of the affected
card and are not accessible from the affected card. The user can therefore
edit the automatically generated contents of the history card without the
costly operations of deleting link icons, which also involves deleting
data in the affected card's object. When editing is completed, each
pointer icon can be converted to a link icon by creating a respective
linking data unit.
The following description, the drawings and the claims further set forth
these and other objects, features, and advantages of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic flow diagram showing steps in preparation of a record
of operations according to the invention.
FIG. 2 is a flow chart showing general steps in scanning operations history
data according to the invention.
FIG. 3 is an image of a screen display showing a history card and a menu
for controlling how data for the history card is obtained from a log.
FIG. 4 is a flow chart showing steps in providing data for a history card
like that in FIG. 3.
FIG. 5 is a schematic diagram showing relationships between data units
according to the invention.
DETAILED DESCRIPTION
A. Conceptual Framework
The following conceptual framework is helpful in understanding the broad
scope of the invention, and the terms defined below have the meanings
indicated throughout this application, including the claims. This
conceptual framework is a modification and extension of that set forth in
the following copending, coassigned U.S. patent applications, all of which
are incorporated herein by reference: Ser. No. 030,766, entitled "User
Interface with Multiple Workspaces for Sharing Display System Objects,"
filed Mar. 25, 1987, issued Dec. 10, 1991 as U.S. Pat. No. 5,072,412, Ser.
No. 127,814, entitled "Small-scale Workspace Representations Indicating
Activities by Other Users," filed Dec. 2, 1987, issued Nov. 27, 1990 as
U.S. Pat. No. 4,974,173; Ser. No. 127,997 entitled "Multiple Shared
Virtual Workspaces," filed Dec. 2, 1987, now continued as Application Ser.
No. 07/570,984; Ser. No. 195,230, entitled "Accelerating Link Creation,"
filed May 18, 1988, issued Jan. 1, 1991 as U.S. Pat. No. 4,982,344; Ser.
No. 241,525, entitled "Private Regions within a Shared Workspace," filed
Sept. 7, 1988, issued Apr. 21, 1992 as U.S. Pat. No. 5,107,443, and Ser.
No. 242,087, entitled "Window System with Independently Replaceable Window
Functionality," filed Sept. 8, 1988, continued as Ser. No. 07/614,957,
issued Jun. 9, 1992 as U.S. Pat. No. 5,121,478.
Although the invention is not limited to a digital data processing system
with a display system, some of the features of the invention can be
advantageously implemented using a display system, as discussed below. A
wide variety of display systems for data processing systems are available
including, for example, various graphical user interfaces, but, despite
their diversity, these systems tend to have certain common
characteristics. One fundamental common characteristic is that a display
produces human perceptions. In this application, the term "display
feature" refers to any human perception produced by a display.
A "workspace" is a display feature within which other display features
appear to have respective relative positions. A card, as in the NoteCards
system, is an example of a workspace. Another familiar example of a
workspace is a window. "Presenting" a workspace that includes plural
display features produces the human perception of the display features in
respective positions relative to each other.
As used herein, the term "workspace" includes a "virtual workspace,"
defined in some of the applications incorporated herein by reference as a
workspace that is not completely viewed at a given time. Presentation of a
virtual workspace produces the human perception of a workspace that exists
but is only partially viewed or is not always viewed. In the NoteCards
system, the cards are virtual workspaces because they are not always
viewed.
A "selectable unit" is a bounded display area that a user can select, such
as a link icon in the NoteCards system. The term "select," when used in
relation to a selectable unit, means a user input operation that includes
a signal that uniquely identifies the selectable unit and requests that it
be selected. The user can, for example, use a pointing device such as a
mouse to select a selectable unit by indicating its position and clicking
a button on the pointing device. In general, a selectable unit may take
any appearance, and is not limited to a visually distinguishable feature
or set of features that appears to be a coherent unity.
A selectable unit can provide "access" to a display feature, meaning that
the system responds to selection of the selectable unit by presenting the
display feature. A selectable unit that is presented in one workspace can,
for example, provide access to another workspace that is presented when
the user selects the selectable unit; in the NoteCards system, for
example, a link icon in a source card provides access to a destination
card. A selectable unit provides "two-way access" between two workspaces
if a user viewing the accessed workspace can always access the workspace
that contains the selected unit, either by selecting another selectable
unit or by another form of request for access. A selectable unit provides
"one-way access" between two workspaces if it provides access but does not
provide "two-way access." Link icons in the NoteCards system provide
two-way access, because a user viewing the destination card can always
access the source card through the destination card's ShowLinks menu item.
Pointer icons in the NoteCards system provide one-way access, because a
user viewing the destination card cannot learn about the existence of the
pointer icon and therefore cannot return to the source card.
Another common characteristic of display systems is a correspondence
between data in digital memory within the data processing system and
display features. In this application, a "data structure" is any
combination of interrelated data. A "data unit" is a data structure that
is accessible as a unit by the data processing system. In the NoteCards
system, the data units corresponding to cards and links are often called
"objects." Data in general can be accessed by accessing any data unit that
includes the data or that is included in the data. A "unique identifier"
or "UID" is a value an instance of which can be used to access a data
unit; data that is an instance of a UID or that can be used to compute an
instance of a UID will sometimes be referred to herein as "indicating" the
UID.
A data unit is "added to" another data structure by making it accessible
based on the location or contents of that other data structure. After a
data unit is added to a data structure, the data structure "includes" the
data unit. Two data units are "associated" with each other whenever either
of them is accessible based on the location or contents of the other. For
example, two data units may be associated with each other by adding one to
the other, by adding both to a third data unit, or by adding a third data
unit to both. Also, two data units can be associated by adding an item of
data to one that can be used to access the other, such as a pointer, a
handle, or other data indicating a UID. Or two data units can be
associated by positioning them in adjacent locations or in locations with
a known separation. In general, two data units can be associated by
associating both with a third data unit in any way. Therefore, a history
card data unit can be associated with an affected card's data unit through
associated UID data or through a linking data unit that includes UID data.
Similarly, data in general are "added to" a data unit or other data
structure by being made accessible based on the location or contents of
the data unit or data structure, and thereafter the data are "included" in
the data un | | |
