[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/FutureVision oplan.txt
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] manuscripts/FutureVision oplan.txt |
Date: |
Thu, 13 Nov 2003 09:32:10 -0500 |
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))
------------------------------------
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Tuomas J. Lukka, 2003/11/12
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Tuomas J. Lukka, 2003/11/12
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Tuomas J. Lukka, 2003/11/12
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt,
Benja Fallenstein <=
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Tuomas J. Lukka, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Tuomas J. Lukka, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Tuomas J. Lukka, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13
- [Gzz-commits] manuscripts/FutureVision oplan.txt, Benja Fallenstein, 2003/11/13