UbiComp / ISWC 2023
ISWC Author’s Guide

For format, deadlines, and other relevant information for submissions to ISWC 2023, authors should refer to the official Call for Participation. Authors submitting material to ISWC 2023 should use this guide to understand how the review process works, and hence how to write more successful submissions.


This document is a modified (with permission) version of the UIST 2011 author guide. It was updated in October 2011 by Daniel Ashbrook for the ISWC 2012 author guide and slightly updated by the Notes and Briefs chairs of ISWC 2023.


ISWC features notes, briefs, and demos, as described in the Call for Participation. Accepted notes and briefs will be presented during technical sessions at the conference and published in the conference proceedings.

*Since ISWC and UbiComp have started co-hosting the conference, ISWC papers formerly known as “Long papers” must be submitted via the IMWUT journal system. IMWUT has 4 submission deadlines a year (15 February, 15 May, 15 August, 15 November). When submitting to IMWUT, please make sure you tick the “Wearable” checkbox as it helps allocate the papers to suitable Associate Editors.


Paper submissions must not have been published previously. A paper is considered to have been previously published if it has appeared in a peer-reviewed journal or meeting proceedings that is reliably and permanently available afterward in print or electronic form to non-attendees, irrespective of the language of that publication. This includes papers that are reviewed only as abstracts, but are published as a complete paper. Works presented only as conference abstracts or talks but not involving a publication are considered as novel manuscripts.

Regular papers submission covers both full papers as well as notes. Both types of submissions are peer reviewed to the same scientific standards. The difference between the two types is that notes are more concise with possibly a smaller yet significant contribution.

Additionally, ISWC will publish outstanding two-page papers (or briefs) that accompany poster submissions. Notes (not longer than four pages in length) and briefs (not longer than two pages in length) are intended for succinct work that is nonetheless in a mature state ready for inclusion in archival proceedings.

Non peer-reviewed documents such as theses and tech reports are not considered prior 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. ISWC authors are welcome to post information and videos about their work online while submissions are under review; sharing research online does not constitute prior publication or otherwise affect the ISWC review process. Note that this includes a submission to online archive sites such as arXiv.org.


A paper identical or substantially similar (or even a subset or superset) in content to one submitted to ISWC should not be simultaneously under consideration at another conference or journal during the entire duration of the ISWC 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 ISWC and another venue is just a few days or a few hours, and even if it is your intention to withdraw the submission from the other venues as soon as it is accepted by one of them. This restriction also applies even if the other venue allows simultaneous submission. We will make every effort to identify simultaneous submissions, and ISWC 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 ISWC and the other venues on grounds of duplication alone.


Paper submissions are anonymous.

What does anonymous mean for ISWC submissions? Primarily, it means that submissions must remove all author and institutional information from the title and header area of the first page of the paper.

Furthermore, all references must remain intact. If you previously published a paper and your current submission builds on that work, the reference-with authors-should appear in the references. Submissions should not have blank references (e.g., “12. REMOVED FOR REVIEWING”).

We encourage authors to refer to their previous work in the third person. Further suppression of identity in the body of the paper, while encouraged, is left to the author’s discretion.

Why did ISWC adopt this particular strategy of lightweight anonymization? ISWC 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. 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. This is why anonymization within the body of the paper is encouraged, but at the authors’ discretion.


The Papers Committee and a set of external reviewers, both consisting of recognized experts, will review submitted papers. Then, at their meeting, the committee will select those papers to be presented at ISWC.

The Committee will use the following process:

  1. In the week following the submission deadline, the Papers Chairs will assign each submitted paper to a primary reviewer who is a member of the paper committee. Papers that are inappropriate may be rejected during this assignment process, without being sent to a primary reviewer. Papers will normally be rejected at this stage only if they are clearly off-topic for ISWC, or if they are discovered to have been published previously or to have been submitted simultaneously to another conference or journal.
  2. The primary reviewers may, upon conferring with the Technical Papers Chairs, recommend a paper to be rejected without additional review. A paper will normally be rejected at this stage only if it falls into one of the categories listed in phase one, but this fact was not detected during the initial paper assignment. It is possible, although unlikely, that a paper may also be rejected at this stage if it solves a problem that is known to be already solved; 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; or if it is solving a problem sufficiently minor that the senior reviewers do not believe that it belongs in the program; or if it addresses a topic that is clearly outside the purview of ISWC.
  3. The primary reviewers distribute each paper to at least two additional experts, called secondary reviewers. The primary and secondary reviewers all write full reviews. Thus, at least three reviews are written for each paper that has not been rejected during phases one and two. The primary reviewer knows the identities of the authors of the papers, but the secondary reviewers do not.
  4. After the primary and secondary reviewers complete their reviews, any paper for which all three reviews fall below a rejection threshold will be rejected. These rejected papers will not be discussed at the PC meeting.
  5. The full papers committee meets, to determine 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 and write short reviews, and their evaluations will be taken into account in the decision.
  6. After all reviews are complete, reviews will be distributed to authors.

Email notifications of the Technical Papers Committee’s decisions will place each paper in one of the following categories:

    1. Desk Rejected: Papers out of the scope of ISWC or without appropriate anonymization may be rejected without reviews.

    2. Rejected: Some rejected papers may be invited for submission as posters or demonstrations at the Conference.

    3. Accepted paper: final edits (in alignment with reviewer comments) will be prepared by the authors for submission on the Camera Ready Deadline.

    4. Shepherded paper: those are papers which require very specific changes identified by reviewers and the program committee members. They are considered to be conditionally accepted, subject to the authors modifying their paper to address specific shepherding comments. These may fall in two categories. Some papers may be requested to be revised in a shorter format (e.g. from Notes to Briefs), while others may be requested to be revised in the same format. A shepherd will guide the authors to ensure that the required changes are adequately completed. Revision timelines will be agreed between the shepherd and authors, but must be fully complete and approved by the shepherd by the Shepherding Acceptance Deadline and then readied for the Camera Ready Deadline.


A good ISWC 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 senior reviewer for the paper is based almost entirely 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? 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, 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 ISWC. On the other hand, beware of trying to write a paper with too large a scope.


One of the ways ISWC papers are evaluated is 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 hardware, software, study design, and prior work your research is based on for someone knowledgeable in the field to have a good chance of reproducing your 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 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.


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 wearable computing, as well as access to the major journals in computer science, electrical engineering, and so forth. A short conference paper can only present a few concise ideas well.


While ISWC 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 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.


The ISWC proceedings are typically printed in black and white, and often reviewers and readers who later download the PDF will print on a non-color printer. Ensure that your graphs and figures are still legible in black and white, and printed at a normal size.


Activity recognition papers have a long history at ISWC, and as such, deserve a section all their own. In order to be novel enough for publication, a paper about activity recognition must significantly raise the bar over prior research. If your paper involves affixing sensors to a person, training a recognizer, and testing said recognizer, consider carefully whether your paper is different than previously-published work. Simply applying known techniques to a new domain is not enough, unless the new domain presents challenges that significantly change how the problem is approached or the techniques are applied.


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 ISWC. 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. Authors of contributions focusing on the deployment of a system or application design should also consider if their work might fit best in the ISWC Design Exhibition. Design Exhibition submissions focus more on the instance case of a designed garment or wearable device, rather than the generalizable knowledge created by assessing or implementing the application.


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 ISWC 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 screenshots is vital to convincing readers and reviewers that the system is real. Do not fake or redraw screenshots; 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.


An application paper presents an application area and a problem in that area that benefited from innovative wearable computing 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 wearable computing developers, not the end user. Successful applications papers provide some general insight into the use of wearable computing to solve problems.


As previously stated, an ISWC 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 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.

ISWC 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.

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 reviews, 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 ISWC 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.


Each paper must be submitted as a single PDF file in ACM double-column format. Maximum page limit for notes are four pages, and two pages for briefs, and two pages for papers accompanying demos. Please refer to the UbiComp/ISWC 2023 template and formatting for either Latex or Word templates and formatting instructions.

Submissions for review must be in the Submission Template format. Written submissions must be in PDF format, and video submissions (see below) must be in one of the approved file formats.

Remember that paper submissions including all supporting materials are anonymous.

It is to the author’s advantage to make the reviewer’s job as easy as possible. A well-written paper containing useful illustrations will appeal to reviewers. Given that many of the papers presented at ISWC are about systems, it is not surprising that most accepted papers include pictures or a video to support the ideas presented. It is not necessary to have the ultimate picture or the final, polished version of the video 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.

Accepted papers must follow the Publication Template format for the Camera Ready version with all author information, affiliation, acknowledgement, etc. de-anonymized. For submissions written with Latex, the source files are also required.


An author of each accepted paper is expected to give a conference presentation (exact length requirements will be provided soon after notification of acceptance). Authors should include a note with their submission if they are planning anything for the presentation that is not obvious from the document; for example, an author may point out that there will be a video or live demonstration at the conference showing the results described in a paper. Authors of accepted submissions will be sent detailed instructions for preparing their conference presentation.


Many submissions to ISWC can benefit from further illustration than is possible in a static paper. Therefore, authors are encouraged to include video material with their papers. The optional digital video that you include with your submission will be used only for confidential internal distribution to the reviewers.

Video supporting paper submissions should be anonymous. Authors should make video material 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 supporting video accompanying a submission for review is used only to help reviewers evaluate the submission; accepted paper authors will have the chance to submit a higher-quality video for the electronic conference proceedings. Acceptable videos can be made without expensive production or special effects. A camcorder, tripod, and some planning can help guide the viewer’s 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 input devices if that is relevant. The UIST website has a nice guide describing how to make good videos.

Although a video may help the reviewers understand your paper, your paper must stand alone without the video: although it would be nice if they did, not every reviewer will watch your video. On the other hand, the video needs 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.

Rest assured that we will not duplicate for public distribution any video included with your initial submission. Those files will only be used during the review process, and then all copies received by ISWC will be destroyed or deleted.


The authors must be prepared to sign an ACM copyright transfer form before the submission is published.

UbiComp / ISWC

Past Conferences

The ACM international joint conference on Pervasive and Ubiquitous Computing (UbiComp) is the result of a merger of the two most renowned conferences in the field: Pervasive and UbiComp. While it retains the name of the latter in recognition of the visionary work of Mark Weiser, its long name reflects the dual history of the new event.

The ACM International Symposium on Wearable Computing (ISWC) discusses novel results in all aspects of wearable computing, and has been colocated with UbiComp and Pervasive since 2013.

A complete list of UbiComp, Pervasive, and ISWC past conferences is provided below.

View all