NoteCards

• Developed by a team at Xerox PARC
• To support the task of transforming a chaotic collection of unrelated thoughts into an integrated, orderly interpretation of ideas and their interconnections
• Designed for use by individuals or small work groups
• A general purpose hypermedia system, but originally designed to be used as a tool for idea processing and authoring in a research environment

• A general hypermedia environment that is fairly typical of the generation of workstation-based systems.
• The system provides the user with a network of electronic NoteCards interconnected by typed links.
• This network serves as a medium in which the user can represent collections of related ideas.
• The network also functions as structure for organizing, storing, and retrieving information.
• The system includes facilities for displaying, modifying, manipulating, and navigating through the network.

• Implemented within the Xerox Lisp programming environment
• Two primitive constructs: notecards and links
• Notecards
• Electronic generalization of the 3X5 paper notecard
• Links
• Typed, directional connection between a source card and a destination card
• Two types of cards: browsers and filebox
• Browsers
• Notecards that contain a structural diagram of a network of notecards
• Fileboxes
• Specialized cards that can be used to organize or categorize large collections of notecards.

Halasz examined the major weaknesses in the design of NoteCards

Issue 1: Integration of Search and Query Functionality
 

• Navigational access by itself is not sufficient
• Effective access to information stored in a hypermedia network requires query-based access to complement navigation
• Content search: all nodes and links of the networks are considered as independent entities and are examined individually for a match to the given query. Ignores the structures of a hypermedia network
• e.g. all the nodes containing the string "hyper*" would be a content query
• Structure search: Specifically examines the hypermedia structure for subnetworks that match a given pattern.
• e.g. "all subnetworks containing two nodes connected by a "supports" link, where the destination node contains the word "hypertext." This query contains a description of node content (i.e., contains the word "hypertext"). But it also contains a structural description of a network (i.e., two nodes connected by a "supports" link.

• Need container or collection nodes in addition to content nodes
• NoteCards only have two primitive constructs: cards and links
• Fileboxes and browsers are built up from those constructs
• Lack of a composition mechanism, i.e., a way of representing and dealing with groups of nodes and links as unique entities separate from their entities.

• Hypermedia: essentially static and fragmentary nature of the hypermedia model
• Hypermedia systems have difficulty with rapidly changing information
• The network cannot reconfigure itself in response to changes in the information it contains.
• Lack of dynamic mechanisms limits the utility of hypermedia in many domains
• Nodes and links are extensionally defined: nodes and links are defined by specifying the exact their components.
• Virtual structures are defined intentionally: by specifying a description of their components
• The exact subcomponents of a virtual structure are determined by a search procedure whenever the structure is accessed or instantiated
• e.g. A virtual composite node might be defined by a specification of the form: a subnetwork containing all nodes created by someone other than me in the last three days. Each time this composite was accessed, its structure and content would be recomputed
• Notion of virtual structures for hypermedia is a direct adaption of the concept of views (a.k.a. virtual tables) in the world of relational database systems
• Notion of virtual structures in hypermedia would be possible only in a system that support a substantial search/query mechanism over the hypermedia network
• A virtual composite allows the user to create nodes that are dynamically constructed at access time form other nodes, links, and composites that are stored in the network

• Hypermedia systems are generally passive storage and retrieval system.
• Hypermedia systems do not actively direct the creation or modification of the network or the information contained therein
• e.g. Unlike expert systems, hypermedia systems don't include inference engines that actively derive new information and enter it into the network
• e.g. Integration of hypermedia and AI technology is an interesting direction to explore.
• Hypermedia systems -> heavyweight entities (whole documents), inter-entity references (links)
• Object-based systems -> define type (class) hierarchy for entities, operations (methods) that can be performed on instances of each type.
• Frame-based systems -> inheritance, defaulting of slot values, integration of truth maintenance, inference engine, rule-based reasoning with frame representations

• A good versioning mechanism will allow users to maintain and manipulate a history of changes to their network.
• Lack of versioning has a lesser impact in the authoring, argumentation, etc.
• Two levels of versioning
• Individual entities: nodes, links, composites
• Each entity has its own version history.
• e.g. composites have a problem of propagating version changes from subcomponents to their composites
• Entire hypermedia system

• Hypermedia is a natural medium for supporting collaborative work. Creating annotations, maintaining multiple organizations of a single set of materials, and transferring messages between asynchronous users are the kind of activities that form the basis of any collaboration
• NoteCards was originally designed as a single user system.
• Most idea processing and information management tasks are inherently collaborative, with groups of two ten people working on a common project
• Two important mechanisms to improve support for collaborative work
• Mechanism of simultaneous multiuser access to a common network
-> sophisticated , shared database, concurrency control
• The social interactions involved in collaboratively using a shared network
-> notify what the other people are doing, update a node, etc.
-> "mutual intelligibility"-- each participants must have some degree of understanding of the actions and intentions of any collaborators
-> "procedural activities" -- decide how to distinguish additions and deletions as the draft is passed back and forth

• Hypermedia model provides a set of very general abstractions: nodes, links, composites
• Users have to apply these abstractions to their tasks.
• Generic future of hypermedia has a blessing and a curse
• Blessing: allow hypermedia to be useful in a variety of task domains
• Curse: generic hypermedia is not particularly well suited to any specific task or style of use
• Needs enough examples
• Programmer's interface is needed to extend and tailor the system.
• Goal: easy for non-programming users
• Good example: GNU Emacs, Apple HyperCard/HyperTalk
• Built around an interpreter for a fully-functional programming language that is specially designed for the kind of objects and operations by the systems