UIST Author Guide for System Papers
原文: http://www.acm.org/uist/uist2012/AuthorGuide.html
相比算法/技术/交互/硬件项目, HCI System项目难做, 论文难写, 会议难过看来已经是公认, 近年来讨论不断, 去年CHI上甚至有一篇来自MIT/CMU/Stanford社交计算系统的学者合著的10页长论文专门批讲吐槽人机交互界中system paper的困难，和所诉求的审稿机制的改变.
UIST是ACM在人机交互方向上的顶级会议之一, 在UIST2012的官方作者指南上专门对system paper的写法做了官方指导和说明, 对跟我一样种种苦逼的system researcher总算是点干货.
p.s. 曾看到有人写到中国学者已经20年没有上过UIST, 无怪乎整个国家山寨横行创新力落到如此地步. 这不是块创新的土地, 深入骨髓.
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.
System
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.
