[Gzz] address@hidden: GI 2003 notification - #183]

[Janne Kujala]

----- Forwarded message from address@hidden -----

Date: Mon, 24 Feb 2003 10:43:30 -0500
From: address@hidden
Reply-To: address@hidden
To: address@hidden
Subject: GI 2003 notification - #183
CC: address@hidden
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

Dear Janne V. Kujala -

We regrent to inform you that your paper

  183 - Tearing instead of rectangular clipping/framing viewports in user 
interfaces

has not been accepted to GI 2003.  

Out of the 96 submissions 32 were accepted.

The reviews are included below.


Sincerely,
Torsten Möller and Colin Ware
Graphics Interface co-chairs
address@hidden
address@hidden


---------------- GI 2003 paper 183, review 1 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      2  (scale is 1..5; 5 is best)
Reviewer expertise  2  (scale is 1..3; 2 = "Knowledgable")

1. Rating

   2  (Perhaps reject)

2. Expertise

   2  (Knowledgable)

3. The Meta-Review

   The reviews are varied for this paper.
   In many senses it is an ideal paper for this conference,
   namely a mix of graphics and HCI.  In the end, however,
   the lack of user testing (anecdotal, or, better yet, through
   user studies), is really problematic.


---------------- GI 2003 paper 183, review 2 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      4  (scale is 1..5; 5 is best)
Reviewer expertise  2  (scale is 1..3; 2 = "Knowledgable")

1. Rating

   4  (Perhaps accept)

2. Expertise

   2  (Knowledgable)

3. The Review

   The paper presents a novel method of displaying viewports into large
   documents using a "torn paper" or "break lines" convention from technical
   drawing.  The paper lists several methods of obtaining and drawing a
   suitably ragged edge from an undistorted viewport using common graphics
   hardware.  Finally, screenshots and a video demonstrate the method
   convincingly in a  prototype viewer.

   The significant and novel contribution of the paper is the introduction
   of the use of break lines to reduce confusion between viewport content
   and the viewport edges.  Additionally, the motion and scale of the break
   lines might communicate further information about the viewport position,
   scale and motion.  A set of implementation techniques is described that
   should give adequate performance of this technique on common graphics
   hardware.

   I do not have the expertise to comment on whether the method is relevant
   in HCI terms.   In terms of graphics and NPR, the paper covers the
   techniques for line drawing well and discusses the relevant issues with
   respect to the problem at hand.  I think the paper is appropriate for GI
   2003, but needs significant editing for clarity and perhaps focus.

   The language in the paper is good, but there are several sections
   (notably Section 4) which need a good rewrite and restructuring.  I
   believe the appropriate information is there, but it is quite confusing. 
   I have included my detailed notes on this below.

   In summary, the idea is certainly interesting, the treatment of the
   graphics and NPR issues is good, but there are problems with the clarity
   of the presentation.  If the issues listed below are resolved by the
   authors (and there are no show-stoppers in the list), then the paper
   should be accepted.


   Detailed comments for the authors
   ---------------------------------

   Section 3.2, 2nd last para.: "Fig xxx"

   Section 3.2: Terminology -- "paper coords" and "canvas coords"
   identical?

   Figure 4: The order of the images e) and f) is backwards compared to
   the rest of the rows.  Same goes for i) j).

   Figure 4 is not referenced in the text, and it's not clear which
   subfigures go with which methods of Section 4.  It took several reads
   determine which subfigures were grouped together and their order.

   Figure 4, g) - i) and the 2nd/3rd paragraphs of "Explicit Undistorted
   Shape" seem to describe a method of obtaining the "ebbing" effect
   reference previously, but the explanation, if it exists, is completely
   opaque.  Further explanation is needed here.

   Section 5, 1st para: "An example Also seen in Fig. 1 The connection
   structure somewhat similar to [12]," ???

   Section 4: Several line-drawing methods are presented, but which was
   finally decided on?  A bit of analysis/summary of how these algorithms
   relate to your goals would be a help here.

   Figure 5, bottom displays the scale information contained in the torn
   edge rather nicely.  I would have liked to have seen it without the
   background pattern, which confounds the issue.

   In general, the HCI and graphics issues should be separated somewhat.
   The methods of obtaining the distorted viewport shape and the methods
   of drawing the edges are useful for an implementor, but the HCI issues
   are the novel contributions of the paper.  Put another way, the
   real-time graphics enables the HCI, but it's the HCI that seems to be
   interesting here.

   What is the difference between the screenshots and the video?  The
   video seems to have much rougher edges which are "busier".  The edges
   in the screenshots have a much cleaner quality.  If this is just a
   difference of smoothing the noise function than that needs to be said.

   What happened to the idea that edges parallel to the motion should not
   move as much as edges perpendicular to the motion?  This is mentioned
   in Section 3.2, but never again.  It is visible in the video, though
   obscured by the random motion of the edge.



---------------- GI 2003 paper 183, review 3 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      4  (scale is 1..5; 5 is best)
Reviewer expertise  3  (scale is 1..3; 3 = "Expert")

1. Rating

   4  (Perhaps accept)

2. Expertise

   3  (Expert)

3. The Review

   Overall, I thought the paper presented a simple yet thought provoking
   idea of “break-line” style window framing. The authors do a good job
   relating it to prior work and have a very comprehensive reference
   section. The arguments are presented quite logically but the paper does
   suffer with some glaring editing mishaps in a few sections (pg 3, see Fig
   XXX; pg 5, “An example Also seen in “, etc.). 

   The authors spend quite a bit of time describing how to implement this
   “break line” style of windows. While this is useful, I would prefer that
   the authors dedicate a bit more time to describing the implications of
   this UI design. For example, what are the tradeoffs with this approach
   over rectangular shaped windows? There is a visual simplicity with
   rectangular windows. In addition, they often match the form of the
   underlying data (e.g., a document, printed page, photograph). One insight
   the authors mention which is very interesting is the styling of the
   ripples indicate the zoom factor of the tear off. These tear-offs look
   very distinct from rectangular windows which may be the main benefit of
   this technique – used to draw attention to the user. How many tear-offs
   can there be on a screen before it looks cluttered? Can tear-offs
   overlap? Are there different rippling styles per application type? Is
   there a benefit of having a drop shadow effect beneath the tear-off to
   signal that the tear-off sits above the context window? Can the region be
   interactively defined and edited? Is there any benefit of considering a
   non-static ripple edge (e.g., animated)? Can the rippling design signal
   where the cut-out came from the larger document? What if the rippling was
   not randomly set to generate edging but actually spelled out words such
   as the source file name.  Lastly, what are they most suited for
   (annotation post-it notes?)? [Sorry for the long list here...]

   The term and concept of “motion” needs to be clarified – I think it is
   first mentioned on pg 2, “the motion of the uneven edge”. 

   Lastly, the benefit not strongly mentioned by the authors is to provide
   an irregularly shapped view onto a complex set of data (as in Figure 1)
   to emphasize non-rectangular regions. This could be very useful. 


---------------- GI 2003 paper 183, review 4 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      3  (scale is 1..5; 5 is best)
Reviewer expertise  2  (scale is 1..3; 2 = "Knowledgable")

1. Rating

   3  (Neutral)

2. Expertise

   2  (Knowledgable)

3. The Review

   The paper introduces a user interface model with irregular shaped view
   ports. The work is inspired by traditional illustration practice of
   drawing break-lines for suggesting incomplete view of objects. The
   authors argue that the use of irregular shaped or “torn” viewports
   enables them to provide visual cues for position, scale and motion of the
   viewable fragment. 
   Most of the paper is dedicated to the challenge of rapid drawing “torn”
   viewports. The algorithm is based on the stencil buffer approach. The
   implementation relies on programmable graphics hardware for rendering a
   texture with an irregular boundary. The authors suggest at least two
   solutions to drawing viewport outlines --- offset overdrawing and image
   filtering. 
   The paper suggests possible application of “torn” viewports but lacks any
   user studies indicating their usefulness. These studies are important
   since even the authors mentioned many objections to the use of
   non-rectangular windows: arguably wasted screen space, incompatibility
   with common widgets, lack of window system support etc. Also, it is not
   clear if dynamic viewport shapes provide sufficient indication of
   fragment scale and motion. Without justification, the use of the
   elaborate shape drawing techniques for supporting variable shaped
   viewports may seem as overkill 
   This paper is on the edge between two disciplines: graphics and HCI,
   which is great. Unfortunately, the lack of user studies leaves many HCI
   questions unanswered. The use of hardware to draw irregular shapes is not
   a significant contribution to graphics practice.
   Minor comments: 
   References to non-photorealistic rendering may not be necessary in this
   context. The shapes are simply irregular and represent stylized break
   lines. 
   The paper has a significant number of grammatical mistakes.  I suggest
   reworking section titles making them more descriptive and readable. 


---------------- GI 2003 paper 183, review 5 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      4  (scale is 1..5; 5 is best)
Reviewer expertise  2  (scale is 1..3; 2 = "Knowledgable")

1. Rating

   4  (Perhaps accept)

2. Expertise

   2  (Knowledgable)

3. The Review

   The main point of this paper is the use of break lines to indicate a
   viewport is actually a piece “torn” from a larger image.  The paper
   introduces the techniques and motivates it both on the basis technical
   sketches and other UI techniques.

   I think the ideas presented in this paper are very innovative and provide
   a significant contribution to GI.  I really liked the analogy, “we see a
   piece of the canvas” instead of “we see the canvas through an irregularly
   shaped hole”.  It was compelling for me.  The sections dealing with the
   algorithm and implementation are beyond the scope of my expertise, but
   from a user interface perspective I think it makes a strong contribution.
    Too often we are constrained by rectangular widgets just because they
   are easy to render.  

   I think the paper is very appropriate for GI, particularly given the
   overlap between both graphics and user interface techniques.  

   Overall I felt this paper is fairly well written with just a few areas of
   improvement.  For example:
   - The additional options discussed in section 3.2 (last paragraph) are
   difficult to understand
   - The top figure in Figure 5 is difficult to understand, both from the
   figure and the caption
   - The ending of the paper just drops off.  There is just a very short
   conclusion, followed by a couple of possible objections.  The further
   work section is also very short and doesn’t really give any indication of
   what would be important next steps
   - The use of 46 references in a paper of this length seems very high.  I
   am sure that a number of them listed in the related work section could be
   omitted.

   Minor corrections:
   - Section 3.1, first sentence, “… shown below”.  I can’t figure out where
   below it.
   - Section 3.1, second paragraph, last line, “can BE achieved …”
   - Section 3.1, third paragraph, first line, “Additionally, [] motion of
   the …”
   - Section 3.2, 4th paragraph, “Fig xxx”
   - Section 5, first paragraph, last sentence, “An example Also seen …”
   - Section 5, second paragraph, two periods, “tearout..”
   - Figure 5, two periods at the end of the caption.  




---------------- GI 2003 paper 183, review 6 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      2  (scale is 1..5; 5 is best)
Reviewer expertise  2  (scale is 1..3; 2 = "Knowledgable")

1. Rating

   2  (Perhaps reject)

2. Expertise

   2  (Knowledgable)

3. The Review

   The paper proposes the idea of using "torn" viewport
   borders in order to easily be able to distinguish
   the viewport border from other edges that may occur
   in the document being viewed. Details for implementing
   this kind fo viewport in current hardware are discussed.

   I like the idea of exploring what can be done beyond
   the standard rectangular viewports. I'm not optimistic
   about the success of the "jagged edge" viewport idea, though.
   The most common solution to producting a readily identifiable
   viewport is to choose distinguishing colors or "skins" for
   the viewport. Granted, skins do not solve the problem of
   knowing when you are really at the edge of large document
   having horizontal or vertical edges.

   I was unable to view the video because I did not have
   the required codec installed. I would have been interested
   in seeing how convincing the illusion of a "torn piece of document"
   remained, rather than the less interesting illusion of "the
   viewport has a ragged edge". This issue is discussed in the paper,
   but I cannot sure about the outcome because I'm unable to view
   the video.

   Page 3 has a reference to "Fig xxx." that needs to be fixed.

   The paper would be much stronger with some user testing,
   or even selected anecdotal comments from users.
   Perhaps these were in the video; I don't know.


---------------- GI 2003 paper 183, review 7 ----------------

Title: Tearing instead of rectangular clipping/framing viewports in user 
interfaces

Overall rating      2  (scale is 1..5; 5 is best)
Reviewer expertise  2  (scale is 1..3; 2 = "Knowledgable")

1. Rating

   2  (Perhaps reject)

2. Expertise

   2  (Knowledgable)

3. The Review


   This paper is about using the technique of jagged edges to visually
   connote that one part of a document was "ripped away" from the larger
   context. The authors state that the technique is inspired by
   nonphotorealistic rendering. However, NPR is usually about abstraction
   and simplification! This paper provides an elaborate algorithm for doing
   something that's the opposite of abstraction - creating a very complex
   jagged edge that changes with motion, and even gives rise to little
   "islands" of noncontiguous bits of the document. I found both of these
   aspects to be confusing - not helpful. The authors state that it's bad to
   have a motion-independent silhouette, but that's the exact opposite of my
   intuition. That's a claim that needs to be strongly backed up but instead
   appears in a vacuum - and it's fundamental to the entire approach!

   In short, there is not enough motivation to justify the heavyweight
   apparatus - the authors do not provide any arguments that this approach
   is necessary. They may well have such a justification, but it needs to be
   written up. I suggest tying the design choices to a scenario of how the
   user would interact with a specific application. 

   I was also a reviewer of the companion paper on unique textures. That
   paper also suffered from a lack of justification (but the problem was
   worse with this one). After reading both, and "reading between the
   lines", I could start to guess - but not necessarily agree with - some of
   the intent behind these design choices. But papers need to stand on their
   own, and it is the responsibility of the author to make the case for why
   these approaches are useful. 

   This paper does not make enough of an HCI contribution to accept it under
   that umbrella. One way to strengthen the HCI contribution would be to do
   an informal or formal evaluation of the system. 










----- End forwarded message -----