fenfire storm ja libvob live-toiminnan mahdollistajina (Re: [Gzz] address@hidden: ACM HT03: Paper Results] (buoyoing) (fwd)

[Alatalo Toni]

Kyperjokeille ja Fenfireläisille tiedoksi: jahka saan gradun pakettiin
(viestintäympäristöistä) olisi tarkoitus keskittyä väikkäriin
live-käytöstä, jota on nyt VJ-keikoilla tullut treenattua. Tässä lyhyesti
siitä miten Fenfire Storm ja Libvob ovat live-toiminnan mahdollistajia:

On Mon, 28 Apr 2003, Oinas-Kukkonen Harri wrote:

> > storm asiaa työstän niin sattui nuo toisetkin kommentit silmiin,
> > olen ajatellut jatkossa osallistua tuohon visuaaliseen puoleen (libvob)
> Mitä tämä tarkoittaa re: väikärin painotus?

väikkärissä tarvin molempia.

Storm mahdollistaa live-toiminnan, kun data saadaan sinne mihin tarvitaan
(esim. kokoustilaan), ja sitä voidaan siellä editoida, vaikkei yhteyttä
projektin palvelimelle olisikaan. tällä hetkellä VJ-keikoista menee
valtaosa tiedostonhallintaan, isoilla keikoilla kymmeniäkin tunteja ja
pienillä helposti kaksi.

Libvobia käytetään työstettävän asian reaaliaikaiseen visualisointiin,
joka live-tilanteessa esim. projisoidaan seinälle kaikkien nähtäväksi,
sekä mahdollisesti henkilökohtaisten (kontrolli)laitteiden kuten
läppäreiden ja nykyisten läppäriden tehoisten kännyköiden ruuduille.
Libvob on siksi tähän hyvä mokkula kun siinä hyödynnetään uusimpien
näytönohjainten ominaisuuksia, joilla saadaan sellaisia työkaluja käyttöön
reaaliajassa joita nykyvälineillä voidaan vain laskea etu/jälkikäteen.
tänään? demottava FenPDF josta on jo videoitakin fenfire.org:ssa
havainnollistaa näitä mahdollisuuksia hypermedia-authoroinnissa.

> Olisi ihan kiva browsata uudelleen läpi sen paperin
> review-tulokset, jossa säkin olit authorina, if ok.

minulla on siitä posti kesken, turva-analyysistä lähinnä,
siitä kirjoitan esseen langattoman tietoliikenteen tietoturvan kurssille
jonka tentin eilen.

> Harri

~Toni

> > 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
> > address@hidden 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 address@hidden
> >
> >
> >
> > 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
> > <http://doi.acm.org/10.1145/208666.208687>.
> > 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
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/gzz-dev
> >
> >
>
>
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>