home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / alt / hypertex / 749 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  9.9 KB

  1. Path: sparky!uunet!dtix!darwin.sura.net!spool.mu.edu!agate!linus!alliant!mydual!olson
  2. From: olson@mydual.uucp (Kirtland H. Olson)
  3. Newsgroups: alt.hypertext
  4. Subject: Re: Interaction with a hypertext (long > 200 lines)
  5. Message-ID: <1992Sep11.181338.4271@mydual.uucp>
  6. Date: 11 Sep 92 18:13:38 GMT
  7. References: <1992Sep6.224648.3218@memstvx1.memst.edu>
  8. Reply-To: olson%mydual.uucp@alliant.com
  9. Organization: The Harvard Group, 01451-0667
  10. Lines: 198
  11.  
  12. In trying to create hypertexts, I've seen some of these problems as
  13. well.  I use HyperRez by MaxThink as a test bed, and that means I don't
  14. have typed links or nodes--if I need them I must build them.  Thus my
  15. experience differs from that of using an integrated system.  I find this
  16. an advantage because I am forced to meet every issue head-on and thus
  17. increase my understanding of the organizational issues.
  18.  
  19. I'd like to see more discussion of these issues in this group, and I
  20. would welcome *any* comments on the notes I've added to Mark's
  21. commentary.  
  22.  
  23. In article <1992Sep6.224648.3218@memstvx1.memst.edu> langston@memstvx1.memst.edu (Mark C. Langston) writes:
  24.  
  25. >  The recent discussion of active v. passive hypertexts (HT's) piqued my
  26. >interest.  I am doing R&D on educational hypertexts, and would like to 
  27. >incorporate the user into a more active role during navigation, along the
  28. >lines of annotation.  Several issues come to mind:
  29. >
  30. >* If the HT structure is theory-determined or research-determined...
  31. >  a strong indexing/inference engine would need to be incorporated into
  32. >  the sytem to correctly link user annotations/additions.
  33. >
  34. >* If user after user after user annotates a particular HT, the possibility
  35. >  arises that most of the accesible information (via the HT) will become
  36. >  embedded in the annotations, and the HT will become redundant and linear.
  37.                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  38. I see how the HT gets redundant with many annotations by different people,
  39. but I don't see the linearity issue.  
  40.  
  41. >>*Allowing multiple annotations increases the amount of user-irrelevant
  42. >  material present on any one card or screen, and increases the linearity
  43.             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^
  44. If the system maintains typed links (as you later suggest) the
  45. irrelevant material would be on the target screen, not the source
  46. screen, so the link system must organize the kinds of relevance. 
  47.  
  48. Sorry to be so dense about the linearity, but I don't grasp that issue.
  49. I cannot imagine what I would do to linearize something that started out
  50. with an organization that could not be drawn on a plane without crossovers.
  51.  
  52. >* Allowing multiple annotations increases the amount of material in general
  53. >  accessible from any one card, and again increases the linearity of the HT.
  54.    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  55. Yes, but in how many jumps?  Imagine a sheet of graph paper where the
  56. intersections of the lines represent nodes and the lines represent
  57. links.  To move from one node to another, I must follow the lines.  
  58.  
  59. When I arrive at a node, it either contains the thought I sought, or it
  60. does not.  I can investigate it's four neighbors to see if the idea is
  61. there. Paths which move away from what I seek, I reject.  I should now
  62. see the "line of reasoning" along each of the two orthogonal paths.  If
  63. neither line will take me where I want to go, I have a line of reasoning
  64. that must be added.  Adding a line of reasoning adds a dimension.  Now I
  65. must have many sheets of graph paper, one above the other, and move
  66. between sheets.
  67.  
  68. Thus I believe that adding comments must increase, not decrease, the
  69. dimensionality of a hypertext.  I will add to the amount of material
  70. accessible from any one node, but the reader will only follow the "line
  71. of reasoning" corresponding to the reader's current interest.
  72.  
  73. In this organization, no diagonal links are allowed.  The relationship
  74. of two remote nodes is built into the structure.  Adding a relationship
  75. means adding a line of reasoning (which may connect existing nodes in a
  76. new way) that the system must maintain as a new and separate line.
  77.  
  78. I think of these lines of reasoning as *threads* and consider hypertexts
  79. to be *multiply threaded* as opposed to the single thread of a short
  80. printed text.  The system may be sparsely populated, as in a novel where
  81. the unities of time, place, etc. form threads underlying the story, but
  82. the author presents the "nodes" in one chosen order.
  83.  
  84. >* Allowing dynamic node creation for indexing of end-user annotation opens the
  85. >  door to computational explosion on number of links.
  86.            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  87. In the system I describe, the number of possible links is known at the
  88. outset from the number of permissible threads.  Each node connects to
  89. two others along any thread, there are T threads, and adding a node adds
  90. 2*T links. Adding a thread adds 2*N links where N= Number of nodes. 
  91.  
  92. >How would one rectify these problems?  [stuff deleted]
  93.  
  94. I believe one needs a system that maintains the threads separately,
  95. maintains a sense of order along each thread, finds targets within a
  96. node, and differentiates next and previous from forward and backward. 
  97. One also needs an authoring system that maintains the threads and their
  98. permissible values--visible to the author or annotator--and
  99. automatically places the node at the intersection of the values along
  100. each thread.  
  101.  
  102. Also, the writer must be trained to write in this context.  Conventional
  103. writing training prepares one to write on paper and teaches tools to
  104. create coherence in a *fixed* sequence.  When the sequence of paragraphs
  105. can vary, conventional writing techniques provide no useful guidance
  106. about structure.  In fact, if I postulated link types of "because,"
  107. "consequently," and "for example," even paragraph structure rules might
  108. get bent. 
  109.  
  110. >One could assume
  111. >unlimited storage/computational power, but I'm focussing on smaller
  112. >systems.
  113.  
  114. Systems don't need to maintain empty boxes.  Rather than create all the
  115. boxes and fill some, one can tag the material with it's conceptual box
  116. and use the engine to maintain the virtual organization.  One must
  117. resolve the issue of fullness--if the system is less than half full, the
  118. tagged material concept saves space, if the system is more than half
  119. full, the empty boxes cost less.
  120.  
  121.  
  122. >...the end user has difficulty following the
  123. >coherence of the links between keyword/card, since these are based on the
  124. >programmer's assumptions of coherence, and not the user's....
  125.  
  126. All communication suffers this problem.  Hypertext offers the
  127. possibility of multiple threads to reduce the problem, but the author
  128. always chooses the purported coherence.  For example, take two textbooks
  129. on the same subject and try to devise a scheme for putting them into one
  130. hypertext.  Since each author chose a coherent scheme, melding the two
  131. may require devising a third that can hold them both.
  132.  
  133. [stuff deleted]
  134.  
  135. >
  136. >  It almost seems that there is an interaction between:
  137. >    a) Number of links
  138. >    b) Types of link structures
  139. >    c) number of nodes
  140. >    d) node types
  141. >    e) coherence during link traversal
  142. >    f) dynamicism of said HT.
  143. >
  144.  
  145. I suggest that adding "coherence types" cleans up the interaction by
  146. limiting it to a knowable, finite number.
  147.  
  148. Now the dynamicism of the HT gets restricted, but not limited.  That is,
  149. you can only do certain things, but you can do as many as make sense to
  150. you until your machine runs out of speed and storage.  If the things you
  151. can do cover all your needs, you've won.  If not, you need a new engine.
  152.  
  153.  
  154. [stuff deleted]
  155.  
  156. >Why not dump the theoretical basis of the HT?  Well, one could do this, but
  157. >the whole point of grounding such a system theoretically/empirically is to
  158. >facilitate search speed and accuracy, and to maintain user coherence, instead
  159. >of relying on the user to infer the programmer's reasons for coherence.
  160.  
  161. To the extent that programmer means author, the programmer's only reason
  162. for coherence needs to derive from the user's frame of reference.  One
  163. must know one's audience and create in their terms if one wishes to
  164. communicate.  
  165.  
  166. I suggest that users annotate a well-crafted piece to tie it to another
  167. framework rather than to correct the original framework.  Thus users
  168. will need to create threads and nodes that represent personal, rather
  169. than shared knowledge.  
  170.  
  171. In the group annealing process, an existing group links the foreign
  172. knowledge to its previously shared knowledge.  
  173.  
  174. In groups newly formed around a "starter" HT, the group develops its
  175. shared knowledge around the HT by offering personal knowledge for
  176. discussion.  
  177.  
  178. These situations all differ, but they share one problem.  *The annealing 
  179. discussion includes both knowledge and knowledge about knowledge.*  Thus
  180. I suggest that the interactions take place on multiple planes and the
  181. hypertext system needs to keep them separated.  
  182.  
  183. Even in conversation the separation of meta-knowledge from knowledge
  184. seems to need lots of trials and false starts.  Asking the HT engine to
  185. do smoothly what I can barely describe may need a few trials to find,
  186. design, and learn to use the engine.  My experience of databases and
  187. outliners as well as spreadsheets keeps reminding me how difficult it is
  188. to separate what I know from the way in which I know it.  Working with
  189. hypertext helps by giving another view. 
  190.  
  191. One further possibility occurs to me.  Perhaps I don't want to annotate
  192. the HT, but to *transform* it into a framework that I define.  Put
  193. another way, maybe you want my hypertext as an annotation to yours.  Once
  194. again, the meta-knowledge level dominates because the task is now to    
  195. translate between two knowledge frameworks. 
  196.  
  197. >
  198. >-- 
  199. >+--------8<------Cut Here------8<------Cut Here------8<------Cut Here---------+
  200. >  Mark C. Langston   |  "Secrecy is the beginning of tyranny."                 
  201. >  Psychology Dept.   |  "Always listen to experts.  They'll tell you what can't
  202. >  Memphis State U.   |     be done, and why.  Then do it."                  
  203. >      "Pftph!"       |           -From the notebooks of Lazarus Long      
  204.  
  205.  
  206.  
  207.  
  208. -- 
  209. Kirtland H. Olson                     olson%mydual.uucp@alliant.com
  210.