Munich, Germany
August 27 - 30, 2013
August 27 - 30, 2013
A good Mobile HCI 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. 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 the paper. Include a crisp description of the problem in the abstract and try to suggest it in the title. The choice of primary reviewer for the paper is based almost entirely on the answer to this question.
What is the relevant published work in your problem area? What deficiencies in their solutions are you trying to overcome? How does the new solution differ from previously published results? Don't 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.
Based on your problem statement, what did you accomplish? You are responsible for proving 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 or result, 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 MobileHCI. On the other hand, beware of trying to write a paper with too large a scope.
One of the ways MobileHCI papers are evaluated are through the question, "Does the paper contain enough detail to replicate the research?" Be sure your reviewers can answer this question in the affirmative! Provide sufficient detail about your research (e.g. study, software, user interface and hardware design) and prior work your research is based on for someone knowledgeable in the field to have a good chance of reproducing your study, design, system, application, or results.
Also, be sure to state your assumptions. If you describe something as "important", be certain that the reader will understand why you consider it so!
The question that generates the most discussion at the program committee meeting is whether a paper is complete. If the paper presents a study or analysis, an experienced practitioner in the field should be able to rerun it using the paper and should expect very similar results. If the paper presents a new interaction technique or device, 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 better 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.
Many large, poorly written papers contain a good paper trying to get out. It is the author's responsibility, not the reviewer's, to discover this paper and turn it into the submission. 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. If you tried several things that didn't work before arriving at a solution, only include the failed attempts if their solutions can shed light on similar problems that other researchers might face. You should assume your audience has a working knowledge of basic concepts relevant to mobile human-computer interaction, as well as access to the major journals in computer science, HCI, and so forth. A short conference paper can only present a few concise ideas well.
While MobileHCI papers are judged primarily as scientific 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 interested audience is likely to 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 appeal to a specialized audience, if they contain significant new ideas.
Often reviewers and readers who download the PDF of your paper will print it on a non-colour printer. Ensure that your graphs and figures are still legible in black and white, printed at a normal size.
As previously stated, a MobileHCI 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!
If your native language is not English, you can greatly increase your chances of an acceptance by getting a native English speaker to proofread your paper before submission! Every year, many papers are rejected because reviewers had a difficult time understanding the ideas in the paper due to difficult-to-read wording.
MobileHCI 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.
Use the active voice! While many publication venues in the hard sciences often encourage passive voice ("a system was developed"), papers using the active voice ("we developed a system") are much easier to read and understand. A good resource describing the differences between active and passive voice, and how to check and modify your writing, can be found at http://lavc.edu/writingcenter/handouts/activepassive.html.
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. (Yes, 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. 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 the 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.
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 submit it to the conference 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 MobileHCI 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.
