|
This document was last updated on January 14, 2005 by
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.
This guide describes the format and deadlines for
submissions to UIST 2005. Authors submitting material to
UIST 2005 should use this guide to discover how the
review process works, and hence how to write more
successful submissions.
This is a guide for authors submitting papers to
UIST 2005, the Eighteenth Annual ACM
Symposium on User Interface Software and Technology.
Submissions must not have been published previously (or
be currently under review elsewhere) and should meet ACM
standards for a scholarly publication. Accepted papers
and TechNotes will be presented during three days of
technical sessions at the conference and published in
the conference proceedings.
UIST features papers, TechNotes, demos and posters,
as described in the
Call for Participation. While the material in this
guide for authors is primarily oriented towards paper
authors, its general emphasis on quality and stringent
review is also applicable to authors of TechNote, demo,
and poster submissions.
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 a
reviewer may request minor modifications before
publication. The papers
committee may suggest changes. Final acceptance of the
paper will be conditional upon the appropriateness of
those changes. There is a well-established procedure for
reviewing papers to determine their appropriateness and
acceptability for the conference. This guide is designed
to give potential authors insight into that reviewing
procedure and to present some guidelines on what
constitutes a successful UIST paper. It is not written
as an official UIST policy paper, but rather as a
guideline for authors planning to submit papers to the
conference.
The reviewing process is administered by the program
chair(s), who select and coordinate 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 is allocated to two senior reviewers,
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. One senior reviewer serves as the paper's
"primary" reviewer, and is responsible for commissioning
three "external" reviews from reviewers who are not on
the program committee. The other senior reviewer is the
paper's "secondary" reviewer. Each committee member will
receive about ten papers as a primary reviewer and about
the same number as a secondary reviewer, and is
responsible for reviewing all these papers. 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.
By the time the program committee meets 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. Because program committee members attend
the committee meeting in person, each paper will be
represented at the meeting by at least two people who
have read it (more than two when additional members are
asked to read papers under discussion). As soon as the
program committee meeting is finished, the selected
papers are sorted into sessions and the advance program
is finalized.
Authors will be notified of acceptance or rejection
shortly after the program committee meeting, on or
before the date specified in the Call for Participation.
With the notification of
acceptance may come revision suggestions. Authors are
expected to respond to these suggestions either by
making revisions or indicating why they should not be
made. Decision on acceptability of the revisions will be
made by the primary reviewer with disagreements between
the authors and the primary reviewer being decided by
the program chair. Contacting the program chair, or anyone on the
committee, before the notification date to see "how your
paper did" is a really bad idea.
A paper should include a descriptive title, an
abstract of 100 to 200 words, keywords, a discussion of
how the reported results relate to other work,
illustrative figures, and citations to the relevant
literature. The paper should present a sufficiently
detailed description of the new work, plus appropriate
background references, to convince reviewers that the
ideas presented are correct and the work performed could
be duplicated. The acceptance or rejection decision is
based on the content of the paper as submitted, since
there is no way to guarantee that shortcomings will be
corrected in the final version.
Appropriate topics include, but are not limited to:
- Novel, enabling technologies such as augmented
reality, perceptual user interfaces, tactile user
interfaces, tangible user interfaces, multimedia
user interfaces, CSCW user interfaces and
unconventional input devices.
- Innovative user interfaces for difficult or
challenging applications, such as the management of
large, complex information sets, or domains, such as
ubiquitous computing.
- Software architectures and development
environments for user interfaces, including those
associated with user-interface management systems,
window systems, toolkits, and knowledge-based user
interfaces.
- Tools and techniques for designing and
constructing user interfaces, including automated
tools, object-oriented techniques, and visual
programming. User interfaces with special system
software requirements, such as real-time,
multi-user, multi-modal, multi-threaded, or
distributed user interfaces.
- Technical aspects of user interfaces for people
with special needs.
A paper must not have been published previously and
we will make every effort to avoid duplicate publication
of papers. Furthermore, a paper identical to or
substantially similar to one submitted to UIST should
not be under consideration for another conference or
journal during the review process. If you have a
previously published paper or one that is under review
that you would like to distinguish from your UIST
submission, don't hesitate to clarify the distinction in
the body of your paper. UIST reviewers are often
familiar with the papers under review for other related
conferences and journals, and submissions that are
substantially similar run the risk of being rejected by
all venues on grounds of duplication alone. Professional
honesty dictates that authors should notify the program
chair immediately if a paper they have written that is
related to one submitted for review to UIST becomes
accepted for publication elsewhere. However, it is not
appropriate to submit substantially the same paper to
multiple conferences or journals, intending to withdraw
the paper from the other venues as soon as the paper is
accepted by one of them; at the very least, this will
waste the time of program committee members and
reviewers involved with the withdrawn papers.
You are encouraged to submit a revised and longer
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.
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.
Authors should make video material short (at most
five minutes for papers, three minutes for TechNotes)
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 verbal description 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 TechNote 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. Information will be provided later about
the video formats that will be accepted for the DVD. It
is not necessary for the videos to be of SIGCHI or
SIGGRAPH quality, and they do not need to stand alone --
it is assumed that everyone who sees the video
proceedings 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 tapes or 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 TechNotes). 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.
If you want to format-by-example (a reasonable
strategy), you can download a
sample paper, properly formatted. Sample
text-processing source files are available for LaTeX (sample04.tex
and uist04.sty) and Word (uistSampleRTF.rtf).
Please note that the content of these samples is dated;
there are lots of obsolete references to hardcopy
submission and marking up camera-ready copy. Also,
TechNotes may now be up to four pages long. However, the
format is correct. 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, submissions
are not anonymous.
Note:
On April 4, the Author's Guide was updated to include a
revised .pdf file, new .tex and .sty files for LaTeX
users and a revised version of the sample .rtf file for
Word users. The only important difference in the revised
files is that they actually use 11 points between
baselines as advertised. Submissions created using the
older files (with 12 points between baselines) will also
be accepted.
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 TechNote is
expected to give a conference presentation lasting
approximately 20 minutes for papers and 15 minutes for
TechNotes (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 and their employers, other than employees
of the U.S. government, must be prepared to sign a
copyright transfer form before the submission is
published. "It is a policy of ACM to own the copyrights
on its technical publications to protect the interests
of ACM, its authors, their employers, and at the same
time to facilitate the appropriate reuse of this
material by others." (Extracted from ACM Copyright
Procedures.)
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
TechNote. 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.
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. (I know, 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. |
