[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/FutureVision oplan.txt vision.rst c...
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] manuscripts/FutureVision oplan.txt vision.rst c... |
Date: |
Thu, 13 Nov 2003 15:32:46 -0500 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz-commits] manuscripts/FutureVision oplan.txt vision.rst c...,
Benja Fallenstein <=