[Gzz-commits] manuscripts/FutureVision oplan.txt

[Benja Fallenstein]

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

Modified files:
        FutureVision   : oplan.txt 

Log message:
        smallness of space & other counters for 500'000 items argument

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/oplan.txt.diff?tr1=1.10&tr2=1.11&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/oplan.txt
diff -u manuscripts/FutureVision/oplan.txt:1.10 
manuscripts/FutureVision/oplan.txt:1.11
--- manuscripts/FutureVision/oplan.txt:1.10     Thu Nov 13 08:03:42 2003
+++ manuscripts/FutureVision/oplan.txt  Thu Nov 13 09:32:09 2003
@@ -28,6 +28,8 @@
 1 Introduction
 ==============
 
+s/we need a system/we believe that a system is needed/
+
 s/a system, in technical terms/in technical terms/
 
 Remove the "irrelevant computery abstractions" goof,
@@ -67,6 +69,12 @@
     (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.
+
 [4],[5] Make explicit the difference between a file
 and items, "a thing we care about":
 
@@ -84,6 +92,13 @@
 2 An item-based user interface
 ==============================
 
+The views simply show whatever they see in the structure
+around a given set of *focus* items:
+
+    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.
+
 The paragraph [1], [6]
 
     Let us stress that the system we discuss is not primarily
@@ -93,11 +108,46 @@
 
 was clearly not clear enough about the smallness of the space.
 
-Should we have 
-a) a new section 2, discussing the natures of the unexplored/explored spaces
-b) just mention it where we discuss the uis
-c) just give the ways to handle large lists (tjl's against this one
-   since the different feel of the spaces is important)
+Mention it where we discuss the uis, after
+"...which you had forgotten about:"
+
+    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 propose to **build a whole computing environment**
+    organizing information around items, rather than
+    splitting it up into files.
+
+In this paragraph, need to explain about integration of documents
+into an item-centric system:
+
+    XXX
 
 Views: views are independent of connections, unlike in systems
 like OHM where the document type determines the view [9]
@@ -117,8 +167,7 @@
 that can *show* the versioning, and allow the user
 to merge different users' changes to a document.
 
-The views simply show whatever they see in the structure
-around a given set of *focus* items.
+Connection types, showing only some (re overload)
 
 3.1 Zzstructure (used in ZigZag(tm))
 ------------------------------------