UIST Skills
A 12-skill depth pack for UIST submissions: interface-systems venue routing, PCS submission audits, video-figure evidence, the 5,000-character rebuttal, TAPS camera-ready with accessibility requirements, artifact and demo packaging, technical-plus-user evaluation design, and full-cycle workflow. Grounded in official UIST 2026 pages checked on 2026-07-08.
Skills in this plugin
11- ▌ Uist Submission · brycewang-stanfordUse when performing the final pre-upload audit of a UIST paper in PCS — the abstract-then-paper deadline pair, 10-page/5-page two-column limits with desk-reject enforcement, anonymous acmart options, video-figure and supplementary uploads, the prior-work overlap rule, and deadline-week sequencing.
- ▌ Uist Experiments · brycewang-stanfordUse when designing or auditing the evaluation of a UIST paper — choosing among technical benchmarks, controlled comparisons, usability walkthroughs, expert sessions, and demonstration applications, matching evaluation shape to the systems claim, and avoiding the ritual study that proves nothing the paper asserts.
- ▌ Uist Camera Ready · brycewang-stanfordUse when converting a conditional UIST acceptance into a published paper — delivering the rebuttal-promised changes by the July deadline, working the ACM TAPS pipeline with alt text for every figure and table, de-anonymizing correctly, finalizing the video figure, and preparing the Detroit talk and demo.
- ▌ Uist Related Work · brycewang-stanfordUse when positioning a UIST submission against prior art — organizing by capability delta rather than paper lists, covering the technique lineage, toolkit ancestry, and commercial systems reviewers know, citing your own work in the third person, and verifying venue attribution through the ACM DL and dblp.
- ▌ Uist Supplementary · brycewang-stanfordUse when producing the video figure and supplementary materials for a UIST submission — treating the 3-minute video as near-mandatory evidence in a demo-culture venue, scripting it around claims, meeting the 1080p/4K H.264 spec, anonymizing frames and audio, and deciding what else ships alongside the PDF.
- ▌ Uist Writing Style · brycewang-stanfordUse when drafting or revising a UIST paper — structuring the systems-paper arc (walkthrough before mechanism), writing an implementation section with real technical depth, pairing every capability claim with a figure or measurement, and fitting the argument inside the 10-page or 5-page two-column limit.
- ▌ Uist Review Process · brycewang-stanfordUse when interpreting the UIST review pipeline — anonymous PC-plus-external review of papers and videos, the rebuttal's role, PC-meeting decisions, conditional acceptance mechanics, reading systems-reviewer psychology, and choosing the demo/poster fallback or resubmission path after a rejection.
- ▌ Uist Author Response · brycewang-stanfordUse when writing the UIST rebuttal — budgeting the 5,000-character self-contained response, prioritizing factual corrections and novelty defenses over taste disputes, promising only camera-ready changes you can deliver, and writing for the PC discussion that follows rather than for the reviewers alone.
- ▌ Uist Reproducibility · brycewang-stanfordUse when making a UIST paper's results replicable — reporting implementation parameters and measurement protocols so a lab could rebuild the system, specifying hardware down to parts and calibration, logging technical evaluations deterministically, and writing honest availability statements for interface systems.
- ▌ Uist Topic Selection · brycewang-stanfordUse 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 Artifact Evaluation · brycewang-stanfordUse when packaging the artifacts behind a UIST paper — code, toolkits, hardware design files, and datasets — first as anonymous review-time evidence that the system is real, then as a public release engineered for reuse, in a venue with no formal badge committee doing the checking for you.