From gzz-dev-bounces+lukka+sav=iki.fi@nongnu.org Mon Apr 7 19:12:08 2003 Return-Path: Received: from uudestaan.iki.fi (uudestaan.iki.fi [212.16.100.1]) by mailhost.it.jyu.fi (8.12.9/8.12.9) with ESMTP id h37GC6ma008934 for ; Mon, 7 Apr 2003 19:12:07 +0300 (EETDST) Received: from monty-python.gnu.org (monty-python.gnu.org [199.232.76.173]) by uudestaan.iki.fi (8.11.6p2/8.11.6) with ESMTP id h37GC6U28500 for ; Mon, 7 Apr 2003 19:12:06 +0300 (EEST) Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 192Z90-0000N9-07 for lukka+sav@iki.fi; Mon, 07 Apr 2003 12:06:50 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 192Z2w-0008Hw-00 for gzz-dev@mail.freesoftware.fsf.org; Mon, 07 Apr 2003 12:00:34 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 192YvE-0004mG-00 for gzz-dev@mail.freesoftware.fsf.org; Mon, 07 Apr 2003 11:52:41 -0400 Received: from kusti.it.jyu.fi ([130.234.160.32] helo=mailhost.it.jyu.fi) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 192YlR-0008Od-00 for gzz-dev@mail.freesoftware.fsf.org; Mon, 07 Apr 2003 11:42:29 -0400 Received: from tarzan.it.jyu.fi (tarzan.it.jyu.fi [130.234.160.40]) by mailhost.it.jyu.fi (8.12.9/8.12.9) with ESMTP id h37FgOma002967 for ; Mon, 7 Apr 2003 18:42:24 +0300 (EETDST) Received: (from lukka@localhost) by tarzan.it.jyu.fi (8.12.9/8.12.9/Submit) id h37FgNJA009281 for gzz-dev@mail.freesoftware.fsf.org; Mon, 7 Apr 2003 18:42:23 +0300 (EETDST) Date: Mon, 7 Apr 2003 18:42:23 +0300 From: Tuomas Lukka To: gzz developers list Message-ID: <20030407154223.GH2820@tarzan.it.jyu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned-By: amavisd-milter at it.jyu.fi Subject: [Gzz] [lac@ecs.soton.ac.uk: ACM HT03: Paper Results] (buoyoing) X-BeenThere: gzz-dev@nongnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Gzz developers List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Sender: gzz-dev-bounces+lukka+sav=iki.fi@nongnu.org Errors-To: gzz-dev-bounces+lukka+sav=iki.fi@nongnu.org Status: RO Content-Length: 10896 Lines: 166 ----- Forwarded message from Les Carr ----- From: Les Carr Date: Mon, 7 Apr 2003 16:12:22 +0100 To: lukka@iki.fi Subject: ACM HT03: Paper Results X-Virus-Scanned-By: amavisd-milter at it.jyu.fi I am sorry to inform you that your submission Buoys, break lines, and unique backgrounds: techniques for non-disruptive bidirectional spatial links has not been chosen as a full paper for the ACM Hypertext 2003 conference. The procedures have been very thorough, and only 25% of the submissions were selected as full papers. Most papers were reviewed by 5 referees whose comments are attached below. If you look at the Web site (www.ht03.org) you will see there are many categories of dissemination still available. You may wish to submit a version of your work in the form of a two-page Short paper, a four-page Technical Briefing, a Poster or a Demonstration (deadline for all categories 30th May). The Program Committee is keen to see your work represented at the conference in the following context: *** The committee particularly felt that the work described in your submission would make a compelling demonstration that would generate a lot of interest. If you would be prepared to submit your work to appear in the conference demo sessions, please email the Demo Chair ht03_demos@ht03.org as soon as possible. *** The committee particularly felt that the results that you describe would make an arresting poster. If you would be prepared to submit a version of your work to appear in the conference poster sessions, please email the Poster Chair ht03_posters@ht03.org. Thank you for your interest in HT03: as you can see from the web site there are many opportunities still available. We are anticipating a lively conference and would value your participation. --- Les Carr & Lynda Hardman HT03 PC CoChairs ===================== REVIEWS ==================== REVIEWER SCORE: 6 ***Comments to Authors I like the way you create three different types of visual markers for different elements and functions of data-presentation & the way these metaphors fit (e.g. the break-lines). I have a few issues, though - or points of interest where your audience might like to learn more: - In the introduction, you mention webpages. In how far can your model work for webpages? Would it replace the browser or run in the browser window (like those JavaScript-based shifting-fucus "3D"-navigations that were fashionable a year or two ago)? - 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? - 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 still non-disruptive? - Where can you implement this model? Website-navigation, data-retrieval on the internet, on your local machine? How do you index data/ files, do you need an author who creates the links or does the tool crawl? Would the software be a permanent replacement of other retrieval tools (folder-structure)? ***Summary Comments -------------------------------------------------------- REVIEWER SCORE: 6 ***Comments to Authors There is a deep and rich history of research surrounding annotation of digital documents, tackling many of the issues you have no doubt encountered with your buoys (and some you apparently have not anticipated). Look for author names Denoue, Golovchinsky, Wilensky, Brush, Bargeron, and Marshall. ***Summary Comments This paper presents some interesting and useful in-situ context-preserving annotation and navigation UI techniques. -------------------------------------------------------- REVIEWER SCORE: 6 ***Comments to Authors This was a very exciting submission. Although it might not be mature enough for a full paper at this conference I urge the author(s) to keep trying. If it is not accepted (as a full or short article) at HT this year then you should try UIST or Document Engineering. I hope to see a demonstration in Nottingham! Here are some notes I jotted while reading the submission: There is no reason whatsoeer to believe the explanation based on [20]. See McKendree et al.`s homeopathic fallacy article at . However, innovative new interfaces don`t need to be rigorously justified before testing. 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. Everyone is familiar with the apparent paradox of spatial reasoning ability and success with hypertext. This issue must be addressed if only in passing. In section 2.2: if evidence is available (aboutthe amount of attention needed) then it should be presented. 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)? instead of ``improves recognizability`` would it be more correct to say it could promote more recognizability? What are affine functions? Did you mean affined? ***Summary Comments new 3D interfaces for annotation style links clearly designed with a particular subset of users in mind although the article does not say who they are weak justification but an interesting design -------------------------------------------------------- REVIEWER SCORE: 3 ***Comments to Authors 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 allow the user to specify the target buoy easily. 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 devices are really novel in the filed of visualization or human interface. Only proposing buoys and unique background colors as just an interesting display method is insufficient to present in this conference. ***Summary Comments -------------------------------------------------------- ***Comments to Authors The overall rankings for this paper were 6,6,6,3,4 recalling that the ratings mean: 10/09 = Definitely accept (very high quality) 08/07 = Accept (good quality) 06/05 = Accept if room (marginal quality) 04/03 = Likely reject (low quality) 02/01 = Definitely reject (has no merit) As an attempt to provide a compelling 2.5D, animated, textured interface onto a hypertext world it clearly provoked interest. For 3 reviewers the work reported is enough to merit a cautious recommendation to `accept if room`, while 2 others were less convinced. The consensus therefore is that there are some significant weaknesses in this as a full paper. The programme committee`s view was that this could make a good Technical Briefing paper - published in the proceedings and including a demonstration. Details will be announced shortly about the requirements for this category of contribution. Specific points: 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 relevant to hypertextual transclusion, or applicable to any domain where there is hypertext or annotation? 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. 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 with colour screenshots or even better a screen movie would be worth considering to communicate the work). Simon Buckingham Shum Assoc. Papers Chair ***Summary Comments -------------------------------------------------------- REVIEWER SCORE: 4 ***Comments to Authors This paper is concerned with novel user interface techniques that exploit modern graphics accelerators. It certainly contains some interesting new ideas. It also shows a good appreciation of the literature. Nevertheless I do not recommend accepting it. 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 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 by no means simple. An early example would, for instance, have made it clear that buoys are opaque (initially I had assumed they were see-through, though perhaps that was my mistake). There is a textual description of an example in Section 4, but this too is complex and relies on an understanding of Xanalogical storage. (I can understand the authors` desire to show the full capabilities of their system, but this goes too far, too fast.) 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. 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. (b) it was unclear to me whether a fragment has to be textual (the first paragraph of 2.2 implies this). ***Summary Comments Promising ideas, but the paper is hard to understand and there is no evidence that the ideas are usable in practice. -------------------------------------------------------- ----- End forwarded message ----- _______________________________________________ Gzz-dev mailing list Gzz-dev@nongnu.org http://mail.nongnu.org/mailman/listinfo/gzz-dev