[Gzz-commits] manuscripts/xupdf review buoyoing.mp

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuomas J. Lukka <address@hidden>        03/05/22 00:42:49

Modified files:
        xupdf          : review 
Added files:
        xupdf          : buoyoing.mp 

Log message:
        Yesterday's changes - the diagram and some thoughts about the reviews

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/xupdf/buoyoing.mp?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/xupdf/review.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: manuscripts/xupdf/review
diff -u manuscripts/xupdf/review:1.2 manuscripts/xupdf/review:1.3
--- manuscripts/xupdf/review:1.2        Tue May  6 23:52:04 2003
+++ manuscripts/xupdf/review    Thu May 22 00:42:49 2003
@@ -8,10 +8,19 @@
 the browser window (like those JavaScript-based shifting-fucus
 "3D"-navigations that were fashionable a year or two ago)?
 
+  COMMENT: Need to talk about us starting from a consistent
+  datamodel to avoid technical difficulties with trying to multidirectionalize
+  one-directional web links.
+
+  That the applications to web are beyond the scope of this article;
+  the article is about the UI
+
 - What about users` learning curves? Having to learn a new navigation
 paradigm always means added stress at first and may create an exit
 point for new users. Do you have empirical data on user-reactions?
 
+  COMMENT: Ongoing, experimental system - not much data yet
+
 - How far can the unique backgrounds go? Color coding always poses
 a conceptual problem - because you run out of distinctive colors/
 patterns and because they impose another learning curve. - Is this
@@ -26,6 +35,8 @@
 does the tool crawl? Would the software be a permanent replacement
 of other retrieval tools (folder-structure)?
 
+    COMMENT: right, we didn't make this clear...
+
 2:
 
 There is a deep and rich history of research surrounding annotation
@@ -34,6 +45,8 @@
 anticipated). Look for author names Denoue, Golovchinsky, Wilensky,
 Brush, Bargeron, and Marshall.
 
+    COMMENT: Must read
+
 3:
 
 There is no reason whatsoeer to believe the explanation based
@@ -41,48 +54,86 @@
 <http://doi.acm.org/10.1145/208666.208687>.  However, innovative
 new interfaces don`t need to be rigorously justified before testing.
 
+    COMMENT: 20 was justification for our intuition,
+    but non-rigorous as said.
+
 Clearly the user interface is intended for a particular (if not
 specialiazed) type of hypertext user.  It must be clear in the
 article who the target group is or what their makeup will be.
+
+    COMMENT: Very true. 
+
+    I guess our target group for the first versions is
+    academic researchers, and their handling of sources.
+
 Everyone is familiar with the apparent paradox of spatial reasoning
 ability and success with hypertext.  This issue must be addressed
 if only in passing.
 
+    COMMENT: What paradox? The only hypertext that really
+    works is one where the documents have been structured
+    really closely to a tree - see the common web navigation
+    paradigms
+
 In section 2.2: if evidence is available (aboutthe amount of attention
-needed) then it should be presented.  It would help readers if
+needed) then it should be presented.  
+
+    COMMENT: None yet, except that mouseovers are not nice.
+
+It would help readers if
 the ideas presented in the article were placed in more context,
 for instance how do they relate to Polle Z.`s fluid annotations
 (as another method of dealing with *some* of the same issues)?
 
+    COMMENT: didn't we say this?
+
 instead of ``improves recognizability`` would it be more correct to
 say it could promote more recognizability?
 
+    COMMENT: [tjl] I really can't say
+
 What are affine functions?  Did you mean affined?
+
+    COMMENT: We need to tone down the tech level of the article.
+    Affine is a mathematical term for a generalization of linear,
+    i.e. linear with constant offset.
+
+
+
                                    
 4:
 
-The biggest value of this paper is to implement a graphic system
-that displays a page of hypertext and related pages in non-mechanical
-way. The authors` idea is buoys and unique backgrounds. A buoy is a
-small area to display the part of the content of the related page
-like floating on the water. It gives a natural atmosphere to the
-user. Unique backgrounds is painting a buoy with a unique color to
+Unique backgrounds is painting a buoy with a unique color to
 allow the user to specify the target buoy easily.
 
+    COMMENT: Sigh - not. Need to make this more clear.
+
 I understand that the authors implemented a sophisticated system to
 display hypertext in a natural way. I also understand the authors`
 efforts to display buoys without overlaps of buoys and prevention
-of the user`s focus. However I`m still not sure that each of these
+of the user`s focus. 
+
+However I`m still not sure that each of these
 devices are really novel in the filed of visualization or human
-interface. Only proposing buoys and unique background colors as
+interface. 
+
+    COMMENT: They really appear to be, and we HAVE to make that clear.
+
+Only proposing buoys and unique background colors as
 just an interesting display method is insufficient to present in
 this conference.
 
+    COMMENT: Agreed now - we need data.
+
 5:
 
 It is a hard task to describe a highly dynamic user interface using
 words and static monochrome figures.  This paper does not succeed
-in the task -- though it is by no means a hopeless failure.  A few
+in the task -- though it is by no means a hopeless failure.  
+
+    COMMENT: We tried hard and failed -- we need to try HARDER.
+
+A few
 SIMPLE and REAL examples early in the paper would help greatly
 (i.e. like Figure 1, but showing the new interface).  The only
 real screen dumps occur at the very end (Figure 7) and these are
@@ -94,20 +145,29 @@
 (I can understand the authors` desire to show the full capabilities
 of their system, but this goes too far, too fast.)
 
+    COMMENT: This is really good instructions for us.
+
 Another problem I have with the paper is that it is premature.
 There is no description of any user testing at all: if you are
 describing a new interface it helps to have some evidence -- even
 if tenuous -- that users see some advantage in it.
 
+    COMMENT: At least anecdotal stuff
+
 Two detailed points:
 
 (a) at a low level, there are problems with the rendering of the
 paper: in two cases the first column extends into the second and
 obscures it.
 
+    COMMENT: Ouch - we really need to read the LaTeX output
+    on overfull hboxes.
+
 (b) it was unclear to me whether a fragment has to be textual (the
 first paragraph of 2.2 implies this).
 
+    COMMENT: Make sure it's stated it's not so.
+
 
 
 Assoc. Papers Chair:
@@ -115,24 +175,47 @@
 There was some confusion over the underlying Zig-Zag basis for the
 work, which although a central driver for your work, is somewhat
 secondary in this paper and not given enough room to properly explain
-with all its concepts and terminology. Is this an interface only
+with all its concepts and terminology. 
+
+    COMMENT: Ouch. Do we need to start to state in every paper
+    we make that this has nothing to do with ZZ?
+
+    Well, probably describing RDF as our basis is sufficient.
+
+Is this an interface only
 relevant to hypertextual transclusion, or applicable to any domain
 where there is hypertext or annotation?
 
+    COMMENT: The transclusion is not the important part...
+    RDF structural links also are there.
+
+    NEED TO MAKE THIS CLEAR.
+
 Contextualise it better to the wider work on annotation
 interfaces. Add earlier examples to ground it in the reader`s
 mind. Given that it`s a user interface project, start to plan solid
 studies that assess what support it adds for realistic user tasks
 compared to current UIs.
 
+    COMMENT: Yes. These are planned, but we didn't make it in time
+    for this year's conference. Next year, we'll have something
+    interesting.
+
 The detailed reviewer comments should also provide valuable feedback
 for the presentation and advancement of this work. It will help in
 the future to ensure quality layout of the document (no overflowing
-columns etc, and for such a rich interface, a companion web page
+columns etc, 
+
+    COMMENT: Our bad.
+
+and for such a rich interface, a companion web page
 with colour screenshots or even better a screen movie would be worth
 considering to communicate the work).
 
-
+    COMMENT: This we HAVE to do, if it's so explicitly allowed / encouraged.
+    My impression was that articles were judged based on the 
+    articles but if the official word is that any extra material
+    *will* be considered, it changes several things.