[Gzz-commits] manuscripts/FutureVision vision.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/09/18 14:40:42

Modified files:
        FutureVision   : vision.rst 

Log message:
        address some xxx

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/vision.rst.diff?tr1=1.141&tr2=1.142&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/vision.rst
diff -u manuscripts/FutureVision/vision.rst:1.141 
manuscripts/FutureVision/vision.rst:1.142
--- manuscripts/FutureVision/vision.rst:1.141   Thu Sep 18 14:39:54 2003
+++ manuscripts/FutureVision/vision.rst Thu Sep 18 14:40:42 2003
@@ -109,11 +109,8 @@
 
 
 
-2 The user interface / user experience
-======================================
-
-(XXX better section title)
-
+2 An item-based user interface
+==============================
 
 Let us stress that the system we discuss is not primarily
 intended as a medium, for communicating information
@@ -185,25 +182,17 @@
 The historian's map and timeline views may have been developed
 independently, for completely different purposes, and it may
 have been the user who re-purposed them for their work.
-(For convenience, the user may create menus and choose
+(For convenience, the user may create menus [#menus]_ and choose
 view defaults for each task, providing quick access
 to the functionality needed for this task.)
 
-XXX create menus --> footnote saying that menus
-are usually 'item' structures themselves
-
 Instead of forcing the user to think in applications,
 such a system lends itself to be structured around
 the user's tasks. `Nelson (1999b)`_ uses the term
 **applitude** for such a "[zone] of functionality."
 An applitude is not "walled off" from the rest of the
 system; when information from a different applitude
-is needed, it is always available. 
-
-XXX applitudes *may* be constructed by a
-programmer and delivered to customers; views
-in that applitude can be repurposed into other
-applitudes then (say this as note)
+is needed, it is always available [#applitudes-as-product]_. 
 
 XXX applitudes use loom buoys, so if you add
 more loom buoys, they look like a seamless part
@@ -389,22 +378,35 @@
 the center, the items connected to *those* nodes a bit further out,
 and so on [#disorientation]_.
 
-- wheel: f+c (see fig.1)
+We usually show only a small subset of a node's
+relationships at every time: Depending on the task at hand,
+the user can "switch" individual relationship types on and off.
+
+RDF diagrams usually label nodes with the string that is
+used internally to identify the node. This is not acceptable
+for showing a network of items; items need to be labeled
+by a description the user can understand. 
+
+Unlike zzStructure,
+RDF doesn't have the notion of a node label contained "in"
+the node. Rather, a node may be connected to literal strings
+providing, for example, the name of a person. In our views,
+the user can specify which of these properties to show
+as the label of a node [#nodelabels]_. If the user does not specify
+one, a reasonable default is used (such as ``rdfs:description``,
+i.e. a description of the item). URIs are only shown
+when a user explicitly requests it.
+
+Also, RDF has no built-in notion of the order of related items;
+for example, in which order to list the students in a class.
+Fenfire will in the future allow a user to specify different
+sorting criteria (first name, last name, birthday etc.)
+
+We are planning to release a version of the RDF 
+browsing and editing functionality as a separate product,
+for use by people who want to edit RDF but are not interested
+in the full Fenfire system.
 
-- challenge:
-  RDF diagrams usually show URI nodes labelled with the URI.
-  In Fenfire, some property of the node will usually be shown
-  as the next inside the node, often an ``rdfs:desctiption``.
-
-  - (unfortunate that the user has to worry about that,
-    but OTOH more powerful than ZZ: you *may* want to show
-    people as "Anna Fischer (39)"...)
-
-- similar with sorting
-
-- we will productize Loom separately as an RDF editor;
-  Loom is similar to a zzstructure implementation that
-  shows only the fundamental hyperstructure.
 
 4.2.2 Buoys
 """""""""""
@@ -1022,6 +1024,20 @@
    about them, in this case the idea about how to develop
    one of them.
 
+.. [#menus] Menus are usually simply commands organized
+   in the same connective structure (hyperstructure) as the items.
+
+.. [#applitudes-as-products] While emphasize that applitudes
+   can be created by a normal user without any programming,
+   just by *using* the system in a particular way, applitudes
+   may also be products, templates for using the system
+   in a particular way, possibly with their own tailor-made
+   views and commands.
+
+   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.
+
 .. [#unix-command-line] Hyperstructure would have an analogous
    role to text files on the UNIX command line: It would store both
    the user's information and, unified in the same model, the data
@@ -1048,6 +1064,11 @@
    are always in the foreground, we hope that this view will not
    cause disorientation. However, we have not done any
    user-testing, yet.
+
+.. [#nodelabels] This additional work for the user is unfortunate.
+   However, it also makes the system more powerful; in zzStructure,
+   when you have decided to label people by their first names,
+   you cannot easily show them using their full name at a later point.
 
 ..  [#libvob-speed] For some changes (scrolling, zooming), the scene
     need not be regenerated but only the coordinate system