A companion document to the
UIST'97 Call for Participation.This document was last updated on October 26, 1996 by George Robertson, who inherited it from Marc H. Brown, who inherited it from George Robertson, who got lots of help on it from Steve Feiner, Brad Myers, Jock Mackinlay, Mark Green, Randy Pausch, Pierre Wellner, and Beth Mynatt.
This guide describes the format and deadlines for papers being submitted to UIST'97. Authors submitting material to UIST'97 should use this guide to discover how the review process works, and hence how to write more successful submissions.
This is a guide for authors submitting papers to UIST'97, the Tenth Annual ACM Symposium on User Interface Software and Technology. Submissions must not have been published previously and should meet ACM standards for a scholarly publication. Accepted papers will be presented during three days of technical sessions at the conference and published in the conference proceedings.
UIST features Panels and TechNotes in addition to papers. Please see the Call for Participation for guidance on how to prepare these submissions. While the material in this guide for authors is primarily oriented towards paper authors, its general emphasis on quality and stringent review is also applicable to authors of panel and TechNotes proposals.
UIST is a reviewed conference, which means that each paper is read by several reviewers. Unlike the reviewers for a refereed journal, UIST reviewers cannot suggest complex changes to the paper and review the paper again after the author has modified it. The paper must be acceptable as originally submitted, although a reviewer may request minor modifications before publication. There is a well-established procedure for reviewing papers to determine their appropriateness and acceptability for the conference. This guide is designed to give potential authors insight into that reviewing procedure and to present some guidelines on what constitutes a successful UIST paper. It is not written as an official UIST policy paper, but rather as a guideline for authors submitting or planning to submit papers to the conference.
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 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.
Papers must be received by the program chair by deadline announced in the Call for Participation. If you intend to be one of the many who send your paper at the last minute, please use a reputable courier service. Papers that get lost in transit may not arrive in time to be considered. Your paper will be acknowledged by email when it arrives, so if you do not hear from us within a week from when you expect your paper to have arrived, please send email.
Each paper is allocated to a senior reviewer, 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. Each committee member will receive about ten papers, and will be responsible both for reviewing each paper and for sending the paper to at least two (usually three) other reviewers for additional comments. Every effort is made in selecting reviewers to ensure a fair and unbiased review.
By the time the program committee meets in late June, each paper will have been reviewed at least four times and the opinions collected, resulting in a list of papers ordered by review results. Papers uniformly receiving reviews highly recommending 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. As soon as the program committee meeting is finished, the selected papers are sorted into sessions and the advance program is finalized.
Authors will be notified of acceptance or rejection by the notification date listed in the Call for Participation. Contacting the program chair, or anyone on the committee, before the notification date to see "how your paper did" is a really bad idea.
A paper should include a descriptive title, an abstract of 100 to 200 words, keywords, a discussion of how the reported results relate to other work, illustrative figures, and citations to the relevant literature. The paper should present a sufficiently detailed description of the new work, plus appropriate background references, to convince reviewers that the ideas presented are correct and the work performed could be duplicated. The acceptance or rejection decision is based on the content of the paper as submitted, since there is no way to guarantee that shortcomings will be corrected in the final version.
Appropriate topics include, but are not limited to:
A paper must not have been published previously and we will make every effort to avoid duplicate publication of papers. In general, a paper identical to or substantially similar to one submitted to UIST should not currently be under consideration for another conference or be submitted later to another conference unless it has been formally withdrawn from consideration (or been rejected) by UIST. If you have a previously published paper or one that is under review that you would like to distinguish from your UIST submission, don't hesitate to clarify the distinction in the body of your paper. UIST reviewers are often familiar with the papers under review for other related conferences, and duplicate submissions can run the risk of being rejected by both conferences on grounds of duplication alone. Professional honesty dictates that authors should notify the program chair immediately if a paper they have written that is related to one submitted for review to UIST becomes accepted for publication elsewhere.
You are encouraged to submit a revised and longer version of your UIST paper to a journal such as Human-Computer Interaction or ACM Transactions on Computer-Human Interaction after the conference.
Since user interfaces are inherently interactive, authors are encouraged to include video material with their papers. The video tape that you include with your paper submission will be used only for confidential internal distribution to the reviewers. Please include six copies of your tape with your paper, in VHS NTSC format.
Authors should make video material short (less than eight minutes) and accessible without being misleading. A video should give the same impression as a live demo. For example, a long computational pause can only be removed if its absence is made obvious through techniques such as a visual dissolve and a verbal description of how much time was removed. Videos about technology mock-ups should be clearly indicated as such. Mock-ups should be avoided when the video is about an implemented system. Use a tripod if at all possible and try to use cinematographic techniques to guide the viewer's attention. A smooth zoom into the interaction area and then out to the full screen is much more effective than a static screen shot. Show how the user manipulates the input devices if that is relevant. Finally, expensive production values are not required. Very effective videos can be made with a camcorder and no editing.
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.
The video chairs of the CHI and CSCW conferences have put together a very nice document describing how to make good videotapes. We've prepared an edited version of the CHI'97 guide, with material specific to CHI deleted. Don't be intimidated by the guide: UIST videos are intended to "bring to life" the static diagrams; they are neither refereed nor archival. However, if you are going to take the time to prepare a videotape, you may as well at least scan the words of wisdom provided by the CHI and CSCW video chairs.
Last year we had a video proceedings for the first time, and we expect to do so again this year. All authors are encouraged to use videotape as part of their conference presentation. A high-quality master copy of these tapes should be sent to the program chair by late September 1997 (the exact date will be determined later) for inclusion in a video proceedings that will be distributed free to conference attendees only. It is not necessary for the tapes to be of SIGCHI or SIGGRAPH quality, and they do not need to stand alone -- it is assumed that everyone who sees the video proceedings will also have access to the paper proceedings.
Rest assured that we will not duplicate for public distribution any tape included with your initial April submission, so please don't worry! Those tapes will only be used during the review process, and then will be destroyed.
Final formatted length for accepted papers will be ten double-column pages in the ACM conference style, like these guidelines, or about 5000 words. The submission should be in the final conference format, except the submission should have page numbers so the reviewers can more easily refer to parts. Videotapes should be at most 8 minutes long. The submission should consist of 6 copies of a paper, 6 copies of a videotape (if there is one), and a cover letter indicating the primary author's name, affiliation, address, phone number and email address (if at all possible). The title page should include an abstract (fewer than 200 words) and keywords. The cover letter should also indicate whether a revised version of the submitted video can be part of the proceedings.
If you want to format-by-example (a reasonable strategy), you can download a sample paper, properly formated. The source code for the paper is available in LaTeX and RTF. If you are using LaTeX, you'll also need to download the style file.
It is to the author's advantage to make the reviewer's job as easy as possible! A well-written paper, printed with a high-quality printer, with useful illustrations will appeal to reviewers. Given that many of the papers presented at UIST are about systems, it is surprising how many papers are presented for review without pictures or a videotape to support the ideas presented. It is not necessary to have the ultimate picture or the final, polished version of the videotape for review. However, the reviewers are much more likely to prefer papers containing some indication that the author's claims are supported than those that leave the final results to the reviewer's imagination.
An author of each accepted paper is expected to give a presentation lasting approximately twenty minutes at the conference. Authors should include a note with their submission if they are planning anything for the presentation that is not obvious from the paper; for example, an author may point out that there will be a videotape or live demonstration at the conference showing the results described in the paper. Authors of accepted papers will be sent detailed instructions for preparing their conference presentation.
The authors and their employers, other than employees of the U.S. government, must be prepared to sign a copyright transfer form before the paper is published. "It is a policy of ACM to own the copyrights on its technical publications to protect the interests of ACM, its authors, their employers, and at the same time to facilitate the appropriate reuse of this material by others." (Extracted from ACM Copyright Procedures.)
A good UIST paper will make both a respectable paper for the proceedings and a good conference talk. As an author, you should ask yourself the following questions before submitting your paper. Papers without good answers to these questions are unlikely to be accepted.
Papers that present new algorithms, techniques, or hardware are the easiest to write and review. If the content is truly new, effective, and makes a useful 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, but do not fake or redraw screen shots. It 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. To repeat, reviewers tend to be very skeptical of design-only papers unless there are new ideas of obviously high quality.
It is very important that you clearly identify what is implemented and what is merely designed. Do so at the beginning of the paper, not the end!
The paper should emphasize the novel aspects of the system, what underlying themes are present, what problems were anticipated/encountered in building the system, and how the structure presented provides solutions to these problems. In general, avoid details that are only of interest to users of the system and concentrate on those that would be interesting to someone else building a similar system. Avoid sweeping claims, especially for paper designs!
Roy Levin and David Redell's article How (and How Not) to Write a Good Systems Paper, although oriented towards operating systems, is highly recommended for further guidelines on writing systems papers.
An application paper presents an application area and a problem in that area that benefited from innovative user interface techniques. The techniques used don't have to be unique, but their use must not be completely obvious. The author should concentrate on what was learned, and how well the user interface works compared to previous techniques for solving the same problem. As in a systems paper, the intended audience should be other user-interface developers, not the end user. Successful applications papers provide some general insight into the use of interactive techniques to solve problems.
As previously stated, a UIST paper is accepted or rejected based on the ratings it receives from the reviewers. Paper reviewing is a volunteer activity; the only benefit that the reviewers get is the knowledge that they have contributed to the field. In many ways, the success of the technical program is more a function of the quality of the reviewers than the work of the program chair or the program committee. We are lucky to have excellent reviewers for this conference and paper authors should be considerate of them.
Many of the senior people in this field receive a large number of papers to review each year. With this in mind, authors should think about their reviewers when they are preparing their papers. In the following paragraphs we provide some advice on how to prepare your paper so it makes the best impression on a reviewer.
The most important point is to put a reasonable amount of effort into the production of your paper. When the author appears to have put little effort or thought into the production of a paper, the reviewer is not motivated to read the paper carefully and produce a good review. There is no excuse for spelling mistakes in papers, since spelling checkers are now widely available. A large number of misspelled words in a paper just indicates to the reviewer that the author didn't care enough about his or her paper to run the spelling checker on it. With this attitude on the part of the author, why should the reviewer bother doing a good job? The same goes for missing references, mislabeled figures, and other trivial problems that could be caught by thorough proofreading. Don't expect reviewers to read your paper carefully if you are not willing to read it carefully first!
UIST reviewers will have several papers to read in a short period of time. Therefore, you should write your paper so that it is easy to read. Try to write your paper so it flows smoothly. A paper that is easy to read will usually get a higher rating.
Has this paper been submitted to a conference before and been rejected? If this is the case, think carefully before you submit it again! There must have been some reason why the paper was rejected. (I know, we all blame bad reviewing, but there must also have been some other reason.) Read the reviewers' comments and try to determine what they would like to see changed, and then make those changes. There is a surprisingly good chance that a resubmitted paper will be reviewed again by a reviewer who gave it a poor rating before (or who recalled the deliberations over your previous submission in a program committee meeting of another conference). If the paper has not been changed to reflect that reviewer's comments, it is likely that your paper will get an even lower rating. Yes, sometimes the reviewer's comments are wrong (reviewers are only human after all), but this usually implies that you need to write more clearly or provide more evidence for your claims. I have received what I originally considered to be bad reviews on papers, but after calm consideration (weeks, or even months, later) realized that these reviews pointed to real faults in the paper. If the reviewer was confused about what I was saying, then the average reader will also be confused!
A highly recommended technique is to write the paper, and let it sit on your desk for a week or two. Then go back and read the paper as if you were a reviewer who doesn't know the author. While you are writing a paper, you are too closely tied to the work to be able to criticize it effectively. After a break of a week or two, you will be much more objective and may see organizational problems that weren't evident when you were actively working on the paper.
The single most important thing you can do to improve the odds of having your paper accepted is to have your own colleagues do an "in house" review of it before you send it to us 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.