UIST 2009 - Author Guide
21st UIST @ Monterey, CA






Sponsored by

Generous support also provided by industry

A Companion document to the UIST 2009 Call for Participation

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.

Anonymous submission process

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.


The Reviewing Process

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.

The Author's Rebuttal

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.

The Program Committee Meeting

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.

Conditional Acceptance

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.

Review Criteria

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.

Systems And Applications Papers

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.

Be Kind To Your Reviewers

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.

A Final Note

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.

Supporting Video Material

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.

Video Proceedings

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.

Conference Presentation

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.