UIST features papers, demos, and posters, as described in the Call for Participation. While the material in this guide is primarily oriented towards paper authors, its general emphasis on quality and stringent review is also applicable to authors of demo and poster submissions. Accepted papers will be presented during three days of technical sessions at the conference and published in the conference proceedings.This author guide contains:
- Requirements concerning novelty and anonymity
- Guidelines on how to write a successful UIST paper
- Guidelines on preparing accessible submissions
- An Explanation on the Review, Rebuttal, and Camera-Ready Process
Important Information Concerning:
Novelty, Concurrent Submissions, and Anonymity
Previous Publications: UIST paper submissions must not have been published previously.
- A paper is considered published if it has appeared in a peer-reviewed journal or conference proceedings that is archived, i.e. permanently available afterward in print or electronic form to non-attendees (this includes papers that are reviewed only as abstracts, but are published as a complete paper). Papers previously published in a language other than English do not count as archival and may be submitted as novel work (keep the author list the same, reference the non-English work in an anonymized way, i.e., remove author names but list title and venue, include a pdf of the original paper without author names in the supplementary material, check the copyright agreement with the original publisher to make sure re-publication is permissible).
- A paper is not considered published if it has been presented in forms explicitly labeled as “non-archival” (examples include: CHI extended abstracts (including alt.chi, works-in-progress, posters, demos, etc.), arXiv.org, the SIGGRAPH Emerging Technology venue, tech reports, and UIST posters and demos). Such ‘non-archival’ work does not count against a paper submission even if the non-archival work was in fact archived as is common for UIST posters and demos from previous years that may appear in the ACM DL. Thus, presenting a UIST poster or demo does not prevent an author from submitting a full paper on the same topic in one of the following years.
Amount of New Content: A paper cannot be considered a novel manuscript if it reports an incremental update or a small improvement to a previously published work, instead significant new developments and findings have to be reported for the paper to be considered a novel manuscript.
- Novelty Over Existing Archival Work (i.e. previously published papers): a paper has to include about 70% new material to be considered a novel contribution over an existing archival work.
- Novelty Over Existing Non-Archival Work (i.e. previously shown demos, posters): a paper has to include about 30% new material to be considered a novel contribution over an existing non-archival work.
Authors wishing to submit work containing substantial portions of work published elsewhere will need to check the copyright agreement with the original publisher to make sure that this is permissible.
Concurrent Submission is Prohibited: Concurrent submissions to another conference or journal are not allowed. A submission is considered concurrent if the paper is identical or substantially similar to (or even a subset or superset of) the submitted UIST paper. This applies to the duration of the entire UIST review process, 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 even a few hours, and even if it is your intent to withdraw the submission from the other venues at the moment it is accepted by one of them. This restriction also applies even if the other venues do allow concurrent submissions. 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 the grounds of duplication alone.
Revision for Journals: You are encouraged to submit a revised and extended version of your published UIST paper to a journal such as ACM Transactions on Computer-Human Interaction or Human-Computer Interaction after it has been presented at the UIST conference.
Remove Identifying Information to Preserve Anonymity: Paper submissions are anonymous. You are required to make a reasonable effort to purge identifying information from your submission, remove all author and institutional information from the paper, the video, and all supplementary materials. Submissions that do not do so will be rejected without review. If you have to refer to your own work, please use the citation guidelines as described in 'Referencing Your Own Prior Work' below. While the details of anonymization in the body of the paper are ultimately left to the authors’ discretion, we understand that some work, such as widely publicized websites, applications, or performances, are difficult (or impossible) to anonymize without degrading the quality of the writing. In these cases, we encourage the authors to ensure that details relevant for review of this paper are included. The rules stated here apply to papers only. Submissions to the Posters, Demos, and Doctoral Symposium tracks should follow the anonymization guidelines in the respective calls for those tracks.
- talk about your own work in 3rd person and include a full reference with names
- if the previous own work has significant overlap, then also submit an anonymized version of the previous work as supplementary material in PCS.
Publicizing Your Work Should be Avoided During the Review Process: While publicizing and promoting work during the review process goes against the spirit of anonymous review, we understand that there are competing interests that make publicity important. The UIST community has agreed that such publicity should not be explicitly prohibited or penalized. However, we encourage authors to wait until the review process is over to publicize their work.
Video Figure Should Give the Same Impression as a Live Demo: Video figures are used only to help reviewers evaluate the submissions. They should give the same impression as a live demo: 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 and Mock-ups should be avoided when the video is about an implemented system.
User Studies Are Not Required: The UIST community has discussed the role of empirical evaluations within HCI research, specifically user testing, and wishes to emphasize that user tests are not strictly required for UIST papers; rather, papers must support the claims they make with evidence. The form of that evidence will vary based on the claims of the paper. Authors should be careful not to make unsubstantiated claims for new techniques, systems, or applications which have not been tested. In general, authors and reviewers should consider what the appropriate method of validation is for the specific problem or research questions that their paper is addressing.
Systems Contributions Need To Be Evaluated Holistically: The UIST 2021 Papers Chairs ask authors to explicitly state their contributions, including claims and scientific evidence, and ask reviewers to perform a holistic evaluation of papers, taking into account the difficult circumstances induced by the COVID-19 pandemic. In the technical HCI community, there is a long standing debate around how systems contributions are and should be evaluated. Many researchers experienced with this type of contribution have suggested a number of ways in which they could be evaluated more holistically. Below we summarize the key points and ask both authors and reviewers to please familiarize yourself with this work by referring to the cited papers:
- Just asking for usability testing is not adequate for evaluating complex systems. Neither is the search for “fatal flaws,” or focusing on what the system does not do. A more holistic approach to evaluating systems research is required. Olsen established a set of heuristics such as the versatility of a system (flexibility), how it reduces effort on designers (expressive leverage), how well the system allows designers to express their design choices (expressive match), and scalability to new, larger problems. — Daniel R. Olsen Jr. (UIST 2007): Evaluating User Interface Systems Research.
- Usability evaluation is important for some but not all user interface development situations. It is just one of many methods. It is important to consider whether usability evaluation would produce anything meaningful given the stage of system design. It is appropriate for settings with well-known tasks and outcomes but system innovations will evolve and often lead to a change in everyday practice. — Saul Greenberg & Bill Buxton (CHI 2008): Usability Evaluation Considered Harmful (Some of the Time).
- Many different evaluation strategies are used and appropriate in the larger technical HCI community: (1) demonstration based on novel or replicated examples, based on case studies, or based on scenarios; (2) usage studies including usability studies, A/B comparisons, walkthrough demonstrations (show and tell rather than use and test), and observation, and take-home studies; (3) technical performance evaluations including benchmarking against thresholds or the state of the art; (4) heuristics using a checklist approach seeing whether individual heuristics are satisfied or discussion based on heuristics (e.g., Olsen’s UIST 2007 heuristics above) — David Ledo, Steven Houben, Jo Vermeulen, Nicolai Marquard, Lora Oehlberg & Saul Greenberg (CHI 2018): Evaluation Strategies for HCI Toolkit Research
- Evaluating interactive systems research requires distinguishing (1) the code that implements a system and (2) the research contribution demonstrated or embodied in a system. For better understanding the wide range of possible systems contributions, we need to further distinguish (1) what a system accomplishes and (2) how it accomplishes that. In many systems contributions, code is used as a means to exploring a research problem, while for some, but not all, the contribution manifests itself directly in the code (e.g., toolkit vs. algorithm). — James Fogarty (CHI 2017 #HCI.Tools Workshop): Code and Contribution in Interactive Systems Research
If you are unsure about one of these requirements, please contact email@example.com.
How to Write a Successful UIST paper
A good UIST submission will result in both an effective 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? 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.
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? One question that often generates 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.
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 close on April 7, 2021 at 5pm PDT. This gives you weeks as of this writing, to submit your paper. Rushing to submit on the day of submission deadline will only create additional stress. Moreover, 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 long submission window, consider submitting your work as late as 24 hours before the deadline (i.e., submit on April 6st , 2021), 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.
Summary: Given that UIST is one the premier forums for innovations in human-computer interaction, the review process is always going to be highly competitive. Acceptance rates have historically been in the 20–25% range, amongst a very competitive field of submissions. 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.
Guidelines on preparing accessible submissions
UIST 2021 introduced tiered deadlines which were set up based on our continued commitment to accessibility, and on feedback from the larger UIST community. First, you are asked to submit your abstract, then the paper PDF, and finally Alt-Text and your optional video. This means, there is more time after the paper submissions to upload your optional video and make your submission accessible including alt-text and video subtitles. We believe these changes will overall help increase the quality of the conference. Below, we provide more information and resources to guide you through the process.
Alt-Text: To make the reviewing process more accessible, we ask you to provide Alt-Text (alternative text) for every figure, subfigure, and table in your document. Clearly start each line with the Figure identifier in the following format “Figure #.#” followed by the Alt-Text for that figure followed by a two new lines between each figure or subfigure. For more information on writing quality Alt-Text please read the SIGACCESS guidelines.
Video Subtitles: There are many ways to create subtitles for videos. One popular way is by uploading the video to YouTube and having YouTube automatically generate subtitles. You can keep the video private or unlisted and delete it immediately after. See the Closed Captions (CC) / subtitles section in the UIST Video Guidelines.
Accessible PDF: For the final submission deadline, you have the option to submit an accessible version of your paper PDF following the SIGACCESS guidelines. This PDF may be used by reviewers. However, this updated PDF should only include changes to improve accessibility.
From Submission to Presentation:
The Review and Rebuttal Process, Conditional Acceptance and Camera-Ready, Travel and Conference
Associate Chairs and External Reviewers: Each paper submitted for review will be seen by at least four different people (2 program committee members (1AC, 2AC) and 2 external reviewers (R1, R2), i.e. experts in the area who are not on the program committee). The 1AC knows the identities of the authors of the paper. The 2AC and external reviewers do not know the identities of the authors.
Assignment of Program Committee Members (1AC, 2AC): In the week following the submission deadline, the Program Chairs will assign each submitted paper to a primary reviewer (1AC) and a secondary reviewer (2AC) who are both members of the program committee.
Desk Rejections: The primary reviewer may, upon conferring with the secondary reviewer and the program chairs, recommend a paper be rejected without additional reviews. Desk rejects will only occur for papers that are clearly off-topic for UIST, if they are incomplete, if they violate rules of this Author’s Guide, or if they are discovered to have been published previously or to have been submitted concurrently at another conference or journal.
Quick Rejections: A paper may be quick rejected, if the primary and secondary reviewer agree that the paper clearly solves a problem that is known to be solved already; or if it does not cite (and the authors seem unaware of) important prior work on the same problem and doesn't address how it is different; or if it has no evaluation via proof, experiment, or analysis when such is required; if it is solving a problem sufficiently minor that the senior primary and secondary reviewer do not believe that it belongs in the program; if its overall level of quality is clearly not appropriate for UIST; or if it addresses a topic that is clearly outside the realm of UIST.
Assignment of External Reviewers (R1,R2): Each paper submitted for review will be seen by at least four different people (2 external reviewers (R1,R2) and 2 program committee members (1AC, 2AC)). The primary reviewer (1AC) distributes each paper to two external experts
External Reviewers Write Reviews: First, the two external reviewers and the 2AC will write full reviews. Note that the 2AC is required to write a full personal review, not a meta-review, and will not be able to see the external reviews before they submit their own.
Primary Meta-Review (1AC): After the 2AC and external reviews are submitted, the 1AC will summarize the reviewer sentiment in a meta-review. This meta-review should be based on the 2AC’s and external reviews, but may also include a personal review of the 1AC. If there is substantial disagreement among the external reviewers, the 1AC is required to prepare a full personal review of the paper.
Discussion: Between review submissions and the program committee meeting, the 1AC may elect to begin a discussion amongst the reviewers to clarify reviews and strive for consensus.
Rebuttal: Authors of papers have two weeks to submit a rebuttal if they feel that the reviewers have made substantive or factual errors, to clarify concerns or uncertainties, or to answer specific questions raised by the reviewers. We encourage the submission of a rebuttal regardless of the scores that authors receive in case the concerns of reviewers come up in discussion at the program committee meeting. The rebuttal is confined to 5000 characters in length and must be self-contained. The rebuttal is for responding to specific questions for clarification raised by reviewers. It may include novel material as long as it can be fit into the rebuttal length. External links, e.g., to video material or additional data, are not allowed unless explicitly requested by an AC. Since the 2AC and external reviewers do not know the names of the authors, the authors should maintain their anonymity in the rebuttal.
Post-Rebuttal Discussion: After the rebuttal has been submitted, the program committee members (1AC, 2AC) and externals (R1,R2) will read the rebuttals, confer about the papers, and prepare a recommendation for the program committee meeting. Since the external reviewers do not know the authors’ and each other's identities, they must maintain anonymity during all online discussion. The preliminary recommendation agreed on at this stage will be either accept, reject, or if agreement on a recommendation cannot be reached, a third option is to table the paper for further review and discussion at the program committee meeting.
Post-Rebuttal Meta Reviews: After the discussion, the primary reviewer (1AC) will revise the meta-review, taking into account the rebuttal. In some cases, a third reviewer from the program committee (3AC) may be assigned based on requests by the 1AC and 2AC.
Program Committee Meeting: All members of the program committee meet at the program committee meeting to determine the acceptance or rejection of each paper. In cases where a consensus on a paper was not reached during the pre-meeting discussion phase, additional committee members may read the paper (3AC, 4AC), and their evaluations will be taken into account in the decision.
Notification of Decision: After the program committee meeting, authors will be informed if their paper was rejected or conditionally accepted. Full reviews, which may have changed due to the rebuttal, online discussion, or discussion at the committee meeting, will be sent via email a few days later to provide additional context for the decision and guidance for improving the paper. Conditionally accepted papers need to go through the camera-ready process as described in the next section, i.e. need to be improved based on the changes described in the rebuttal before final acceptance.
A very small number of papers may be chosen by the program committee to be shepherded. These papers usually make compelling contributions, but require more substantial changes to meet the bar for acceptance than conditionally accepted papers. For these papers, an AC, who is generally either the 1AC or 2AC, will be assigned as a shepherd, and will initiate a separate review process with the authors to make sure the paper meets the bar for acceptance before the camera-ready deadline.
Preparing the Camera-Ready Version
Integrating Requested Changes into the Paper: All acceptance notifications emailed out after the program committee meeting are conditional pending changes as outlined by the authors in the rebuttal and any additional changes the program committee may suggest for the camera-ready version. After authors upload their revised paper, the 1AC will check that all changes have been made and that required changes have not compromised the paper in any way. Only when the 1AC confirms that everything is in order, will the paper be accepted for final publication. Papers that do not satisfy the reviewer requests or that are not uploaded in the final form by the camera-ready deadline will be rejected.
Selecting a Copyright Option: ACM offers three different options for authors to manage the publication rights to their work. Please consult the ACM Authors Site (http://authors.acm.org/). The SIGCHI Submitter Agreement also requires that authors hold copyright to the content of their submission, and will obtain appropriate permissions for any portions of the content that are copyrighted by others.
Publication and Public Dissemination Date
NEW FOR THIS YEAR: Papers will be made available to registered conference attendees as early as the week after the camera-ready deadline. Thus authors should anticipate that the official publication date, also known as the public dissemination date, for their papers will be August 11, 2021. Any internal approvals and intellectual property obligations may need to be completed by this date.
Preparing the Conference Presentation
Presentation Time: All papers will have the same presentation time at the conference and there will be no distinction made between papers based their length. The exact talk duration will be determined when the program is finalized and the total number of papers is known.
Attending the Conference
- The ACM-W Scholarships program is intended to provide support for women undergraduate and graduate students in Computer Science and related programs to attend research conferences. The student does not have to present a paper at the conference she attends. More details are available.
- UIST 2021 plans to offer registration assistance and scholarships to individuals from developing countries, students, and those suffering from hardships due to COVID-19. Further details on these programs will be announced when registration becomes available.
This document was last updated in January 2021 by Ranjitha Kumar, Michael Nebeling with input from Jeff Nichols and Gierad Laput, who inherited it from Fanny Chevalier and Stefanie Muller who inherited from Michael Bernstein and Katharina Reinecke, who inherited from Andrew Wilson, who inherited from Chris Harrison and Jen Mankoff, who inherited it from 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.