A bit about me...

• Visiting Researcher, Aarhus University, July 2005 to July 2006
• Associate Professor, University of Colorado, Boulder, July 1998 to Present
• Received Ph.D. at University of California, Irvine in 1997
• Research Interests:
  • Software Engineering
  • Open Hypermedia (Chimera)
  • Structural Computing
• Have been working on hypermedia since 1991, first demo at Hypertext'93
• Watched the “birth” of the Web occur while sitting across from Roy Fielding at UCI

University of Colorado at Boulder

Come Visit!

Classical Systems: What are they good for?

• The systems discussed today are either extinct or receiving only limited use
  • But that does not mean that they are irrelevant!
• They introduced many important concepts to the field of hypermedia:
  • External Link Databases
  • Sophisticated Anchoring
  • Graphical Browsers (Putting the MEDIA into hypermedia)
  • Cooperative Work
• They also illustrate different approaches to hypermedia in contrast to the Web
  • For Example: KMS has basically the same hypermedia model, but is quite different!

System Papers: Similar Characteristics

• All three papers this week are “system description” papers with several similar characteristics
  • discussion of system architecture, UI, and use
  • discussion of hypermedia design issues
• These types of papers are extremely useful to (system) designers and get better as your expertise goes up (!)
  • Fred Brooks' The Mythical Man-Month is similar for software engineers
• This lecture will first look at the systems, do some comparisons, and then return to the design issues

Overview

• System Descriptions
  • KMS
  • Intermedia
  • StorySpace
• Comparisons
• Hypermedia Design Issues

KMS: Background Information

• KMS is a commercial version of a research system called ZOG that was created at CMU.
  • ZOG was developed and used at CMU from 1972 to 1984.
  • The first version of KMS appeared in 1983.
• ZOG helped to create some of the largest (pre-Web) hypermedia structures
  • It was used as the documentation system for the USS Carl Vinson providing more than 20,000 frames of information.
  • It ran on 28 PERQ workstations, which were one of the first commercial graphical workstations available on the market.
• Rob Akscyn
  • Significant member of the ZOG and KMS design team
  • Director of Knowledge Systems, the company that commercialized ZOG
  • Has been active in the Hypermedia field for over 30 years!
  • General Chair for the 1998 Hypermedia conference
    • I was the Co-Chair for Demos and Posters at that conference, so Rob was my boss for that event! :-)

KMS Data Model: Frames

• A KMS database consists of a set of interlinked frames
  • Therefore, Frames = Nodes in this model.
• There is only one type of frame and it can consist of any number of text, graphics, and image items. Each item can be linked to another frame or be used to invoke a program
• A typical screen displayed two frames side by side, however it was possible to display just a single frame. Frames were fixed to a side of 1132 pixels wide by 805 pixels high. These numbers were influenced by the size of the screens available in the 1980s
• Frames, on average, contained two paragraphs of text and were 1KB in size
• KMS did not allow scrolling, the entire frame was displayed at once

KMS Data Model: Frames, continued

• Frames are assembled into a hierarchy via links (tree items)
  • Tree items establish one-way parent-child relationships between frames
  • When navigating down a tree, the KMS “back” command allows users to traverse back up
  • KMS apparently offers a way to go back up a hierarchy after following an associative link but the paper does not provide enough detail about this mechanism
• Related frames are known as frame sets
• A KMS database can contain many frame sets (as many as available disk space allows)
• KMS programs typically took frame sets as input and produced frame sets as output

KMS – screen shot

KMS Data Model: Links

• KMS does not have a first-class link object in its data model
• Instead, links are a property (i.e. attribute value) of an item on a frame
• Three Link Types: “tree item”, “annotation item” & “action item”
  • Tree items are indicated with the ° symbol
  • Annotation items are indicated with the @ symbol
  • Action items are indicated with the • symbol
• Link Creation
  • Invoking the “traverse” command on an unlinked item caused a new frame to be created and the item was now linked to this new frame
  • To link to an existing frame, one would find an item that already linked to it, copy its link property, and paste the link property onto another item
• Link Traversal
  • Clicking the left mouse button on a linked item invoked the “GoTo” on the item and caused the target frame to be displayed or the target program to be invoked. (This behavior should be familiar to anyone who has used a Wiki.)
  • On average, it took KMS < 0.25 second to find and display a new frame; the paper reports that an experiment revealed that speeds faster than that could lead to confusion in the user, as the human visual system could easily miss the frame update and trick the human into thinking the traversal had not yet occurred!

KMS Data Model: Actions

• KMS provided an interpreted scripting language, similar to JavaScript
• Any item could have an action associated with it
• Actions could even call commands from the host operating systems
  • This could be used, for example, to create documents based from frames and send them to the printer
  • KMS provided just such a program called “linear” which performed a depth-first traversal of a frameset
  • Formatting commands could be placed on frames to influence the output of the linear command
• Actions were also used to implement KMS's query functionality
  • Queries provided free text search over the entire KMS frame hierarchy
  • The results were given in the form of newly created frames that had items that linked to frames that matched the search query

Other Features of KMS

KMS: Design Rationale

• Navigation and overview without a graphical browser
  • Standard frame Layout (Critical!)
  • Large items to serve as anchors
  • Fast traversal and backtracking
  • Consistent marking of link types
  • “No editors”
• Frames limited to screen size
  • Quick access
  • Encourage utilization of entire frame
  • Enables optimistic concurrency control
  • No scrolling
• User interface designed for three-button mouse
  • gives access to 90% of commands via the mouse
  • WYSIWYG
  • Context sensitive cursor

Overview

• System Descriptions
  • KMS
  • Intermedia
  • StorySpace
• Comparisons
• Hypermedia Design Issues

IRIS and Intermedia

• Brown University, Institute for Research in Information & Scholarship (IRIS)
• Intermedia was used extensively at Brown University to support work by students in its literature and biology classes
• It provides a “object-oriented framework” for creating hypermedia applications
• Intermedia was first implemented on conventional Unix work stations, and then later moved to Apple Unix (long before MacOS X) with support from Apple.
• After work on Intermedia ended, its development group split and went in different directions
  • Meyrowitz, for example, went to GO Inc., where he helped build linking facilities into the operating system of their PDAs

Intermedia: Data Model

• Node → Intermedia Document
• Corpus: a group of Intermedia documents
• Link → Bidirectional link object with two end points
  • Created using “Start Link” and “Complete Link” commands
  • Two link types: relation (primary) and reference (secondary)
• Anchor → Block
  • A block is a region of interest within a document that can serve as the endpoint of a link traversal
  • “Any selection” could be made into a block (a point, a region, an entire document)
  • A block would “stick to” its information as a document was edited
• Link markers → appeared as small icon within a document after a block
  • Link traversal invoked by double clicking icon or invoking the “follow” command
  • Multiple links could be associated with a block; however only one link marker would appear in these situations. When traversal was invoked on such a link marker, a menu would pop up showing the available links
• Web: a set of links and blocks
  • Link and block information is stored separate from a document's contents
  • Webs are stored in a conventional database
  • Webs provide a way to create a context for a document and have only links relevant to that context appear during browsing
  • The same document can participate in many different contexts; different links become available by switching among different webs
  • This functionality was a precursor to similar functionality that appears in later open hypermedia systems

Intermedia – screen shot

Intermedia – screen shot

Intermedia: Other Features

• Dangling Links
  • i.e. links that point to a deleted document; e.g. the Web's “404 Not Found” error
  • In Intermedia, all links to a deleted document are deleted
  • However, block markers attached “to the other end” of those links remain; so its possible to encounter a block in a document that has no links attached to it
• Attributes
  • Links and blocks had several associated attributes including user id and creation time and users could add user-defined attributes as well
  • In addition, users could associate keywords with links and blocks that could be used to find them later via Intermedia's query mechanism
• Queries
  • Document and Link attributes could be used to formulate search critera
  • The search results would then link to all found documents
  • When the result of a query was a link, the search result linked to the link's source block
• Browsers: Local and Global Maps
  • Local maps show how the current document links to its nearest neighbors
  • Global maps showed all links in the current web
• Support for Cooperative Work
  • Multiple users can follow and create links in the same Web
  • Intermedia provided read, write, and annotate rights on documents and Webs
  • The annotation right allowed a person to link to a document but not otherwise change it

Intermedia Framework

• Framework provided a set of different editors (InterText, InterDraw, InterSpect, InterMail, etc.) with a single user interface for linking across all of them
• Framework also provided a consistent user interface with respect to the mouse, menus, copy/paste, toolbars, styles, etc. across all Intermedia applications
  • a special feature at that time was that the Intermedia framework provided support for multiple undo/redo
• A feature “ahead of its time”: Framework provided an Intermedia layer over MacApp (an old Macintosh application framework)
  • the layer implemented link creation/following AND link markers for all MacApp-based editors
  • automatically stored link and anchor information in relational database for these applications

Intermedia: Timeline

• Used by many teachers and students at Brown
  • Indeed, in literature classes, successive generations of students would build on the Webs created by previous generations
• Webs were created with many thousands of links
• Project started in the mid-1980's
• Intermedia paper from 1988; just one of many
• Project finished in the early 1990's

Overview

• System Descriptions
  • KMS
  • Intermedia
  • StorySpace
• Comparisons
• Hypermedia Design Issues

But First... Some Background

• Hyperfiction
• Adaptive Hypermedia
• Adaptive Hypermedia Systems

Hyperfiction (Hypertext Literature)

• We usually look at hypermedia systems aimed at supporting knowledge work
  • structuring of large bodies of information
  • news
  • technical documentation
  • etc.
• In such systems efficiency, overview, and consistent behavior are essential and necessary
  • there are limits to how many surprises you want from a tool
• Hyperfiction is different
  • the purpose is an (aesthetic) experience
  • the reader is engaged in “discovering” a story and will gradually uncover the text, and does not necessarily possess an overview
  • the text is not necessarily static, but may change as the result of the reader's actions
  • indeed, surprising the reader may be the author's goal!

Adaptive hypermedia

• Hypertext documents and/or web sites are often fully connected, and all links are available at all times (we hope)
  • Some websites are written by people with deep domain knowledge and they have no problems handling the whole site at once
  • However such sites may be confusing to domain novices, who may need guidance and limits in order not to become “lost in hyperspace” (or just lost)
  • These users would be helped by a site that gradually opened to them as they learned more
    • an obvious application is educational systems, such as digital libraries for children
• Related to Hyperfiction in that the users of these sites are engaged in a dynamic process with the site; its not just static reading, rather the content of the site is dynamic based on what the reader does

Adaptive Hypermedia: Continued

• One solution to this need for adaptive hypermedia is adaptive hypermedia systems
• These systems adapt to a user as they browse and read the site
• This is done by maintaining a model of the user's actions in the system as well as a model of the user's likely prior knowledge
  • which links has the user followed?
  • which text fragments has the user read?
  • what knowledge does the user already possess?
    • This might be ascertained, for example, by having the user take a test of some type while at the site
    • ... or having the user declare a skill level upon entering the site.
  • what knowledge has the user acquired during the session?
• This poses some new demands on the hypertext author
  • hypermedia structure and rhetoric become very important
  • the hypertext will often divide the text up in many small fragments
    • though the text will not be presented as fragmented to the reader
    • ... instead the models will determine how the text is combined to best match the user's needs

Storyspace: Background

• One of the oldest, active hypermedia systems
  • Has seen continuous use and development since 1987!
  • A product of Eastgate Systems, the dominant provider of Hyperfiction
• Mark Bernstein
  • one of the most active person among the “hypertext litterati”...
  • but also an active hypermedia system developer
• StorySpace has been used to write a lot of Hyperfiction (visit Eastgate's website to get a sense for how much)
• Of course, you can also find (and write) Hyperfiction on the WWW... but commercial work tends to be done in StorySpace

StorySpace: Characteristics and Hypermedia Model

• Monolithic hypermedia system
  • however, StorySpace is not meant to be a generic hypertext system, so this is not necessarily a “bad thing”
• Two different versions of the application: author and reader
  • The authoring environment can be used to create and read hypertexts
  • The StorySpace browser can simply read hypertexts and is often used to deploy commercial hypertexts by Eastgate Systems
• Nodes
  • “writing spaces”: denoted by a rectangle in the map view with an associated text document
  • each writing space can play host to other writing spaces, creating a parent-child hierarchy
• Links
  • Bidirectional link object with two end points (called spans)
  • Connects span to span or node to node
  • Represented as a first-class link object BUT stored with the content of the hypertext in a single file
  • A somewhat unique feature: guard fields (discussed soon)

StorySpace Views

• Different Representations of the Hypertext
  • outlines
  • charts
  • treemaps
  • Storyspace map
    • The primary view; the one where “day to day” work is done

StorySpace Links

• As mentioned above, links are stored external to the node but internal to the hypertext
• Link names are required, and some authors have even used link names as yet another place to write their stories (!)
• Link Markup
  • the presence of links are hidden by default(!)
  • a user can press a key combination to have them revealed
  • such a choice, allows the reader to read the text without being distracted by links until they are ready to move on
• Default Link
  • “The default link is the first basic link in the list of links from the space that is not blocked by its guard field.” From the StorySpace 2 Manual
  • Default links provide an initial path through the hypertext for a reader
  • Activated by clicking <return>

Guard fields

• Provides the ability to add dynamic behavior to a StorySpace hypertext
• They are simply a text attribute associated with a link (that specifies a boolean condition) that governs whether the link can be followed
• Examples
  • "help" : link cannot be followed until reader has visited the "help" writing space
  • ~"top secret" : link can only be followed if the reader has NOT visited the "top secret" space
  • hypertext|hypermedia : link can only be followed if the reader has selected either of the two words listed
• See StorySpace manual for complete syntax and additional examples

Maps

• The primary method for working with story space (demo)
  • create and arrange writing spaces
  • create and manipulate links
  • manage the hierarchical arrangement of spaces
• The size of a hyperfiction can become quite large, and without the map it can become very difficult to keep track of everything
• Authors will sometimes use the map as “yet another writing space” hiding stories in the space's names and making pictures out of the way spaces are arranged.
• Note: authors will sometimes disable the map view for their readers, especially if they want to hide the structure of the story from the reader
• At one point, StorySpace offered the ability to layout the spaces automatically; this feature was universally hated!

Experience

• In general, a very powerful system that has been used to create a lot of hypertext fiction
• Developer has kept the system backward compatible with older versions to allow people to read “old” texts
• Funny (and enlightening) support stories and stories about authors using the tool in unexpected ways
• Hypertexts created in StorySpace are heavily linked, suggesting that its map view encourages authors to be brave about linking their text fragments

Overview

• System Descriptions
  • KMS
  • Intermedia
  • StorySpace
• Comparisons
• Hypermedia Design Issues

Comparisions

• Its important that we compare these systems to one another and to the Web to reflect on where we've been and where we'd like to go
• All three systems are
  • closed: at least to other systems; you can always import data into them, but they cannot export hypermedia services
  • monolithic: systems are single application images, with no decomposition to address unrelated services
  • but simple, powerful, and used by lots of people for lots of different tasks
• Data Model Comparision

  	KMS	Intermedia	StorySpace	World Wide Web
  Node	Frame	Document	Writing Space	HTML Document
  Anchor	Item	Block (able to be associated with multiple links)	Span	"a" tag
  Link Marker	Icon	Icon	Box (hidden by default)	underlined text (controlled by stylesheet)
  Link	Property of Item (unary pointer)	External Binary First Class Object (stored in Webs)	Binary First Class Object (stored with node data)	Property of "a" tag (unary pointer)
  Node Groups	Frame Sets	Corpus	Maps	None
  Link Groups	None	Webs	None	None
  Dynamic Link Behavior	Yes: Actions	No: Just Traversal	Yes: Guard Fields	Some: via Javascript
  Collaboration Support	Yes	Yes	No	Can be added

• Support for collaborative editing of nodes and links by KMS and Intermedia stand in stark contrast to the standard design for the World Wide Web
  • First version of Web was “two way” with support for viewing AND authoring via Web browser
  • Unfortunately, this support existed only in a Web browser written by TBL for the NeXT platform and was not distributed widely
  • With the advent of the “browse-only” Mosaic browser, it took the Web (standards community) six years to begin to address the issue of authoring once more

Overview

• System Descriptions
  • KMS
  • Intermedia
  • StorySpace
• Comparisons
• Hypermedia Design Issues

Hypermedia Design Issues

• By now it should be clear that when designing a hypermedia system, you need to tackle
  • Definition of Node, Anchor, Link
  • Are links external?
  • Support for Authoring
  • Support for Reading
  • Dynamic Behaviors of System
  • How open is the system to
    • external data
    • other systems
    • what information it imports and what it can share
    • what services it provides
  • Support for Collaboration

Summary

• Classical Hypermedia Systems
  • “Best of Breed” systems in their categories
  • All of these systems are “closed” and monolithic
• Good examples of systems, where the design is clearly targeted towards specific goals
  • KMS
    • Quick performance and efficient use
    • Very simple design that nonetheless addresses a large range of user needs
  • Intermedia
    • Rich media types
    • Multiple webs provide support for multiple students working on the same materials
  • StorySpace
    • Author Workspace
    • Rich functionality (not necessarily used by all users)