Advice for Submission

Advice for a Successful UIST Submission

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. Submissions that do not provide good answers to these questions are unlikely to be accepted.

What problem are you solving, or opportunity are you seizing?

There is no point in publishing a paper unless it presents a solution to a problem, or the taking advantage of a new opportunity or capability. 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 your paper. The abstract should succinctly present what you did in the work and what you found as a result. The introduction should include a crisp description of the problem or opportunity, why it matters, and an overview of the approach you took. The choice of reviewers for the paper is based heavily 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? How does it differ from commercial or other publicly available solutions?

Do not 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. Poorly written discussions of related work can lead to paper rejection.

How well did you solve your problem?

Based on your problem statement, what did you accomplish? You are responsible for demonstrating 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. Often the best papers are very specific in what they provide so as to deliver a concrete solution, and yet that solution has the power to generalize to other instances, situations, use cases, etc.

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?

A paper should be as succinct as possible. A long, poorly written paper will likely be rejected. 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 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 would 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 that appeal to a specialized audience, as long as they contain significant new ideas.

Production Quality

It is very important to put effort into the production of your paper. A paper that shows effort will likely induce a reviewer to put effort into their reviews. On the other hand, when the author appears to have put little effort or thought into the production of a paper, the reviewer will not be motivated to read the paper carefully and produce a good review. There is no excuse for spelling mistakes in papers. A large number of misspelled words in a paper indicates to the reviewer that the author didn't care enough about his or her paper to run a spell 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 or illegible figures, wrong format, and other trivial problems that could be caught by careful proofreading. Don't expect reviewers to read your paper carefully if you are not willing to read it carefully first!

Don’t Wait until the Last Minute

The submission site will open March 1, 2016 and close on April 13, 2016 at Noon PDT. This gives you six *weeks* to submit your paper. Rushing to submit on the day of submission deadline is unlikely to have good results. Beyond simple stress, a rushed submission is likely to have errors and production problems. In some cases, technical issues with the submission site may cause you to miss the deadline. With a 6-week submission window, consider submitting your work as late as 24 hours before the deadline (i.e., submit on April 12, 2016), and spend the remaining time correcting any typos or grammatical errors.

Resubmitting Rejected Papers

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(s) why the paper was rejected. (Yes, we all blame bad reviewing, but there must also have been some other reason.) Read previous reviewers’ comments and try to determine what they would like to see changed, and then make those changes. There is a 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 the Program Committee meeting of another conference). If the paper has not been changed to reflect that reviewers’ comments, it is likely that your paper will get an even lower rating. Yes, sometimes the reviewers’ 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 our 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.

Let It Sit

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.

In-House Review

Another strategy you can use to improve overall quality of your paper 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 in advance of the deadline that you have a protective cushion in your schedule.


Given that UIST is one the premier forums for innovations in human-computer interfaces, the review process is always going to be highly competitive. Writing a submission for UIST is a lot of work, but it is rewarded with the visibility and influence that UIST offers. We hope this document has helped give you some clear and concrete guidance on how to write a successful UIST submission.


This document was last updated in December 2015 by Jacob O. Wobbrock and Daniel Avrahami, who inherited it from Tovi Grossman and Bjoern Hartmann, who inherited it from Mira Dontcheva and Daniel Wigdor, who inherited it from Ivan Poupyrev and Takeo Igarashi, who inherited it from Hrvoje Benko and Celine Latulipe, who inherited it from Maneesh Agrawala and Scott Klemmer (who used material provided by Saul Greenberg), who inherited it from Francois Guimbretiere, 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.