Shareware Overload/ShartewareOverload.cdr/games/hyper.zip/FILE22

Text File | 1988-02-01 | 10KB | 164 lines

                   What are the general problems with hypertext?
                   =============================================

The current collection of some 20 hypertext programs, both for personal
computers as well as mainframe computers, includes a number of obvious
faults.  In my mind, the design flaws seem to center on:

          ┌───────────────────────────────────────────────────────────┐
          │  - mouse selection        -  pictorial formats            │
          │  - page framing           -  non-hierarchical structures  │
          │  - database indexing      -  network browsing             │
          └───────────────────────────────────────────────────────────┘

Here's what I think is wrong with these concepts in hypertext.

MOUSE SELECTION:   One common misconception is that hypertext requires a
================   mouse.  In graphic selection (pointing to segments of
                   diagrams or drawings), a mouse is superb. However, for
                   routine selection among a fixed set of objects (e.g.,
                   keys on a keyboard, items on a list, levels in a
                   display), the keyboard is from three to 20 times faster.

                   To experienced users, the actions of fingers on a
                   computer keyboard <FILE25 KEYBOARDS> more closely resemble
                   parallel processing -- with key selection using fingers
                   alone, being many times faster than mouse selection. That's
                   why my vision of hypertext emphasizes keyboard selection
                   over mouse selection in choosing among several hypertext
                   branches.

PICTORIAL FORMATS: Another popular misconception of hypertext is the
=================  emphasis on windows, with flawed thinking about page
                   layering and button linking.

                   The first problem in pixel formats is page construction
                   time.  In the time required to create a suitable drawing
construction time  in pixel formats, you could create perhaps 100 ASCII
                   format hypertext frames (text alone).

                   Picture hypertext (pixel page formats) typically require
                   10-20 times as much disk space ASCII text.  For example,
storage space      we recently shipped on three disks a large ASCII format
                   hypertext system containing several thousand nodes, links,
                   and screens.  If instead we used window and pixel
                   formats, the same three disks would have held less than
                   100 screens.

Worlds of          In the world of material suitable for hypertext (laws,
knowledge          specifications, ruling, depositions, articles), the most
                   of such knowledge is in text format, not by pictures,
                   diagrams, or graphics.  While a picture may be worth
                   1,000 words, textual knowledge (e.g., law, medicine, and
                   accounting) exceeds diagram-form knowledge perhaps by a
                   ratio of 1,000,000 to one.  <FILE54 KNOWLEDGE>

                   Many PC users still have systems that are ill suited to
                   the evolving operating systems and hardware required for
                   pictorial hypertext.  Standards in picture formats,
                   memory/cpu requirements, and compatibility are not yet
                   stable.  For example, your 1989 scheduled PC-windowing
today's computers  hypertext system including the full implementation of
                   OS-2 will probably require 4 megabytes of memory.  In
                   contrast, ASCII hypertext easily runs on a minimal
                   current system (i.e, minimum 256k memory -- 10-megabyte
                   hard disk).

PAGE FRAMING:      Another major flaw in many current hypertext systems is
                   in organizing ideas into screen-size units instead of by
                   idea units.  Screen-size units inhibit link construction
                   and also foster difficulties in button binding that
                   idea-unit framing avoids.  <FILE28 FORMAT>

                   In link construction, I build branching points in
link construction  hypertext decision trees perhaps 10 times faster when
                   linking directly to idea units instead of putting
                   buttons on a screen.  In addition, I can rapidly merge
                   and divide my idea units in ways that are impossible to
                   manipulate with screen-based hypertext.  <FILE64
                   METHODS>

                   While appearing functional, the buttons in some systems
                   have no binding to the ideas on the screen.  For
button flaws       example, in Apple's HYPERCARD, if you place a jump
                   button on a particular word to edit the text so that
                   the marked word is moved, the button falsely identifies
                   another word as the jump point to the original word.  The
                   branching methodology is not in any way coupled to the
                   idea units.  That's simply an invitation to dead-end
                   pointers.

NON-HIERARCHICAL   Many implementations of hypertext have their roots in
APPROACHES         what has become known as "Xerox envy."  The Xerox
                   NOTECARDS system overemphasized the jump button and
                   graphic screen formats while neglecting hierarchy and
                   taxonomy features.

lost in            The current hypertext systems rooted in NOTECARD
hypertext          formats invariably provide a "lost in space" experience.
                   Pictorial browsing systems easily fall into
                   spaghetti-like labyrinths of links (great for game
                   trekkies, but scarcely functional elsewhere).  In
                   contrast, ASCII hypertext with its central emphasis on
                   obvious hierarchies and taxonomies is much better
                   suited for both rapidly finding information and
                   communicating the overall structure of the knowledge
                   contained therein.

DATABASE INDEXING: Hypertext centers on two ideas: indexing information by
                   idea content and rapid access to such information
                   regardless of the user's level of understanding.

database or        These goals cannot be achieved using conventional
hypertext?         database approaches.  Yet, behind the flash of many
                   hypertext systems, you'll find only database methodology
                   of keyword searches and relational processes.  There
                   are several major problems inherent in database
                   methodologies: words versus ideas, presumed knowledge,
                   set intersections, and synonyms.  <FILE23 PROBLEMS>

indexing ideas?    The process of indexing words simply does not index
                   ideas.  Ideas are larger units and hypertext systems
                   that index ideas tend to be superior (in both usefulness
                   and speed) to database approaches that index only words.

relational or      Databases use relational methods.  These methods
hierarchical       presume a knowledge of the language of the field and
access?            usage of set intersection techniques with the language.
                   If you are unfamiliar with either, you simply can't
                   extract information from the system.  That's the reason
                   why hypertext exists -- it overcomes many of the
                   deficiencies found in relational databases.

NETWORK BROWSING:  One of the more fanciful approaches to hypertext
=================  browsing consists of automatically displaying on the
                   screen the network of relationships between items within
                   the system.  This approach presents problems in
                   utilizing the capabilities of the hardware, the user,
                   and the system.

limits of          In a typical network of 30 screens, there are a
displays           possible 900 links between such items.  Displaying this
                   network on a screen (or most subsets of this) provides
                   little user understanding of the system.  Neither the
                   screen, the operating system, nor the user are matched
                   to the task.

                   Whereas some hypertext systems use visible network
the heart of       displays, I believe the PC-Hypertext approach offers
hypertext          better methods for both browsing and communicating the
                   structure of the knowledge within the hypertext system.
                   At the core, that's the art and craft of hypertext
                   regardless of the hardware and software -- communicating
                   and confirming structure with each piece of information.

As for a conclusion, the design of all software (including PC-Hypertext)
focuses on tradeoffs <FILE17 DESIGN>.  From my viewpoint, until the
capacities of both floppy and hard disks are increased, this format of ASCII
hypertext has many advantages over graphic forms of hypertext.

Neil Larson  1/16/88  files22
44 Rincon Rd., Kensington, CA  94707
Copyright MaxThink 1988 -- Call 415-428-0104 for permission to reprint