peterr@utcsrgv.UUCP (Peter Rowley) (11/12/83)
Though I can't give any references off-hand, I think it's been shown reasonably
well that people don't remember phrases (such as article titles) verbatim, but
interpreted according to their own knowledge. Also, what is remembered is
subject to interference from the body of the article itself. So while a
reader might remember most of a title, it might only be in terms of its
meaning, not the words used; thus I wouldn't have much hope for a
sentence-matching scheme, except for very short titles ("Grenada").
Even slightly longer titles are subject to transposition errors (e.g.
"Lebanon bombing", "Bombing in Lebanon") and minor interpretation
differences ("Bombing marines").
Here are two ideas, tho: a "note the title, article #, and first few
lines of the article I just read" command in readnews, which would dump
the information to a .followup file, which could be consulted when posting
a followup (in a manner similar to mail message printing). This could
provide the necessary link between reading news and posting followups.
This scheme also has the advantage of providing a note-pad on which to record
messages you want to respond to (an incentive for use of the "note article"
command).
readnews -p could print article numbers.
The other idea is to use keywords-within-groups, following the spirit
of suggested keyword news systems. "Grenada", "Lebanon", "bombing", and
"marines", above, are all pretty good keywords. Taking all the noise
words out of a title sentence to come up with a keyword list which could
then be compared against keywords supplied by a followupper might work.
A more explicit use of keywords (i.e. keywords supplied by the article
originator, or by analysis of a submitted article) would probably be better.
The keyword-oriented scheme has the advantage of the followupper being
allowed to generalize or specialize the discussion, by removing or adding
keywords to the set of keywords in the referenced article. The discussion
on Grenada is one in which this would have been useful. (e.g. moving from
{Grenada} to {Grenada,news} and {Grenada,airfield} to {Grenada,airfield,
British} to {British,US}). Keyword systems have problems with synonyms
though.
p. rowley, U. Torontogrunwald@uiuccsb.UUCP (11/19/83)
#R:utcsrgv:-270600:uiuccsb:19000002:000:4090 uiuccsb!grunwald Nov 14 13:57:00 1983 I don't want this to be taken as an attack on B-news, but ... People seem to operate better when instructions and so forth are given in both spatial and textual terms. This was illustrated in my Human Factors class by studies comparing text + illustration vs. text alone vs. illustration alone manuals and documents. Essentially, news provides a text-alone referencing for what is, at the crux, a graphical element. The concept of a note and its following responses can be viewed as a graph across time of the conversation. Futhermore, every node in the graph is not identical. Typically, people ask a question or make a statement and other be make responses or comments to those statements. In the same vein, people could in fact respond to others responses. Representing this graphical element via textual references seems to be a mistake, one imposed by the history of B-news and other linear news systems (i.e. EIES, etc), as well as the resources of the machines that these systems have historical been run on. To grasp the concept a little more intuitively, take the example of looking at a linked-list in a memory dump. Clearly, a graphical representation of the linked list provides much more rapid comprehension of the overall structure and provides better mechanisms to move through the structure than, say, a textual list of "next-cell" pointers. However, one would be in error to ignore the constraints of the technology. One can not, at this time, provide a widespread, completely graphical representation on a display (e.g. using icons, etc). I doubt that one could ever do this, just by the size of a conversation (e.g. representing a graph of 100 responses gets to be a little time-consuming). Since we are trying to get the maximum information content across in the minimum time, one would hopefully realize that this is not really needed either. Thus, it is wise to seek a compromise. By providing a "packed-graphical" display, we get across the picture of the overall structure of the conversation. How do we provide this "packed-graphical" display? Well, one example is that provided by "notesfiles". Instead of asking the user to remember back-pointers (i.e. references), this is done automatically. I know that there is a lot of bad feeling on some peoples part about notesfiles, but I think that they are do an injustice to themselves to not look at the concepts incorporated in the structure. As many people know, the structure behind notesfile (e.g. a chain of notes and a chain of responses to each note) is not new. Notesfiles have been used on the PLATO computer system for a good many years. I have spent about 7 years using the PLATO system at one point or another. During that time, I've seen very few mistakes made by people when it comes to associating a response with a note. They very rarely include the response as another base note, and they almost never include it as a response to another note. Additionally, the structure imposed usually tends to guide the conversation around the topic of interest in the base note. Now these structures are by no means the only ones which can be used in such a structure. Other people have tried more tree-oriented structures (e.g. CONFER on PLATO -- tied out because conversations tended to wander too much). However, the key point of these methods is that they looked at how people carry on conversations, abstracted the interactions and provided a reasonable computer representation of the process. B-news, on the other hand, seems to be closer to a model of an editorial page. It's very difficult to carry on conversations through an editorial page. So, in closing, do not be so concerned with how to back-index or reference a note via textual methods to another one. This is work for machines. Look for a better metaphor for the computer discussion and apply that to your program. The time spent doing that will be paid back by a much more usable interface. Dirk Grunwald University of Illinois ihnp4 ! uiucdcs ! grunwald (USENET) grunwald.uiuc@Rand-Relay (CSNET)