| name | uist-topic-selection |
| description | Use when deciding whether a project belongs at UIST — testing it against the interface-systems contribution bar (novel technique, toolkit, or hardware that works), making the CHI-vs-UIST routing call explicitly, and re-routing to CSCW, IMWUT, TEI, ISMAR, IUI, or TOCHI when the artifact is not the contribution. |
UIST Topic Selection
UIST publishes papers whose contribution is an interface artifact: a new
interaction technique, an enabling piece of hardware, a toolkit or authoring system,
or an algorithm that makes a previously impossible interaction possible. The venue
grew out of demo culture and still reviews like it — the implicit first question is
"what did you build, and can I imagine holding it?" Use this skill before any UIST
plan is made; the March deadline punishes late routing discoveries.
The artifact-subtraction test
Delete the system from the paper and see what survives:
- If what survives is a finding about people (how users behave, adopt, trust,
collaborate), the system was an instrument, not a contribution — that is a CHI or
CSCW paper.
- If what survives is nothing, because every claim is about what the artifact
enables and how it is engineered, you are holding a UIST candidate.
- If what survives is a model or algorithm evaluated offline with no interactive
loop, consider IUI, an ML venue, or a domain venue instead.
CHI vs UIST: make the call, don't drift into it
Both are SIGCHI venues, both use PCS, and many projects could be dressed for either.
Decide on contribution shape, not on which deadline is closer:
| Question | Points to UIST | Points to CHI |
|---|
| What is novel? | The technique, device, toolkit, or enabling pipeline | The empirical insight, theory, or design knowledge |
| What is the evidence spine? | It runs: technical evaluation, demo, video figure | Study rigor: participants, methods, analysis |
| Who must be convinced? | Systems builders who will reuse or extend the artifact | A mixed jury weighing study quality and framing |
| Weakest section right now? | A thin user study is survivable if the engineering is deep | A thin study is usually fatal |
| Natural conference moment? | A demo people queue for | A talk people argue about |
An honest tie-breaker: if your video figure would be boring — nothing moves, nothing
is manipulated, nothing responds — UIST reviewers will feel the same way about the
system.
Fit ledger
Score each row 0-2 and be suspicious of any total under 8:
[ ] Enabling novelty: the artifact does something no published system does (not "does it better on a benchmark")
[ ] Technical depth: there is a mechanism, algorithm, or fabrication method worth two pages of implementation
[ ] Demonstrability: the contribution is visible in under three minutes of video
[ ] Evaluation match: the planned evidence measures what the artifact claims (see uist-experiments)
[ ] Community reuse: a builder could take the technique/toolkit and make something you didn't anticipate
[ ] Timing: buildable and evaluable before the late-March abstract/paper deadlines
Where UIST-adjacent work actually belongs
- Deployment and appropriation studies of an interactive system → CSCW or CHI;
UIST wants the system's construction, not its month-three usage patterns.
- Sensing without an interactive application (activity recognition, physiological
pipelines) → IMWUT/UbiComp.
- Tangibles and fabrication where the argument is design-theoretic → TEI or DIS;
keep fabrication at UIST when the contribution is the enabling process or machine.
- AR/VR perception or display optics without an interface contribution → ISMAR or
IEEE VR.
- Intelligent interfaces where the model is the contribution and the interface is
a wrapper → IUI, or an ML venue with a demo track.
- Mature systems with longitudinal evaluation that outgrew a 10-page conference
paper → TOCHI.
The Lasting Impact lineage is a useful calibration set: mobile sensing hardware
(Hinckley et al., UIST 2000), multi-user touch hardware (DiamondTouch, UIST 2001),
gesture text entry (SHARK2, UIST 2004) — every one is an artifact a reader can
picture operating. Benchmark your idea against that lineage in
../../resources/exemplars/library.md.
Three routing vignettes
Concrete cases, because the boundary is learned by example:
- "We built a VR classroom and studied 40 students learning in it." Subtract
the artifact: a finding about learning in VR survives. Unless the classroom
required new rendering, tracking, or authoring machinery worth two implementation
pages, this is CHI (Learning subcommunity) or a learning-technology venue. The
UIST version of this project would contribute the authoring system that let a
teacher build such classrooms without programmers.
- "We invented a way to print stretchable circuits on fabric with a consumer
printer, and made four demo garments." Nothing survives subtraction — the
process is the paper. The four garments are the evaluation breadth, and the
technical characterization (resistance under strain, wash cycles) is the
evidence. Textbook UIST; TEI only if the argument shifts to design theory.
- "Our LLM agent completes GUI tasks from natural-language instructions; we
benchmarked it on 500 tasks." The judgment call of the current era. If the
contribution is benchmark accuracy, it drifts toward an ML/agents venue. It
becomes UIST-shaped when the paper contributes the interactive machinery:
mixed-initiative repair when the agent stalls, user-visible plans, an
architecture others can build interfaces on — and evaluates those interactions,
not just task completion.
Timing the decision
Routing is cheapest at conception and expensive after a rejection. Three checkpoints:
- At project pitch: run the subtraction test on the planned paper, not the
planned system — labs routinely build UIST systems and then write CHI papers
about them by accident.
- At feature freeze (see
uist-workflow): re-run the fit ledger; if technical
depth scored 0-1, the short-paper category or an adjunct track is the honest
landing zone.
- After reviews: rejections phrased as "the evaluation doesn't support the
claims" are often routing errors in disguise — reviewers asked for the evidence
the other venue's version of the paper would have carried.
Scope notes for the 2026 cycle
- The 2026 CFP was verified via search renderings on 2026-07-08 (direct fetches were
blocked); the Papers deadline (March 31, 2026) has passed, so a routing decision
made today targets the adjunct tracks of UIST 2026 — Demos and Posters welcome work
already shown elsewhere — or the UIST 2027 Papers cycle.
- Short papers (5 pages) exist for smaller-but-complete contributions; routing a
half-built system to a short paper is legitimate, padding it to 10 pages is not.
- Scope vocabulary drifts with the field (2026 chairs span video accessibility,
human-AI systems, fabrication, and programming tools — a hint about breadth);
reread the current topics list rather than assuming last decade's hardware focus.
Output format
[UIST fit] strong / plausible / re-route
[Artifact-subtraction result] <what survives without the system>
[CHI-vs-UIST call] UIST / CHI / genuinely either — with the deciding row
[Fit ledger] <score>/12 with weakest two rows
[Re-route candidate] <venue + why its reviewers are the right jury>
[Next skill] uist-experiments (evidence plan) or uist-workflow (calendar)
