At UIST, related work is a novelty proof, not a literature survey. The section exists to establish that no prior system delivers your capability, and its jury includes people who built the prior systems. Precision about what neighbors can and cannot do is therefore worth more than coverage breadth — and misdescribing a reviewer's own system is the fastest way to earn a hostile expert review.
Structure subsections around the dimensions on which your artifact differs, and end each with an explicit delta sentence:
WEAK: "Several systems have explored on-skin input [4,9,12]. Others used
acoustic sensing [7,15]. We also use acoustic sensing."
STRONG: "Prior on-skin input systems localize touches on the forearm [4,9] or
hand [12], but all require instrumentation of the touching finger.
Acoustic approaches remove finger instrumentation [7,15] yet resolve
only 4-6 discrete locations. Our contribution is continuous 2D
localization with no finger instrumentation."
A comparison table (rows: closest systems; columns: the 3-5 capability dimensions) is often the strongest half-page in the paper — but every cell about someone else's system must be defensible from their paper's text.
| Lineage | What reviewers check | Where authors slip |
|---|---|---|
| Technique lineage | The chain of prior techniques for the same user intent, across decades | Citing only the last 5 years; UIST's canon runs to the early 1990s |
| Toolkit/platform ancestry | Which abstractions you inherit vs invent | Claiming novelty for what a mature toolkit already provides |
| Commercial and open-source practice | Shipping products that already do a version of it | Ignoring the product every reviewer owns |
Commercial systems lack papers but not existence: cite documentation or teardowns and state the capability difference plainly. "No academic paper describes X" is not a novelty claim when X ships on a phone.
../../resources/exemplars/library.md
is verified against DL/dblp records; follow the same recipe for anything you add.The capability-comparison table is high-value and high-risk. A defensible build procedure:
Table skeleton (rows = closest systems, cols = capability dimensions):
| finger-free | continuous 2D | on unmodified skin | latency reported
SystemA '19 | no | 4 sites | yes | not reported
SystemB '22 | yes | 1D slider | no (sleeve) | 23 ms
Ours | yes | yes ±2.1 mm | yes | 11 ms median
UIST's 2026 rules (verified 2026-07-08) are specific and unusual in one respect:
Reviews for UIST 2026 papers are in (notification June 27, 2026). If you are
repositioning after rejection, mine the reviews for missed prior art before choosing
the next venue: an expert pointing at a system you did not cite is the cheapest
related-work audit you will ever get. For camera-ready papers, the +10% page
allowance is often best spent making the comparison table honest about points the
rebuttal conceded (see uist-camera-ready).
[Novelty frame] <the capability delta in one sentence>
[Nearest neighbors] <3-5 systems + the dimension separating each>
[Lineage gaps] technique / toolkit / commercial — which is thin
[Attribution check] verified via DL-dblp / pending
[Self-citation risk] third-person compliant / overlap attachment needed / clean