[Gzz-commits] manuscripts/FutureVision oplan.txt vision.rst c...

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/13 15:32:45

Modified files:
        FutureVision   : oplan.txt vision.rst 
Added files:
        FutureVision   : change2.png hop1.png 

Log message:
        start to integrate

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/change2.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/hop1.png?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/oplan.txt.diff?tr1=1.31&tr2=1.32&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/vision.rst.diff?tr1=1.179&tr2=1.180&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/oplan.txt
diff -u manuscripts/FutureVision/oplan.txt:1.31 
manuscripts/FutureVision/oplan.txt:1.32
--- manuscripts/FutureVision/oplan.txt:1.31     Thu Nov 13 15:26:49 2003
+++ manuscripts/FutureVision/oplan.txt  Thu Nov 13 15:32:44 2003
@@ -38,7 +38,7 @@
     This system
     should **center around the things we care about**,
     the people, appointments, plants, articles we read, 3D models we create
-    and so on. We need a system
+    and so on. We believe that a system is needed
     in which these **items** (`Nelson 2000`_) are visible things
     that can be connected to each other;
     in technical terms, a hypermedia system in which items
Index: manuscripts/FutureVision/vision.rst
diff -u manuscripts/FutureVision/vision.rst:1.179 
manuscripts/FutureVision/vision.rst:1.180
--- manuscripts/FutureVision/vision.rst:1.179   Sat Nov  8 10:48:18 2003
+++ manuscripts/FutureVision/vision.rst Thu Nov 13 15:32:45 2003
@@ -19,10 +19,12 @@
 ========
 
 Computers should help us with **organizing our lives**, rather
-than making them more difficult. We need
+than making them more difficult. We conjecture that we need
 a system **structured** around **items** -- 
-**things that we care about**, such as people, arguments and ideas --
-rather than directories and files.
+**things that we care about**, such as people, arguments and ideas,
+and able to express the relationships between them,
+so that connected to e.g. an idea we see all arguments
+we have considered for or against it.
 
 Based on Ted Nelson's ideas,
 we describe the design of a computing environment based on a 
**hyperstructure**,
@@ -51,17 +53,53 @@
   courses we have taken, marks we got, types of poems, types of plants, 
   classes in a program and structures in a plot
 
-Instead of being centered around irrelevant computery
-abstractions such as "files" and "directories," this system
+This system
 should **center around the things we care about**,
 the people, appointments, plants, articles we read, 3D models we create
-and so on. 
-We need a system
+and so on. We believe that a system is needed
 in which these **items** (`Nelson 2000`_) are visible things
-that can be connected to each other; a system,
+that can be connected to each other;
 in technical terms, a hypermedia system in which items
 are first-class objects [#can-use-structcomp]_. 
 
+In contrast, in the mainstream file system paradigm,
+only documents and categories of documents are represented 
+as first-class objects.
+While documents certainly qualify as things that we care about,
+other items like people, theories, or places are not 
+explicitly represented in this paradigm at all. 
+Additionally, file systems are simple hierarchies,
+rather than allowing arbitrary relationships between items
+to be expressed. Information like "In this meeting, we discussed
+possible solutions A, B, C to problem X, and our consensus
+was that...," for example, might be hidden in a document called
+"Minutes 2003-07-24."
+
+In an item-centric system, this information would be expressed
+as relationships between a couple of items-- the problem, the meeting,
+the solutions discussed, the arguments raised in this discussion,
+the decisions reached. Looking at the problem item, for example,
+the user would connect to it the solutions that have
+been discussed for it, and to them
+the arguments that have presented in favor or against each
+of the solutions-- no matter in which meeting, in which e-mail,
+in which memo or in which chat session they were made.
+(On the other hand, the user could just as well look at all the points
+made in a particular meeting, no matter which topic they were about.)
+
+In file systems, you have to remember what information you
+stored where, like with paper notes. We conjecture that
+an item-centric system can improve on this problem greatly,
+because after you have connected information to an item,
+the information can always be shown when looking at that item.
+
+Also, many items that do have a representation in current systems--
+for example appointments (often all appointments are stored
+in a binary, proprietary database file) and e-mail
+(usually several stored in one file)-- are not represented as files.
+It is not possible to make connections
+between an e-mail and an appointment if they are stored
+in different files.
 
 Hypermedia was meant to be an extension to the mind: 
 Vannevar Bush entitled his famous article "As We May Think" (`Bush 1945`_);
@@ -92,7 +130,7 @@
 ==============================
 
 Let us stress that the system we discuss is not primarily
-intended as a medium, for communicating information
+intended as a medium for communicating information
 to others, but as a **tool for personal use** -
 working/editing/authoring/programming [#hypertext-personal]_.
 
@@ -113,9 +151,10 @@
 
 The item we are currently looking at
 is shown in the middle, items related to it are shown
-around it [#fig1note]_. Items further away 
-fade into the background. Clicking
-on a far-away item will bring it to the center.
+around it [#fig1note]_. 
+Items further away fade into the background;
+items more than a few steps away are not shown at all.
+Clicking on a far-away item will bring it to the center.
 
 **Related items are always near each other.**
 This allows you **see the information** you entered 
@@ -125,16 +164,57 @@
 This may be intended; for example, when you'll meet
 somebody, you may want to be reminded of things they borrowed
 from you and ought to return. It may also come in unexpected:
-Planning the next chapter in your novel,
+planning the next chapter in your novel,
 you notice that you once had an idea about how to develop one
 of your characters, which you had forgotten about [#novel-planning-example]_.
 
+One might be concerned what happens if an item has
+a large number of connections, in the hundreds or thousands.
+There are a number of factors alleviating this concern.
+
+- Firstly, the items shown are only those connected
+  directly or through a short path to the item
+  we are looking at. Even if we have hundreds of thousands
+  of items in the system, we only show a small number of them
+  at a time.
+- Secondly, as we have stressed above, this is a tool for
+  *personal use*, and will presumably contain mostly connections
+  made by its particular user. It would seem very unusual
+  for a user to think of thousands of things as *directly*
+  related to an item. For example, rather than categorizing
+  thousands of e-mails as discussing a particular subject,
+  a user might categorize them as making a smaller number
+  of *arguments*, items connected to the subject.
+- Thirdly, we assume that connections are *typed*,
+  as shown in the mock-up ("with," "to," "has borrowed"),
+  and that a user can toggle each connection type to be
+  shown and hidden. A user would usually switch off the
+  connection types not relevant to the task at hand,
+  reducing the number of connections shown.
+- Finally, in the case that there *are* a lot of connections
+  with the same type to the same item, we show them as a
+  scrollable list, and allow the user to specify the sorting order.
+  This is useful when you want to, for example,
+  see all your e-mails sorted by date. We are also working on 
+  interfaces where there are several foci and the nodes on the paths
+  connecting the foci are emphasized and others de-emphasized - 
+  this could make browsing a graph with a high
+  local degree significantly easier.
+
 We propose to **build a whole computing environment**
-around this concept, organizing information around items,
-rather than files on a desktop. 
-Documents and emails would be items,
-connected to other items they relate to, for example the
-meetings they propose or the problems that they solve.
+organizing information around items, rather than
+splitting it up into files.
+
+Some of the items in the system will still be documents,
+such as letters, e-mails, images and so on [#documents-as-files]_,
+and the bodies of these documents will still be characters,
+pixels and so on. However, as items, the documents will be woven
+into the network of items and thus connected to e.g. the things that
+they talk about, the people that created them, the meetings
+they propose and the problems they solve;
+we conjecture that it will be much easier to find relevant documents
+in such a system than it is in the simplistic hierarchical
+categorization of files and folders.
 
 .. _`Figure 2`:
 
@@ -148,11 +228,14 @@
 
    __ full-document-connections.gen.png
 
-Instead of having separate applications, we would have **views** 
-for **specific kinds of information** [#multiple-views-refs]_.
+Instead of having separate applications, we would have **views**
+[#connections-to-items]_ for **specific kinds of information**.
 For example, a historian might want to mark places on a map,
 connecting them to the events that have taken place there,
-and they might want to show the events on a zoomable timeline. 
[#annotating-views]_
+and they might want to show the events on a zoomable timeline. 
+[#annotating-views]_ Multiple views for the same information
+have long been recommended by both `Engelbart (1990)`_ and
+`Nelson (1993)`_.
 
 The content of a document or e-mail is shown when the user clicks
 on it. Similarly, the map or timeline would be shown when the
@@ -200,14 +283,14 @@
 information we already store in our computers, it may also
 help us to **organize our thoughts**.
 
-(Paper notes don't work: Unless you are really tidy, you
+Paper notes don't work: Unless you are really tidy, you
 have to remember that you took a note about a subject
 a year ago, or you won't find it. If we could **connect
 our thoughts and ideas to the subjects they are about**,
 they would be in the place we need them. If we connect all
 the arguments that come to mind to the counter-arguments
 that we have considered, we would not have to think
-through them again.)
+through them again. [#more-vs-semantic-conns]_
 
 .. _`Section 3`:
 
@@ -1102,9 +1185,26 @@
    about them, in this case the idea about how to develop
    one of them.
 
-.. [#multiple-views-refs] Multiple views for the same information
-   have long been recommended by both `Engelbart (1990)`_ and
-   `Nelson (1993)`_.
+.. [#documents-as-files] It would certainly be possible to implement this
+   by storing documents as files on a file system and load them
+   transparently when they need to be shown in the network
+   of items, even though that is not the approach we have taken.
+   What is important to us is the user experience, in which documents
+   are woven into a network of items rather than categorized into
+   a hierarchy of folders.
+
+..  [#connections-to-items]
+    Note that connections are made to items, not to
+    particular views of items. One can view the same item
+    using different views, yet its connections stay the same
+    in each case. Also, while the network of items can be versioned
+    (by keeping a version history), views of it are not. However,
+    views can *show* differences between versions if
+    the versioning information of the network of items is
+    stored in the network itself, through, e.g., RDF reification,
+    or explicitly representing different versions of RDF nodes
+    as nodes themselves (naturally, to save space, this would
+    require a virtualized implementation of the past version).
 
 .. [#annotating-views] There may also be views that add information
    about items shown in arbitrary other views. For example,
@@ -1139,6 +1239,28 @@
    A user of such an applitude would always be free to extend it
    to suit their needs or to repurpose the views and commands
    for use in a different applitude.
+
+..     [#more-vs-semantic-conns] The advantage of
+       using a network of items isn't to simply have *more*
+       connections; it is to store one's ideas in a
+       semantic network, storing the relationships between
+       subjects, problems, solutions, ideas and arguments.
+       Textual notes would become
+       annotations that elaborate on particular items. 
+       
+       The problem with paper notes is that when considering
+       a particular subject, there is no way to find all the
+       notes you have about this subject. Even if you recollect
+       that you made *some* notes about the subject, likely
+       you cannot remember where you put them. 
+
+       By storing
+       your ideas in a network of items, when looking at a
+       particular subject, you can easily see all ideas
+       that you have earlier connected to this subject,
+       and from there all notes you have written about these ideas.
+       We believe that this can solve the problem of not being able
+       to find the relevant notes.
 
 .. [#unix-command-line] Hyperstructure would have an analogous
    role to text files on the UNIX command line: It would store both