 |
Claims  |
|
|
What is claimed is:
1. An apparatus for displaying documents, comprising:
a computer controlled display device;
means for displaying a strand of documents on said display device, said
strand having a parent document and one or more child documents, said
parent document represented on said display device by a screen object,
each one of said child documents represented on said display device by a
screen object displayed on a strand path, said strand path consisting of a
two dimensional line through a three dimensional virtual display space in
which said parent document and said child documents are arranged;
said parent document including a strand function, said strand function
being an attribute having a value equal to a script representation of a
mathematical equation which when interpreted and executed outputs the
coordinates of said strand path; and
each one of said child documents identified by an entry in a child document
list contained within said parent document, each entry in said child
document list containing a unique identifier for one of said child
documents.
2. The apparatus as in claim 1, further comprising:
a workspace viewer process for maintaining said three-dimensional virtual
display space, said three dimensional virtual display space known as a
workspace;
a perspective function, within said workspace viewer process, for
translating coordinates of said parent document and said child documents
in said three-dimensional workspace from three-dimensional coordinates
into two dimensional screen coordinates.
3. The apparatus as in claim 2, further comprising:
a processor;
a memory coupled with said processor;
said documents stored as data in said memory;
said perspective function consisting of software stored in said memory and
executing on said processor.
4. The apparatus as in claim 1, further comprising:
user interface means for manipulating the position of said strand as
displayed on said display device.
5. The apparatus as in claim 4, said user interface means further
comprising:
a mouse; and
strand moving means, responsive to said mouse, for selecting said strand
and moving the location of said strand as a whole in said workspace.
6. The apparatus as in claim 5, further comprising document removing means,
responsive to said mouse, for selecting one of said child documents, and
removing said child document from said strand by dragging said child
document off of said strand path.
7. The apparatus as in claim 1,
said parent document including a minimum spacing constraint defining a
minimum distance along said strand path between each screen object on said
strand.
8. The apparatus as in claim 1, said parent document including a maximum
spacing constraint defining a maximum distance along said strand path
between each screen object on said strand.
9. The apparatus as in claim 1, said parent document including a knot
constraint, defining a point on said strand path, such that any of said
child documents displayed between said parent document and said knot
constraint belong to a first sub-strand, and all other of said child
documents belong to a second sub-strand.
10. The apparatus as in claim 1, said parent document including an origin
constraint, said origin constraint defining the position of said strand on
said display device relative to the screen object of said parent document.
11. The apparatus as in claim 1, wherein said display device is a CRT.
12. An apparatus for displaying documents, comprising:
a processor;
display memory means coupled with said processor;
a display device, coupled with said display memory means, for displaying
screen objects described in screen coordinates stored in said display
memory means;
document memory means, coupled with said processor, for holding one or more
documents;
one or more child documents stored in said document memory means;
a parent document stored in said document memory means, said parent
document having a strand function, said strand function being an attribute
having a value equal to a script representation of a mathematical equation
which when interpreted and executed outputs the coordinates of a strand
path;
one or more screen objects representing each one of said one or more child
documents and displayed on said display device on said strand path;
script interpreter means, coupled with said document memory means, for
interpreting and executing said strand function and outputting three
dimensional world space coordinates of said strand path; and
perspective function means, coupled with said processor, said display
memory means, and said document memory means, and
responsive to said three dimensional world space coordinates, for
translating said world space coordinates into two dimensional screen space
coordinates, and storing said screen space coordinates into said display
memory means.
13. The apparatus as in claim 12, further comprising:
said script interpreter means and said perspective means are computer
programs executing on said processor; and
said strand function is code stored as a high level language in said parent
document, and said strand function is interpreted into executable code by
said script interpreter means, and said executable code is executed on
said processor.
14. The apparatus as in claim 12 said parent document further comprising:
a child document list identifying all child documents on said strand;
a strand minimum constraint defining a minimum distance between screen
objects on the strand;
a strand maximum constraint defining a maximum distance between screen
objects on the strand; and
a strand origin constraint defining a position of said strand relative to
position of a screen object representing said parent document on said
display device.
15. The apparatus as in claim 12 each one of said one or more child
documents further comprising:
a strand position constraint defining a location of a screen object
representing said child document on said strand on said display device
relative to said parent document; and
a strand parent constraint identifying said parent document.
16. The apparatus as in claim 12 further comprising:
a user interface, having a user interface device, for dragging screen
objects shown on said display device;
said parent document including a child document list, each element in said
child document list containing a unique identifier of one of said one or
more child documents;
document inserting means, responsive to a screen object of a new document
being dragged into contact with said strand path, for inserting said
document into said strand by adding a unique identifier for said new
document to said child document list in said parent document, said new
document thereby becoming a child document of said strand.
17. The apparatus as in claim 16, further comprising:
document removing means, responsive to a screen object corresponding to one
of said on or more child documents being dragged off of said strand path,
for removing a unique identifier of said on of said one or more child
documents from said child document list in said parent document.
18. The apparatus as in claim 16, wherein said user interface device is a
mouse.
19. The apparatus as in claim 16, wherein said user interface device is a
track ball.
20. The apparatus as in claim 16, wherein said user interface device is a
touch sensitive display screen.
21. The apparatus as in claim 16, wherein said user interface device is a
light pen.
22. The apparatus as in claim 16, wherein said user interface device is a
pressure sensitive pad for inputting user handwriting. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
FIELD OF THE INVENTION
The invention relates generally to office management, and more specifically
to the representation and manipulation of documents on a display device.
BACKGROUND
People have been using computers to work with their documents for years. In
known systems, finding documents often means an expedition through a maze
of directories and folders, and even simple jobs require learning a
mysterious language of commands and data objects.
In known two-dimensional user interfaces, folders or directories are used
to organize files or documents into groups and hierarchies. The
traditional way of dealing with grouping documents is to use containers,
directories or folders. A directory or a folder is a container in which
you put other objects.
A problem with the known two-dimensional user interfaces is that documents
in containers or directories are hidden from the user. The user is
therefore unable to easily browse through the documents in the system. The
user typically cannot see the documents inside a container without opening
up the container.
For these reasons and others, a new system of document representation is
required, which allows users to easily manipulate documents in an
environment like the real world of the desktop, where documents are not
hidden inside containers. The new system should enable the user to
organize documents in a way that is intuitively appealing, and is not
based on artificial constructs imposed by the nature of computer storage
of documents or two dimensional user interface displays.
SUMMARY
The disclosed system combines the computational and storage power of a
computer with an environment that is as natural as the space outside the
computer. In the space outside the computer, it's a simple matter to find
a document within a pile on a desk, scan its contents, and locate the
needed information. The disclosed system provides a similar, visually rich
environment for handling documents with a computer system. Documents may
be typed, scanned, or faxes sent by remote users. The system allows the
user to organize and browse documents in an environment that resembles the
real world of piles and papers.
In accordance with principles of the invention, there is provided a system
for displaying documents on a computer controlled display device is
disclosed. The system displays documents either in a completely free-form,
user controlled configuration or as strands, such that documents in a
strand follow a strand path. The strand path is a two dimensional line
through a three dimensional display space. The documents displayed on the
strand are known as child documents, and each strand also has a parent
document. Various constraints defining the strand are associated with the
parent document, including a strand function defining the strand path,
minimum and maximum separation constraints defining the distance between
the child documents on the strand, and an origin constraint defining the
positional relationship of the strand path to the screen object of the
parent document.
The system provides a powerful interface for manipulating documents through
a display device. The representation of documents on strands enables the
user to arrange documents on the display device in useful and intuitive
ways.
These and other features and advantages of the present invention will
become apparent from a reading of the detailed description in conjunction
with the attached drawings in which like reference numerals refer to like
elements in the several views.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a drawing of a strand;
FIG. 2 is a drawing of a strand that has been selected by a user;
FIG. 3 is a drawing of a pile and scroll tool with a strand;
FIG. 4 is a drawing of a tile strand of documents;
FIG. 5 is a drawing of a corkscrew strand of documents;
FIG. 6 is a drawing of an embodiment the system;
FIG. 7 is a drawing of a second embodiment of the system;
FIG. 8A is a drawing of a repository node having a repository interface and
coupled with repository storage;
FIG. 8B is a drawing showing the logical processes within a repository
interface;
FIG. 8C is a drawing of a repository node having repository storage in the
form of a disc drive;
FIG. 9 is a drawing of a find tool with an output strand having a knot;
FIG. 10 is a block diagram of the architecture of a document display system
using strands;
FIG. 11 is a flow chart showing the steps of a method for scheduling using
a blocked queue and an execution queue;
FIG. 12a is a drawing of an example embodiment of an attribute shown having
a name, a delimiter, and a value;
FIG. 12B is a drawing of a second embodiment of an attribute shown having a
name, a value, and delimited by parentheses;
FIG. 13 is a diagram of showing a system having asynchronous remote
repository access;
FIG. 14 is a diagram showing the steps of a find tool method for retrieving
documents from repositories;
FIG. 15 is a diagram of an apparatus for sharing a document between two
users;
FIG. 16 is a diagram of an apparatus for merging multiple documents based
on their visual display attributes; and
FIG. 17 is a diagram of an apparatus for retrieving documents from
repositories and having no busy cursor.
DETAILED DESCRIPTION
Documents
A document is the primary object in the system. All data are contained in
documents. A document contains some number of attributes, each attribute
having a name and a value. The set of attributes for any given document is
arbitrary, and no particular attributes are required of all documents.
A screen object is the visual representation of a document. It may be
visible or hidden at any given time. Screen objects are generally
rectangular.
A Unique Identifier, or UID, is a string of alphanumerics that uniquely
identifies a document. A UID is necessary and sufficient to refer to a
specific document.
Attribute Value Pairs
An attribute is a piece of data stored in a document. Each attribute has an
attribute name and an attribute value. An attribute name uniquely
identifies an attribute value within a document.
The Script Interpreter
Script consists of a scripting language that can be executed to perform
some action. It is stored in attribute values. Scripting language is a
language used to specify commands to the system environment.
The script interpreters (architecturally there can be any number) interpret
script which is stored in attributes of documents. Scripts can modify
attributes of documents, perform basic mathematical and search operations,
call other scripts, and do other basic operations such as insert or remove
documents from strands. Most of the actions in the system are activated by
calling scripts within documents.
Documents are the single abstraction structure in the script language.
There is no persistent storage associated with the script environment
other than attributes of documents. Most of the actions in the system
(other than simple dragging of documents) are activated by calling scripts
within documents. A document consists of attribute/value pairs; by
referencing an attribute in an expression, the value is returned.
The value of any attribute, ephemeral or not, may be executable script.
Script thus allows the power user to extend the functionality of the
system. For example, a user may define the value of an attribute by
writing his or her own script as the value of that attribute.
Whether an attribute is executable or not is typically established by
convention. For example, for a given implementation, an architecturally
defined set of messages may indicate that the attributes referenced by the
messages are executable. Or, a button on the mouse may be architecturally
defined to invoke and execute the script contained in an attribute of the
document in which the cursor is located when that button is clicked by the
user. In addition, or as an alternative, an identifier process can be
designed and used to determine whether the value of an attribute is
script, and also what script interpreter is needed to interpret it. The
identifier process does not test whether the script can be properly
parsed, but upon determining that the value of an attribute is script,
chooses which script interpreter to call to interpret the script. For
example, the identifier process can select an interpreter for a dialect of
the Lisp programming language by checking the first non-whitespace
character to see if it is a left paren or single-quote. If the first
non-whitespace character is a left paren of a single-quote, the identifier
process selects the interpreter for the dialect of the Lisp programming
language to interpret the script.
A goal in designing a particular script language is that the script
language be easy to read. Users may not be computer scientists, but will
nevertheless want to examine and modify scripts to a certain extent.
Therefore the language must have few special characters, and generally use
natural language words instead of symbols.
The script language should be uniformly structured, in that the only
storage entity (object) in the language is a document consisting of
attribute/value pairs. Values may be atomic, such as strings, numbers,
dates, or images, or they may be pointers (UID's) to other documents.
Global objects may be stored as attributes in a universal "global"
document which is visible to all scripts.
Attributes are generally not typed, but values are generally typed. The
types of values are used to determine what operations are permissible. A
script is executed within a document by evaluating an attribute whose
value is a script, and whose type is executable.
Inputs to the System
An example embodiment of the system includes an input device, for example a
mouse, to obtain information from the user regarding selecting and moving
documents within the display. It will be clear to one skilled in the art
of user interfaces that devices other than a mouse, such as a light pen, a
voice controlled display, or a touch sensitive screen, are potential
alternatives to the mouse.
The locations of mouse events, for example the pressing and or releasing of
a mouse button, are recorded as the UID of the document in which the
cursor is located when the mouse event occurs. The x, y or z position of
the cursor at the time the mouse event occurred is recorded. The results
of user actions to select or deselect one or more documents are similarly
recorded.
Scanning Documents
Any paper document can be entered into the system by scanning. When
scanning a document into the system, a cover sheet should be used. Each
cover sheet is encoded with the identification of the owner of the
document. Such identification would, for example, consist of the unique
user name defined within the system used to log-on or gain access to
system.
In an example embodiment, when a document is scanned into the system, the
scanned document is automatically placed in an IN BOX pile of the owner of
the document. Each scanned document has an information sticker across its
top displaying the name of the owner and the date it was scanned. The
cover sheet is not included.
Scanned documents without cover sheets, or that have cover sheets that do
not name valid users, cannot be delivered to the true owner of the
document by the system. The system may be configured to deliver such
scanned documents to a designated user, who is responsible for determining
the owner of the scanned documents.
The Visual Presentation: The Workspace
A workspace is a virtual three dimensional space in which a set of
documents are arranged. In this way a workspace contains a set of
documents. Within a workspace, there is a list of the documents contained
within the workspace, consisting of combinations of repository identifiers
(RIDs) and unique identifiers (UIDs). Also, for each document within the
workspace there exist ephemeral attributes, which describe the current
visual display of that document within the workspace. Examples of
ephemeral attributes include the X, Y, and Z positions of the document
within the workspace.
A workspace is stored in a workspace document and displayed in a workspace
window. A workspace document is a document that contains all of the state
information of a workspace. A workspace document may be contained within
other workspaces.
The display of a workspace on the display device is the "screen space"
representation of the three dimensional workspace on the two dimensional
display device. In an embodiment of the system, the screen space display
of a workspace is implemented through a window in the host computer's
windowing system, within which the two dimensional screen space rendering
of the three dimensional workspace is displayed.
The system uses a three dimensional workspace to provide a useful display
of potentially thousands of documents. A workspace may display thousands
of documents. In a preferred embodiment of a workspace, the workspace is
wrapped at the edges, giving a fish-eye lens effect, so that every screen
object that is not invisible has at least some portion of its rectangle
within the screen display no matter what its position in the three
dimensional workspace.
Workspaces may be shared, such that multiple users have the same workspace
open. For example, user one and user two could simultaneously have the
same workspace open. In one embodiment, when user one drags a document
within the workspace, user two sees it moving as well. The ephemeral
attributes defining the visual representation of the documents within the
workspace can be mediated via repository connections from user one to user
two to support this feature. For example, both user one and user two could
simultaneously read and write to a shared copy of the workspace document
within a mutually accessible repository. Alternatively, user one and user
two could maintain separate copies of the workspace document in their
respective client modules, establish a direct network connection between
them, and exchange ephemeral attribute updates via the direct network
connection.
The Renderer Process
A renderer process is an element of the system that maintains the virtual
three dimensional workspace. The renderer process is performed by various
specific renderers.
A document renderer is that portion of the system that draws inside the
rectangle of the screen object associated with each document in a
workspace. The system supports multiple renderers, and which renderer is
used for a particular document is determined by an attribute of that
document.
A workspace viewer is a process in the system responsible for outlining the
screen objects of documents within the workspace and managing the display
of selection indication. The interior of each screen object is rendered by
its associated renderer, and the workspace viewer completes the view. The
workspace viewer is also that part of the system which is responsible for
maintaining the view of a workspace. That is, the workspace viewer
contains the means for arranging documents in three-space.
Ephemeral Attributes
Ephemeral attributes are attributes associated with a document in the
context of a workspace. Ephemeral attributes are stored within a workspace
document of the workspace containing the screen object of the specific
document which the ephemeral attributes are associated with. Ephemeral
attributes define the display characteristics of the associated document,
such as position and size. Ephemeral attributes reflect the actions of the
user in manipulating the screen object of a document within a workspace,
typically through using an interface device such as a mouse.
Ephemeral attributes are stored in workspace documents, which in turn are
stored in repositories. All the state information of the last image of a
workspace, including ephemeral attributes associated with each document in
the display, is stored in the permanent attributes of a workspace document
when that document is stored into a repository. Thus a document may have
different ephemeral attributes and values when that document is associated
with different workspaces.
An ephemeral document is a document that has existence only in a workspace.
It has no permanent attributes, only ephemeral ones. In an alternative
embodiment, ephemeral documents may be stored in a virtual "workspace
repository", accessible only from its workspace, and may have permanent
attributes in this context. In such an alternative embodiment, the state
of the workspace repository is stored as an attribute of the workspace
document.
An intrinsic ephemeral attribute, or intrinsic attribute, is a special
ephemeral attribute that every document must have, which directly effects
the display of the screen object. Examples include x position (xpos), y
position (ypos) and z position (zpos). Many intrinsic attributes are
available for direct manipulation through the user interface device.
The Perspective Function
A perspective function maps objects on the screen by taking the three
dimensional workspace coordinates, or "world space coordinates",
maintained by the workspace viewer, and mapping them into two-dimensional
screen space positions.
For example, every document has a position in world space defined along the
x, y, and z axis, and every document has a width and a height. When an
image of the document is drawn on the display device, the perspective
function takes those world space coordinates and size variables as input
parameters, and determines the actual size and location on the display
device, in "screen space coordinates", where the document is actually
going to be drawn. The perspective function is instantiated by the
workspace viewer process.
Dragging Along the X, Y or Z Axis
To move a document around a workspace, there are three basic actions:
dragging around, pushing back/pulling forward, and clipping. Dragging a
document is the act of moving the corresponding screen object for that
document with respect to one or more of the x, y, and z axis of the
workspace by manipulation of the user interface device.
To move a document within the workspace, the user uses the user interface
device to place the mouse cursor near the center of screen object of the
document. The user next presses and holds the mouse button while moving
the mouse. As a result, the screen object disappears and is replaced by an
outline of its shape (called a drag box). As the mouse is moved, the drag
box follows. This is known as dragging. When the mouse button is released,
the screen object reappears in its new position.
Documents are pushed back and pulled forward via a modified drag action,
e.g. using a separate mouse button, or by first moving the mouse cursor
close to a corner of the screen object of the document, and then pressing
and holding a mouse button. As an alternative a track ball device may be
used to manipulate the position of the mouse cursor. As the mouse cursor
is moved toward the bottom of the screen, the screen object is dragged
forward (towards the user) within the workspace. As the mouse cursor is
moved toward the upper left corner of the screen instead of forward, the
screen object is pushed back within the workspace. Note that as the screen
object on the display device is being moved, the virtual location of the
corresponding document maintained in the world space of the workspace
viewer is being changed accordingly. Thus one can either say that the
screen object is being moved, or that the document is being moved, and
have the same meaning.
As a document is pulled forward, the document is moved towards the user
along the z axis of the three dimensional workspace. The perspective
process translates this movement of the object towards the user into a
screen representation of the screen object for the document. As a result,
the screen object for the document grows in size in its two dimensional
screen space representation. Conversely, when a document is pushed back,
the screen object for the document is made smaller.
A document can only be moved forward a certain distance. When it is as big
as it will get, it is plastered against the workspace window and cannot be
moved any closer.
The world space size of a screen object is the size of the screen object in
the three dimensional space of the workspace. This is the object's real
size opposed to the screen space size at which it appears on the screen
display surface. Documents and elements of documents (e.g. buttons, text
fields, etc.) all have world space sizes. Although dragging along the Z
axis can make the world space size of documents very small, they will
never be rendered at a size that is invisible to the user.
In the case of "corner dragging" in the Z dimension, any of the four
corners of a document may be used to push or pull it. However, the
document will move along somewhat different paths depending on which
corner is used.
Repositories
A repository is a data store that contains documents. A workspace is
generally used for short term storage of documents. For long-term storage,
documents are kept in repositories. When a system tool brings documents
into a workspace, it gets them from repositories. A Repository Identifier,
or RID, is a string of alphanumerics that uniquely identifies a
repository. RIDs are unique on the network. An RID is necessary and
sufficient to refer to a repository. In an alternative embodiment RIDs are
universally unique, and therefore permanently stable in a global
environment where mobile computing is increasing significant. For purposes
of example, such universally unique RIDs may be assigned through a central
RID allocation system, similar to how 48 bit Ethernet physical layer
addresses are centrally assigned to specific network controllers, to
guarantee that there are no duplicates.
The computer network that the system is connected to may have one
repository available or it may have many. Some repositories are generic
places to put documents, while others may be specialized. For example, a
machine that sends and receives documents as faxes over telephone lines
can be a repository. The user may choose to maintain a private repository
on the local computer. Most repositories are on remote machines and the
system gets documents from them over the network. A repository may exist
on the local file system. An embodiment of the system may run on a system
with no disks. In that case, all repositories exist within remote network
nodes.
The user may retrieve documents from many different repositories at the
same time. Similarly, multiple users can connect to the same repository at
once. A user of a document may put a document into a shared repository
marked to the attention of other specified users. Each user may configure
a special FIND tool (which serves as their IN BOX) that constantly watches
the repositories for documents marked for their attention and brings them
into their workspace. In this way, documents may be shared between users.
Repositories are visually represented in a workspace by a document called a
repository portal. The user accesses a repository through the repository
portal for that repository. A repository may be password protected, such
that the user may have to enter a password into the portal document before
using the repository.
Repositories may have special characteristics (unusual connection
requirements, limited hours of availability, etc.) These are represented
to the user on the portal document. Repository portals also have a visual
indication of whether their repositories are currently available for use.
A repository server is a server that serves documents from a repository to
a client and provides a search engine, and repository interface to process
search requests described by attribute value pairs from the client system,
and to search the repository using the search protocol specific to that
repository.
Strands
Strands are a system for positioning screen objects in a three-dimensional
workspace. Strands allow grouping of documents, so that they can be
manipulated as groups. Strands are a method of applying constraints to the
organization of screen objects in three dimensions.
A strand is associated with a first document (the "strand parent"), and
constrains the location of a set of documents not containing the strand
parent. A strand is a process that maps a (possibly discontinuous) line
into 3 space. Each strand child has a position on the strand relative to
the strand origin. A strand also has minimum and maximum constraints for
the spacing of its children.
Strands are not containers, but rather are a mechanism for arranging screen
objects without hiding them. A strand constrains the position of screen
objects attached to the strand into a certain shape. The certain shape is
indicated by a strand function. When the strand function is evaluated, its
output defines a strand path. A pile is an example of a strand where all
the documents attached to a strand are constrained to be next to each
other in the shape of a pile.
The strand path is mathematically defined as a one-dimensional path through
three dimensions, along which are displayed the screen objects of the
child documents of the strand. Objects attached to a strand path appear to
be indirectly connected, as do pearls on a strand of string. The strand
function can be arbitrarily set so that it is oriented in any direction or
is any complex line. It can be a complicated function like a bunch of line
segments joined together, or it could be U-shaped or zigzag-shaped.
A pile of documents is a strand having a strand path defined by a function
causing the strand to be oriented substantially parallel to the Z access
of the display, that is, going straight back from the surface of the
display device that is closest to the user. A "tile" of documents is a set
of documents placed next to each other so that the complete contents of
their current screen objects are showing. A tile is defined as a strand
having a strand path substantially parallel to the glass of the screen.
The strand mechanism itself is completely general. The user may define a
corkscrew strand path to have documents spiraling back into infinity if so
desired.
An example of a system tool having a strand is as follows. The FIND
operation may be a tool having a pile for its output. The FIND command
locates documents, and puts them into a pile below itself. The output pile
is attached to the FIND tool. When the FIND tool is moved, the pile
follows. The FIND tool will "let go" of a document if the document is
clicked and dragged away from the pile.
A strand parent is a document to which a strand is attached. The strand
path for that strand is defined relative to an origin point defined with
respect to the strand parent. For example, the strand path could be
relative to an origin in the upper left corner of the screen object for
the strand parent. Minimum and maximum separation constraints, associated
with the strand parent, define the spacing between any two child documents
on the strand to be greater than the separation minimum and less than the
separation maximum. The minimum and maximum separation constraints may for
example be stored in the strand parent.
FIG. 1 shows a display device 10, including an example of a strand 15. The
strand 15 is shown having child document screen objects 19a, 19b . . .
19e, and parent document screen object 17. The strand path is shown by
line 20, and the mouse cursor is shown by element 21. The separation of
the child document screen objects 19 is shown at 24.
During operation of the system, with reference to the elements in FIG. 1,
the strand path 20 is calculated by evaluating a strand function
associated with strand parent represented by screen object 17. The exact
orientation of the strand path 20 is determined with reference to an
origin constraint associated with the strand parent screen object 17, for
example, the upper left hand corner of the strand parent screen object 17
at point 26. The outputs of this evaluation are three dimensional
coordinates that define the strand path 20 in the virtual representation
maintained by the workspace viewer.
The child documents of the strand (corresponding to screen objects 19) are
determined from a list of unique identifiers of the child documents
associated with a strand parent document corresponding to screen object
17. The separation constraints associated with the strand parent document,
indicating the minimum and maximum separation of child documents displayed
along the strand path 20, are also evaluated. The output of these
evaluations provides three dimensional coordinates defining the appearance
and location of the child document screen objects 19 along the strand path
20.
The three dimensional coordinates are passed to a perspective process for
translation into two dimensional screen space coordinates. The two
dimensional screen space coordinates are used to display screen objects
19, representing child documents along the strand path 20, on the display
device 10. The strand path 20 itself is not typically, but may be
displayed on the display device. The separation 24 between the child
documents cannot exceed the maximum separation constraint, and is not less
than the minimum separation constraint associated with the strand parent
document corresponding to screen object 17.
Strand parents may further include a knot constraint, defining points in
the strand that divide the strand into sub-strands. Knot constraints may
be arbitrarily defined, and are generally invisible to the user. For
example, knot constraints may be used to subdivide the strand into two
sub-parts so that the user has a pile of mail that has been read, and a
pile of new mail, both within a single strand. Knots are used to keep
those sub-strands (or sub-piles) separated.
Two applications for strands are presentation of documents in piles or
tiles, and grouping documents. A strand is an object on the display
device, and the user can pick up the strand by using the mouse to select
the parent document of the strand. All of the strand's children are moved
when the strand itself is moved. The system may be configured such that
when the user selects a child document on the strand and moves it, the
document is removed from the strand. In the alternative, the system can be
configured such that moving any child document on the strand causes the
entire strand and all other documents on the strand to move without
removing the child document from the strand.
In the example shown in FIG. 1, the parent document corresponding to screen
object 17 is a FIND tool. For example, the FIND tool may be used to locate
documents containing a particular string of characters. When the FIND tool
is used, the documents found to contain the string are displayed along the
strand 15, in this case, a pile. The FIND tool is the parent of that
strand. When the screen object for the FIND tool is moved on the display
device, the pile is dragged with it.
In FIG. 2, the elements shown in FIG. 1 are shown after the user has
selected the screen object 17 of the strand parent for the strand 15.
While the strand parent screen object 17 is selected, the user has also
selected the entire strand 15, including child document screen objects 19.
The strand parent screen object 17, and the child | | |
