|
This guide describes the format, deadlines and other relevant information for
submissions to UIST 2009. Authors submitting material to
UIST 2009 should use this guide to discover how the review process works, and hence how to write more
successful submissions.
UIST features papers, tech notes, demos and posters, as
described in the Call for Participation. While the material in this
guide is primarily oriented towards paper and tech note authors, its
general emphasis on quality and stringent review is also applicable to
authors of demo and poster submissions. Accepted papers and tech notes
will be presented during three days of technical sessions at the
conference and published in the conference proceedings.
Paper and technote submissions must not have been published
previously. A paper is considered to have been previously published if
it has appeared in a peer-reviewed journal or meeting proceedings that
is reliably and permanently available afterward in print or electronic
form to non-attendees, irrespective of the language of that
publication. This includes papers that are reviewed only as abstracts,
but are published as a complete paper. If the previous publication is a
poster or short paper, then a longer and more complete paper on the
same topic by the same authors may be submitted to UIST; however, the
onus is on the authors to indicate how the submission contributes
substantially over the previous shorter publication, and the reviewers
will take the prior shorter publication into account when determining
the contribution and suitability of the submission. In these
situations, the new paper must offer substantial new knowledge over the
previous shorter publication and the new contribution must be clear.
Non peer-reviewed documents such as theses, tech reports, patents, and
abstracts-only in other conferences are not considered prior
publications under this policy, and thus do not preclude submission of
a complete paper on the same topic by the same authors; however, the
prior work should always be referenced appropriately. Furthermore, a paper identical or substantially similar (or
even a subset or superset) in content to one submitted to UIST should
not be simultaneously under consideration at another conference or
journal during the entire duration of the UIST review process (i.e.,
from the submission deadline until the notification of decisions are
emailed to authors). This restriction applies even if the overlap in
review timelines between UIST and another venue is just a few days or a
few hours, and even if it is your intention to withdraw the submission
from the other venues as soon as it is accepted by one of them. This
restriction also applies even if the other venue allows simultaneous
submission. We will make every effort to identify simultaneous
submissions, and UIST reviewers are often familiar with the papers
under review at other related conferences and journals; as such,
submissions that are substantially similar run the risk of being
rejected by UIST and the other venues on grounds of duplication alone. You are encouraged to submit a revised and extended version of
your UIST paper to a journal such as ACM Transactions on Computer-Human
Interaction or Human-Computer Interaction after it has been presented
at the conference.
This year for the first time both papers and tech notes submission will be anonymous.
We will use a model similar to CHI that does not attempt to conceal all traces
of identity from the body of the paper. Authors are expected to remove author
and institutional identities from the title and header areas of the paper, as
noted in the submission instructions.
Authors should not use anonymous citations (by blanking their
name or using Anonymous as an author) for references to their
previous work. Instead, authors should refer to previous work in
the third person (i.e. as if they were not the authors). This
will ensure that reviewers can take into account previous
research by the authors. Further suppression of identity in the
body of the paper is left to the authors' discretion.
Submissions to the Posters, Demos, and Doctoral Symposium track will be non-anonymous, as in previous years.
UIST is a peer-reviewed conference, which means that each paper
is read by several reviewers. Unlike the reviewers for a refereed
journal, UIST reviewers cannot suggest complex changes to the paper and
review the paper again after the author has modified it. The paper must
be acceptable as originally submitted, although reviewers may request
minor modifications before publication (see the "Conditional
Acceptance" section below). The reviewing process is administered by the program
chair, who selects and coordinates the program committee. The program
committee is a group of user-interface researchers —professionals
selected for their knowledge of the field, their experience with UIST,
and their willingness to serve the community in this manner. The
committee members act as senior reviewers for the conference Each paper and tech note is allocated to two program
committee members, based on the subject area discussed in the paper as
defined by the title, abstract, and a brief look at the body of the
paper. Papers that clearly fail to meet UIST's standards for
applicability, originality, completeness, or page length may be
rejected at this point. The committee members serve as the paper's
"primary" and "secondary reviewers. The primary reviewer is responsible for commissioning two
"external" reviews from reviewers who are not on the program committee. The secondary reviewer is responsible for commissioning one extra
"external" reviews from reviewers who are not on the program committee. Every effort is made in selecting reviewers to ensure a fair and
unbiased review process. All reviewers are instructed to abide by the UIST paper review process code of ethics. All reviews (two from the program committee and three from external reviewers) will be available to authors during the rebuttal period.
When the external reviews are complete, authors will have the
opportunity to post a rebuttal to the reviews on the electronic
submissions web site. You should use your rebuttal to address any
questions raised by the reviewers, or to note factual or technical
errors that may have been made by the reviewers. You cannot use the
rebuttal to add new data, results, or other new material to your paper.
It is also a really bad idea to belittle the reviewers or their
comments; most reviewers are highly regarded experts in user
interfaces, and most do an excellent and conscientious job. No paper is
perfect. If you insult the reviewers, it will give the impression that
you did not understand or take the time to reflect on criticisms raised
in the reviews. Your goal for the rebuttal should be to honestly answer
the questions and concerns raised by the reviewers, and give the
program committee confidence that you have read the reviews carefully
and are willing to revise your paper to address or acknowledge the
shortcomings noted by the reviewers. However, no rebuttal can help a
paper with reviews that consistently recommend rejection.
By
the time the program committee meets in person in June, each paper will
have been reviewed at least five times and the opinions collected,
resulting in a list of papers ordered by review results. Papers
uniformly receiving reviews that strongly recommend acceptance are
usually accepted without much further discussion; those uniformly
receiving rejection ratings also receive little further attention. The
balance of the meeting is spent deciding which of the other papers to
include in the program. For the majority of papers that receive a mixed reaction
from reviewers or that the program committee members responsible deems
require extended discussion. Each committee member will receive about seven papers as a primary
reviewer and seven more as a secondary reviewer, and is responsible
for reviewing all these papers. Thus, to stand out, your paper must
clearly spell out the problem that it is solving, state how you solved
it, and make a convincing case as to why this forms an important
research contribution to user interface software and technology. A good
rule of thumb is that a reader knowledgeable about user interfaces, but
not necessarily an expert in the exact area of the paper, should be
able to clearly understand the problem and the contributions claimed by
the paper by the end of the Introduction section. Because program committee members attend the committee meeting in person, each paper discussed
at the meeting will be represented by at least two people who have carefully read the paper, the reviews, and
your rebuttal (and sometimes more than two when additional members are asked to read papers under
discussion). Committee members use all of this information to arrive at the fairest possible
decision on each paper. The UIST conference is very competitive and every year we must reject
many submissions that report interesting research contributions. Even for papers that are not
accepted, the program committee goes to great lengths to ensure that the reviews explain as clearly
as possible our decision and offer feedback of how to improve the paper to make a successful
submission in the future. Authors will be notified of conditional acceptance or rejection shortly
after the program committee meeting, on or before the date specified in the Call for Participation.
All decisions of the program committee are FINAL.
Contacting the program chair, or anyone on the committee, before the notification date to see
"how your paper did" is a really bad idea. Sending emails to the papers chair that argue about
the decision is an even worse idea.
All accepted UIST papers and tech notes are conditionally accepted
pending changes that the papers committee may suggest or require for
the final camera-ready draft of the paper. This means that your paper
will not be formally accepted to UIST until you revise your paper and
submit a final draft for approval by the program committee. The committee member responsible for a conditionally
accepted paper will include instructions that list suggested or
required changes deemed necessary by the program committee. Authors are
expected to carefully revise their manuscripts according to these
instructions and submit a final draft, along with a description of the
changes made (or why any suggested changes were not incorporated). The
committee member will check the final draft of the paper, and final
acceptance of the paper requires the author's satisfactory revision of
the draft according to the instructions of the program committee. The
electronic submission web site has a facility to exchange anonymous
messages with the committee member handling your paper, so that you can
further discuss your planned revisions if necessary. You also have the
right to withdraw your paper if you do not wish to make the requested
revisions.
Conditionally accepted papers which do not
make satisfactory revisions may be rejected at the discretion of the
papers chair. However, you will not have to worry about this as long as
you make a good and honest effort to improve your draft and discuss the
changes with the anonymous committee member who is assigned to check
the revisions to your paper.
A
good UIST submission will result in both a respectable document for the
proceedings and a good conference talk. As an author, you should ask
yourself the following questions before writing your paper or tech
note. Submissions that do not provide good answers to these questions
are unlikely to be accepted. What problem are you solving?
There
is no point in publishing a paper unless it presents a solution to a
problem. Try to state all your constraints and assumptions. This is an
area where it can be invaluable to have someone not intimately familiar
with your work read the paper. Include a crisp description of the
problem in the abstract and try to suggest it in the title. The choice
of senior reviewer for the paper is based almost entirely on the answer
to this question.
What were the previous solutions?
What
are the relevant published works in your problem area? What
deficiencies in their solutions are you trying to overcome? How does
the new solution differ from previously published results? Don't expect
the reviewers to know this information without your telling them in the
paper, as they are unlikely to remember the precise details of all the
relevant literature. Make specific comparisons between your work and
that described in the references; don't just compile a list of vaguely
related papers.
How well did you solve your problem?
Based
on your problem statement, what did you accomplish? You are responsible
for proving that the problem is solved. Include pictures, statistics,
or whatever is required to make your case. If you find this part of the
paper difficult to write, perhaps the work is not yet finished and the
paper should be deferred until next year.
What does this work contribute to the field?
What
are your new ideas or results? If you don't have at least one new idea,
you don't have a publishable paper. Can your results be applied
anywhere outside of your project? If not, the paper is probably too
special-purpose for UIST. On the other hand, beware of trying to write
a paper with too large a scope.
Is the paper complete?
The
question that generates the most discussion at the program committee
meeting is whether a paper is complete. If the paper presents an
algorithm or technique, an experienced practitioner in the field should
be able to implement it using the paper and its references. If the
paper claims to present a faster or more efficient way of implementing
an established technique, it must contain enough detail to redo the
experiment on competing implementations. When you quote numbers, be
sure that they do not lie; state clearly whether they were measured,
simulated, or derived, and how you did the measurements, simulations,
or derivations. For example, CPU time measurements are meaningless
unless the reader is told the machine and configuration on which they
were obtained.
Does the paper contain too much information?
Many
large, poorly written papers contain a good paper trying to get out. It
is the author's responsibility, not the reviewer's, to discover this
paper and turn it into the submission. If you have solved a single,
practical problem, don't try to generalize it for the purposes of
publication. If you have a formal theory or elaborate architecture,
don't include all the vagaries of the implementation unless they are
critical to the utility of the theory. Don't include the contents of
your user's manual; instead, describe the model or functionality
achieved. You should assume your audience has a working knowledge of
user-interface development and access to the major journals in computer
science, electrical engineering, and psychology. A short conference
paper can only present a few concise ideas well.
Can this paper be presented well?
While
UIST papers are judged primarily as technical papers, some
consideration is given to how suitable the topic is for a conference
presentation. Think of how you would present your ideas, and how big
the audience is likely to be. Papers that have a small number of
concisely stated new ideas and that are visually interesting tend to
appeal to a large audience and be easy to present. As recent
conferences clearly show, these criteria do not eliminate papers that
have taxonomies or strong theoretical content, or appeal to a
specialized audience, if they contain significant new ideas.
Papers
that present new algorithms, techniques, or hardware are the easiest to
write and review. If the content is truly new and effective, and makes
a significant contribution to the state of the art, the paper is likely
to be accepted for UIST. Equally valuable, but harder to write and
evaluate, are papers that describe systems and applications. While the
criteria above will be applied to all papers, here we offer some
additional guidance for authors of systems and applications papers.
A systems paper may present a
real system, either by a global
survey of an entire system or by
selective examination of
specific themes embodied in the
system. Alternatively, it may
present the design for a system
that includes ideas or
techniques you feel are
important to present to the
technical community, even
without an implementation. Make
it obvious from the abstract and
introduction which kind of paper
yours is.
If a system has been
implemented, include information
about how it has been used and
what this usage shows about the
practical importance of the
system. Do the users include
anyone other than the authors?
Do they depend on it for their
work or do they just play with
it? Have formal user studies
been done and, if so, what are
the results? While user testing
is not required for UIST papers,
authors should be careful not to
make unsubstantiated claims for
systems which have not been
tested. However, papers can say
that the system "might be easier
to use because . . ." or that
"feature xxx is expected to make
the system easier to use because
. . .".
Also, if the system has been
implemented, including screen
snapshots is vital to convincing
readers and reviewers that the
system is real. Do not fake or
redraw screen shots; fakery is
usually obvious and is a clear
indication that the system is
not real.
If the system is still being
designed, it is most important
to state the design criteria and
constraints. Back up your
decisions with references to
similar systems that are already
implemented, stating what
problems you are solving or what
solutions you are including in
your design. Reviewers tend to
be very skeptical of design-only
papers, unless there are new
ideas of obviously high quality.
It is very important that you
clearly identify what is
implemented and what is merely
designed. Do so at the beginning
of the paper, not the end!
The paper should emphasize
the novel aspects of the system,
what underlying themes are
present, what problems were
anticipated/encountered in
building the system, and how the
structure presented provides
solutions to these problems. In
general, avoid details that are
only of interest to users of the
system and concentrate on those
that would be interesting to
someone else building a similar
system. Avoid sweeping claims,
especially for paper designs!
Roy Levin and David Redell's
article
How (and How Not) to Write a
Good Systems Paper,
although oriented towards
operating systems, is highly
recommended for further
guidelines on writing systems
papers.
At UIST 2007, Dan Olsen ran a
panel on Evaluating Interface
Systems Research. We strongly
encourage you to read the
associated paper, which is
available on the
ACM Digital Library and on
Dan's web page.
An application paper presents
an application area and a
problem in that area that
benefited from innovative user
interface techniques. The
techniques used don't have to be
unique, but their use must not
be completely obvious. The
author should concentrate on
what was learned, and how well
the user interface works
compared to previous techniques
for solving the same problem. As
in a systems paper, the intended
audience should be other
user-interface developers, not
the end user. Successful
applications papers provide some
general insight into the use of
interactive techniques to solve
problems.
As previously stated, a UIST
paper is accepted or rejected
based on the ratings it receives
from the reviewers. Paper
reviewing is a volunteer
activity; the only benefit that
the reviewers get is the
knowledge that they have
contributed to the field. In
many ways, the success of the
technical program is more a
function of the quality of the
reviewers than the work of the
program chair or the program
committee. We are lucky to have
excellent reviewers for this
conference and paper authors
should be considerate of them.
Many of the senior people in
this field receive a large
number of papers to review each
year. With this in mind, authors
should think about their
reviewers when they are
preparing their papers. In the
following paragraphs we provide
some advice on how to prepare
your paper so it makes the best
impression on a reviewer.
The most important point is
to put a reasonable amount of
effort into the production of
your paper. When the author
appears to have put little
effort or thought into the
production of a paper, the
reviewer is not motivated to
read the paper carefully and
produce a good review. There is
no excuse for spelling mistakes
in papers, since spelling
checkers are now widely
available. A large number of
misspelled words in a paper just
indicates to the reviewer that
the author didn't care enough
about his or her paper to run
the spelling checker on it. With
this attitude on the part of the
author, why should the reviewer
bother doing a good job? The
same goes for missing
references, mislabeled figures,
and other trivial problems that
could be caught by thorough
proofreading. Don't expect
reviewers to read your paper
carefully if you are not willing
to read it carefully first!
UIST reviewers will have
several papers to read in a
short period of time. Therefore,
you should write your paper so
that it is easy to read. Try to
write your paper so it flows
smoothly. A paper that is easy
to read will usually get a
higher rating.
Has this paper been submitted
to a conference before and been
rejected? If this is the case,
think carefully before you
submit it again! There must have
been some reason why the paper
was rejected. (Yes, we all blame
bad reviewing, but there must
also have been some other
reason.) Read the reviewers'
comments and try to determine
what they would like to see
changed, and then make those
changes. There is a surprisingly
good chance that a resubmitted
paper will be reviewed again by
a reviewer who gave it a poor
rating before (or who recalled
the deliberations over your
previous submission in a program
committee meeting of another
conference). If the paper has
not been changed to reflect that
reviewer's comments, it is
likely that your paper will get
an even lower rating. Yes,
sometimes the reviewer's
comments are wrong (reviewers
are only human after all), but
this usually implies that you
need to write more clearly or
provide more evidence for your
claims. Each of us has received
what we originally considered to
be bad reviews on some paper,
but after calm consideration
(weeks, or even months, later)
realized that these reviews
pointed out real faults in the
paper. If a hand-picked reviewer
is confused about what you are
saying, the chances are good
that the average reader will
also be confused!
A highly recommended
technique is to write the paper,
and let it sit on your desk for
a week or two. Then go back and
read the paper as if you were a
reviewer who doesn't know the
author. While you are writing a
paper, you are too closely tied
to the work to be able to
criticize it effectively. After
a break of a week or two, you
will be much more objective and
may see organizational problems
that weren't evident when you
were actively working on the
paper.
The single most important
thing you can do to improve the
odds of having your paper
accepted is to have your own
colleagues do an "in house"
review of it before you submit
it to the conference for formal
review. That requires beginning
far enough before the deadline
that you have a protective
cushion in your schedule, but
remember that the majority of
UIST papers are rejected. It's
far better to start a week or
two earlier and get your paper
accepted, than it is to get
rejected and feel as if you
wasted your time.
Since user interfaces are
inherently interactive, authors
are encouraged to include video
material with their papers. The
optional digital video that you
include with your submission
will be used only for
confidential internal
distribution to the reviewers.
Video
supporting papers or tech notes
submission should be anonymous.
Authors should make video
material short and accessible
without being misleading. A
video should give the same
impression as a live demo. For
example, a long computational
pause can only be removed if its
absence is made obvious through
techniques such as a visual
dissolve and a clear indication
(verbal and/or visual) of how
much time was removed. Videos
about technology mock-ups should
be clearly indicated as such.
Mock-ups should be avoided when
the video is about an
implemented system. The
supporting video accompanying a
submission for review is used
only to help reviewers evaluate
the submission; accepted paper
and tech note authors will have
the chance to submit a
higher-quality video for the
conference DVD proceedings.
Acceptable videos can be made
without expensive production or
special effects. A camcorder,
tripod, and some planning can
help guide the viewer's
attention. A smooth zoom into
the interaction area and then
out to the full screen is often
much more effective than a
static screen shot. Show how the
user manipulates the input
devices if that is relevant. The
DVD proceedings chairs have put
together a
guide describing how to make
good videos.
Supporting video need not be
stand alone, because the
reviewers will have the paper.
However, the paper must be
understandable without the
video, and the paper should not
include any references to the
video. You can assume that
everyone who has the video has
the paper, but not vice versa.
All authors are encouraged to
use video when appropriate as
part of their conference
presentation. A high-quality
master copy of each video file
should be sent to the DVD
proceedings chairs by the date
indicated in the acceptance
notifications for inclusion in
the DVD proceedings, which will
be distributed to conference
attendees only. Videos will also
be included as supplemental
material for the corresponding
papers and tech notes in the ACM
Digital Library. Information
will be provided later about the
video formats that will be
accepted for the DVD. It is not
necessary for the videos to
stand alone -- it is assumed
that everyone who sees the video
will also have access to the
paper proceedings.
Rest assured that we will not
duplicate for public
distribution any video included
with your initial submission, so
please don't worry! Those files
will only be used during the
review process, and then all
copies received by UIST will be
destroyed or deleted.
The final formatted length
for accepted papers is up to ten
double-column pages in the UIST
conference style (up to four
pages for tech notes).
Submissions for review must also
be in the final conference
format, except they should have
page numbers so
the reviewers can more easily
refer to portions.
Submissions must be in PDF
format, and video submissions
must be in one of the approved
file formats. Submission details
can be found at the UIST
Electronic Submission site (http://www.precisionconference.com/~sigchi).
If you want to
format-by-example (a reasonable
strategy), you can download a
sample pdf paper, properly
formatted. Sample
text-processing source files are
available for LaTeX (uistSample.tex
and
uist.sty), Microsoft Word (uistSample.doc)
and in RTF (uistSample.rtf).
A
PDF version of the latter
two sample files will help you
make sure that they are properly
loaded by your text processor.
Note that UIST uses 10 point
fonts with 11 points between
baselines for the body text
(unlike the official ACM sig
template, which uses 9 point
fonts). As indicated in the
samples, paper and tech note submissions are
anonymous.
Submissions to the posters, demos, and Doctoral Symposium track are not anonymous, and should use the UIST abstract format (doc, pdf).
It is to the author's
advantage to make the reviewer's
job as easy as possible! A
well-written paper containing
useful illustrations will appeal
to reviewers. Given that many of
the papers presented at UIST are
about systems, it is not
surprising that most accepted
papers include pictures or a
video to support the ideas
presented. It is not necessary
to have the ultimate picture or
the final, polished version of
the video for review. However,
the reviewers are much more
likely to prefer papers
containing some indication that
the author's claims are
supported than those that leave
the final results to the
reviewer's imagination.
An author of each accepted
paper or tech note is expected
to give a conference
presentation lasting
approximately 20 minutes for
papers and 15 minutes for tech
notes (exact length requirements
will be provided soon after
notification of acceptance).
Authors should include a note
with their submission if they
are planning anything for the
presentation that is not obvious
from the document; for example,
an author may point out that
there will be a video or live
demonstration at the conference
showing the results described in
a paper. Authors of accepted
submissions will be sent
detailed instructions for
preparing their conference
presentation.
The authors must be prepared
to sign an ACM copyright
transfer form before the
submission is published. The
author retains several rights,
including the right to post
versions on their home page and
employer web site. See the
ACM copyright policy and
copyright form for details.
This document was last
updated in February 2009 by
François Guimbretière (using
material provided by Saul
Greenberg), who inherited it
from Michel Beaudouin-Lafon, who
inherited it from Ravin
Balakrishnan and Chia Shen, who
inherited it from Ken Hinckley
and Pierre Wellner, who
inherited it from Dan Olsen, who
inherited it from Steve Feiner,
who inherited it from Joe
Konstan, who inherited it from
Michel Beaudouin-Lafon, who
inherited it from Ari Rapkin,
who inherited it from Beth
Mynatt, who inherited it from
George Robertson, who inherited
it from Marc H. Brown, who
inherited it from George
Robertson, who got lots of help
on it from Steve Feiner, Brad
Myers, Jock Mackinlay, Mark
Green, Randy Pausch, Pierre
Wellner, and Beth Mynatt.
| 
