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.
Paper submissions must not have been published previously in the English language. A paper is considered to have been previously published if it has appeared in a peer-reviewed journal or conference proceedings that is reliably and 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.
A paper cannot be considered a novel manuscript if it reports an incremental update or a small improvement to a previously published work. Although a paper can be based on an earlier archival publication by its authors, significant new developments and findings have to be reported for the paper to be considered a novel manuscript. As a rule of thumb, a paper has to include about 70% new material to be considered a novel contribution. We also encourage the authors to submit a complete work rather than dividing it into smaller pieces.
For UIST submission purposes, a paper is not considered to have been previously published if it was presented earlier in forms explicitly labeled as “non-archival,” even if they are, in fact archived. Such non-archival forms include, for example, CHI extended abstracts (including alt.chi, works-in-progress, posters, demos, etc.), the SIGGRAPH Emerging Technology venue, and UIST posters and demos. However, work that builds on previous non-archival work should typically contain at least 30% new material. Authors must cite this previous non-archival work in their new submission. If you are unsure about whether something is considered archival, please contact email@example.com. Authors wishing to submit work containing substantial portions of work published elsewhere will need to cite the source appropriately and may also need to check the copyright agreement with the original publisher to make sure that this is permissible.
English is considered the international language of ACM SIGCHI and its journals and conferences. Work that has previously been presented or published in a language other than English may be translated and presented or published in English in SIGCHI journals and conferences insofar as ACM SIGCHI is concerned. The original author should typically also be the author (or co-author) of work translated into English, and it should be made clear that this is, in fact, a translation; the original non-English work should be referenced. We encourage authors whose work was originally published in languages other than English to publish their work in English if they feel that the work was of sufficient relevance and quality to be useful to a wider international audience. Of course, it is not acceptable to translate the original work of another author and present it as one’s own. Authors wishing to publish an English version a work originally published in non-English will need to check the copyright agreement with the original publisher to make sure this is permissible.
UIST sees significant value in sharing early work through posters, demos, and informal venues like technical reports. UIST strongly encourages the submission of exciting, early research as a UIST poster or demo. Sharing preliminary research through these short, more lightly reviewed, work-in-progress or extended-abstract types of venues does not inhibit subsequent publication at UIST, provided that the UIST submission makes an important contribution beyond the previous, shorter document. Such documents, which typically appear in the adjunct proceedings, are not considered prior archival publications, and thus do not preclude submission of a paper on the same topic by the same authors. Prior work should, of course, be referenced appropriately.
A paper identical or substantially similar to (or even a subset or superset of) a paper submitted to UIST must 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 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.
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 UIST conference.
Paper submissions are anonymous. You are required to make a reasonable effort to purge identifying information from your submission:
Primarily — as with ACM CHI — it means that submissions must remove all author and institutional information from the title and header area of the first page of the paper. Author information should also be removed from submitted supplementary materials, in particular, videos. Submissions that do not do so may be rejected without review.
Furthermore, all references must remain intact. If you previously published a paper and your current submission builds on that work, the complete reference with author's name must appear in the references. Authors must refer to their previous work in the third person (e.g., “We build on prior work by Smith et al. [X] but generalize their algorithm to new settings.”) and avoid blank references (e.g., “12. REMOVED FOR REVIEWING”). Further suppression of identity in the body of the paper (for example, in an Acknowledgements section), while encouraged, is left to the authors’ discretion.
While the details of anonymization in the body of the paper are ultimately left to the authors’ discretion, we understand that some work is 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.
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.
UIST has a long tradition of excellent, thoughtful reviewing. This policy seeks to balance two goals. The first goal is to emphasize for all parties involved that reviews assess the content of a submission, not its authors. This is why names must be omitted from the masthead and reasonable efforts to maintain anonymity in the body of the paper should be taken. The second goal is to encourage papers that clearly explain the research. Sometimes doing so requires (at least implicitly) disclosing information about the authors or an institution. If you have comments or questions about this policy, please email firstname.lastname@example.org. 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.
The UIST review process is confidential and the confidentiality of submissions is maintained from their submission to their publication date. See the UIST 2018 Call for Participation for relevant dates.
The Program Committee and a set of external reviewers, both consisting of recognized experts, will review submitted papers. Then, at their Program Committee (PC) meeting, the committee will select those papers to be presented at UIST 2018. For 2018, the Committee will be using the following process:
Full reviews, which may have changed due to the rebuttal, online discussion, or discussion at the committee meeting, will be sent via email. The notifications will place each paper in one of the following two categories:
Conditionally accepted papers undergo a second review process in which a referee (an associate chair of the Program Committee) verifies that the final version of the paper is acceptable (that any required changes have been made, and that other changes made by the authors, perhaps in response to reviewer comments, have not compromised the paper in any way). The length of the camera-ready copy (rounded up to the nearest page) must be less than or equal to the length of the original submission unless there is a strong justification to increase the length of the manuscript, which should be agreed upon by the primary reviewer. This second and final stage determines the final acceptance status of all papers. The referees’ decisions are final. Papers that do not satisfy the referees in the second stage of review and/or that are not uploaded in final form by the final deadline , together with the original or revised versions of the submitted supplementary material, will be rejected. Accepted papers will appear in the conference proceedings.
There are many types of valid contributions to UIST, including new algorithms, techniques, systems, tools, hardware, devices, models and applications. We will do our best to ensure reviewers understand that there are many ways for a paper to make a significant contribution to UIST, and that papers should be reviewed according the nature of their contributions. In particular, our community has identified systems and applications papers as particularly challenging to write and evaluate. For authors and reviewers of such papers, we recommend consulting articles written on how to evaluate systems research and how to write systems papers:
Levin, Roy, and David D. Redell. How (and How Not) to Write a Good Systems Paper. ACM SIGOPS Operating Systems Review 17.3 (1983): 35-40.
Olsen, D. R. 2007. Evaluating Interface Systems Research. In Proceedings of the 20th Annual ACM Symposium on User interface Software and Technology. UIST '07. ACM, 251-258.
Another topic of discussion within our community has been the role of empirical evaluations within HCI research, specifically user testing. While user testing is not strictly required for UIST papers, 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. For more advice on this topic, we recommend the following article:
Greenberg, S. and Buxton, B. 2008. Usability evaluation considered harmful (some of the time). In Proceeding of the Twenty-Sixth Annual SIGCHI Conference on Human Factors in Computing Systems. CHI '08. ACM, 111-120.
See also the video guide. Since user interfaces are inherently interactive, authors are encouraged to include a Video Figure with their papers, which will be kept confidential during the review process. As with the rest of the paper, Video Figures should be anonymized. Authors should make Video Figures 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 video figure accompanying a submission for review is used only to help reviewers evaluate the submissions. Acceptable videos can be made without expensive production or special effects. A camcorder, tripod, and some planning can help guide viewers’ attention. A smooth zoom into the interaction area and then out to the full screen is often much more effective than a static screenshot. Show how the user manipulates an input device if that is relevant. Supporting video need not be stand-alone, because the reviewers will have the paper. Although the paper should be understandable without the video, the paper may include images from the video. For example, authors may use video sequences as figures showing actual use of the proposed system to give readers and reviewers an impression of how the interaction unfolds like and/or how users responded to using the presented system. As video figures will be included with the paper in the ACM digital library, authors may assume that everyone who has the video has the paper, and vice versa. The burden is on the authors to ensure that videos figures are rendered in file formats and codecs that are accessible on all common platforms. Please see the video guide for more details.
All paper submissions must be made in the SIGCHI papers format. (Note that this format utilizes the newer “Firstname M. Lastname” convention.). Note that references do not count towards the paper length. Submitted papers may also include page numbers so the reviewers can more easily refer to portions. Detailed format instructions are available at the SIGCHI conference publication format site. 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).
Authors have the option to choose the level of rights management they prefer. 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.
This document was last updated in January 2017 by 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.
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.
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 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.
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 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.
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.
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.
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.
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!
The submission site will open soon and close on April 5, 2018 at 5pm PDT. This gives you four *weeks* 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 month-long submission window, consider submitting your work as late as 24 hours before the deadline (i.e., submit on April 3rd, 2016), and spend the remaining time correcting any typos or grammatical errors.
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.
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.
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.