Episode 6388 custom

Why Swipe Decks Make Better Training Data

A Tinder-style swipe deck removes comparison to force isolated choices, turning rapid binary labels into active learning training signals.

Oct 31 18:40 Transcript

With

0:00

Episode Details

Episode ID: MWP-6590
Published: Oct 31
Duration: 18:40
Audio: Direct link
Pipeline: V5.26
TTS Engine: chatterbox-regular
Script Writing Agent: Claude Sonnet 5.5
Topics: open-source training-data ai-evaluation ai-bias

AI-Generated Content: This podcast is created using AI personas. Please verify any important information independently.

The prompt

The prompt that started this episode, as sent in (production notes for the hosts removed).

My favourite kind of user interface is what I usually call "the Tinder interface": one item on screen at a time, and you act on it with a swipe left, right, up or down, or a few big buttons. Behind it there's some memory, so what you're shown gets smarter over time.
I keep wanting this for very different things. One is a movie recommendation app: show me one film at a time, I tap like, dislike, skip or "don't show again", and that feeds a profile that improves the suggestions. Another is human feedback and post-training data: the AI generates two options and I pick the better one. Right now I'm training a spam classifier, and the strength of this pattern is its simplicity — "spam" is just a button with an angry face. What these share is that they use phone gestures really well and add a little gamification, so a boring job like dataset annotation becomes something you can actually get through.
So my question: does this pattern have a better, more accurate name than "Tinder-like"? And what are the primitives — the frameworks, libraries or basic building blocks — for building one? Next time I say "I wish we had a Tinder-like frontend for this", what should I be saying instead?

Often casually called the Tinder interface, the swipe deck pattern isolates single cards for rapid, binary decisions without list comparisons. Despite missing from standard design systems, it powers workflows ranging from spam classification to photo triage. Building one entails a straightforward gesture layer—requiring essential accessibility buttons and undo mechanisms—paired with a sophisticated active learning backend. Systems like Label Studio leverage these loops by presenting uncertain, borderline data rather than obvious examples, retraining models as cards are resolved. Furthermore, incorporating four-directional options or abstention choices like skip prevents forced-choice noise, helping models accurately separate genuine subjective differences from inherently ambiguous data.

Sources

What the research for this episode read before the script was written. Primary sources first.

Context

Prior episodes already covered building AI preference datasets (#6129), choosing human labelling tools for LLM benchmarks (#6130), DPO training on your own taste (#6242) and audio annotation tool selection (#6300). Don't retread those; this episode is about the interaction pattern itself: its name(s) and the building blocks to build it.

Mentions

anyswipe-swipedeck Headless swipe deck library with undo and batch loading
Conjointly Survey tool with single swipe card question type
Embla Carousel Web carousel library underlying shadcn Carousel
Intuify Survey tool with directional swipe question modes
label studio Open source data labeling tool
react-native-deck-swiper Popular React Native swipe card library
react-native-tinder-swipe-cards Stale React Native Tinder-style card library
shadcn UI component collection with Carousel built on Embla
SwipeGANSpace Research using swipe-to-compare as preference signal
vocab.design Design vocabulary site defining swipe deck pattern

Downloads

Episode Audio

Download the full episode as an MP3 file

Download MP3

Transcript (TXT)

Plain text transcript file

Episode Book (PDF)

The episode's record — date, duration, models, sources — with the full transcript

#6388: Why Swipe Decks Make Better Training Data

Daniel keeps saying "the Tinder interface" and he wants a better word. The picture is one item on screen, a swipe or a few big buttons, and some memory behind it so the next item is smarter. He wants it for movie picks, for choosing the better of two AI outputs, and right now for a spam classifier where "spam" is a button with an angry face. Same gesture, three different jobs. So what's it called, what do you build it from, and what does he say instead of "I wish we had a Tinder-like frontend for this"?

Herman Poppleberry, and the name is swipe deck. Also card stack, tinder swipe, swipe cards, yes no deck. A design vocabulary site called vocab.design has an entry for it, and it defines it as a stack of cards judged one at a time, each thrown left or right to record a binary decision and reveal the next card underneath.

Fine. Why does nobody say that?

Because the entry says outright: "No design system documents this." There's no swipe deck in Material, none in Apple's Human Interface Guidelines, none in the ARIA patterns. The name comes from the product that popularised it.

So Daniel isn't being sloppy. He's being accurate about a hole in the documentation.

Yes. There's no spec to cite, so everybody points at the dating app.

It's like calling every adhesive bandage a Band-Aid.

Or every vacuum a Hoover, in Britain. When a pattern has no standard name, the first product that nails it becomes the noun. The trouble is that the noun carries baggage. Say "Tinder interface" in a meeting and half the room hears dating, not decision-making.

And the other half hears a budget request for a dating app.

Which is a worse meeting. A shared name also matters when you write a ticket. "Build a Tinder thing" leaves open whether you want undo, keyboard support, or four directions. "Swipe deck" at least points at a defined pattern with known obligations.

What's the mechanic, precisely?

Only the top card is actionable. The choice is binary and physical. And the line I like: the reward for deciding is the next card arriving.

That's a slot machine with a to-do list.

Close to a variable-ratio schedule with a progress bar, yes. We'll come back to that. First, the boundaries, because the term is only useful if it excludes things. Swipe actions are the drag that reveals buttons behind a list row. It snaps back and the item stays in the list. Swipe to dismiss is throwing a card or notification away to clear it. Stories are timed full-screen cards you tap through.

And in a deck, the card leaves and takes the decision with it.

That's the distinction. The decision is the point.

Take the mail app, where you swipe a row to reveal "archive" or "delete."

That's a swipe action. The row is still a row in a list, you're operating on a collection. In a deck there is no list in view. You only ever face one item, and that's what forces a judgment.

So you can't glance at the next three and decide which to do first.

Right. A list lets you triage by comparison. A deck removes comparison on purpose, so every card is judged on its own merits, and in a labelling job that's often exactly what you want.

So the word is swipe deck. A name doesn't build anything, though. What are the pieces?

Two halves. A gesture layer and a memory layer, and they're very different in difficulty. The gesture layer first, and the library landscape tells you how easy it is. The incumbent on React Native is react-native-deck-swiper. About twelve and a half thousand weekly npm downloads, version 2.0.19, last updated August of last year.

Popular.

Used, anyway. It has a hundred and eighty GitHub stars and sixty-three open issues. Heavily used, thinly loved.

Sixty-three open issues is a lot of people quietly waiting.

And the historically famous one, react-native-tinder-swipe-cards, has over eleven hundred stars and hasn't been pushed since September of twenty twenty. Six years stale. Much of this space is tutorial-grade code, single-digit stars, a one-week lifespan.

Which suggests the gesture part isn't hard enough for anyone to bother maintaining.

My reading too. It's a weekend of Reanimated and Gesture Handler. Drag, rotate with distance, commit past a threshold, spring back otherwise. One SwiftUI write-up puts the commit point around thirty-five percent of screen width.

I'd have guessed half.

Half feels like a lot of dragging, apparently. Below the threshold the card springs home, so a hesitant thumb costs nothing. Past it, the card is gone and the decision is recorded.

For me every drag is a lot of dragging. Touchscreens aren't built for claws.

Noted. There's a newer entrant worth mentioning, anyswipe-swipedeck, created this April, about a hundred and eighty weekly downloads. Its README names the gap: most swipe libraries only support left and right, are tightly coupled to their own card UI, or make you manage swipe state yourself.

So it's the headless version.

Right. Bring your own card component, and it handles gesture detection, sixty frames per second animation, undo history and batch loading. Callbacks for left, right, up and down, an animated undo, an append call so you can feed it more data, and a remaining-count callback for infinite scroll.

What does the remaining-count callback do in practice?

When the stack drops to, say, five cards, it tells your code to fetch more. That's where the memory layer plugs in. The next batch doesn't have to be random. It can be whatever the model wants answered next.

So the deck never visibly runs dry, and the model is quietly choosing what refills it.

Yes, and the user never sees the seam. The five-card buffer is also what hides your network latency.

Four directions. That's Daniel's like, dislike, skip, don't show again.

Nearly word for word. Its own example maps four directions to skip, like, plan to watch, watching. A movie app. And that's why four directions is the interesting case. Two directions is a vote. Four is a small taxonomy.

Is that on the web too?

On the web the substrate is a one-at-a-time carousel. Embla Carousel, which is what shadcn's Carousel is built on. If a deck is a carousel with decision semantics bolted on, that's your foundation. There's also a cross-platform one called knitui with a super-like on the drag up.

Daniel's phone-gesture point is about swiping. But a drag has a problem.

It's the first of two obligations vocab.design says you can't skip. A drag can't be done with a keyboard, a switch or a voice command. So visible yes and no buttons, permanently, not as a hidden fallback nobody can find.

Which suits Daniel anyway. He said a few big buttons.

And on a desktop, those buttons can map to arrow keys, which makes a labelling session much faster than dragging a mouse.

And the second obligation?

Undo. A person moving at one decision per second will get one wrong, and without a way back the speed is paid for in accuracy.

One a second. I'd get the wrong one by second two.

You'd still be asleep at second two.

That's a different kind of wrong.

The gamification connects here. The same property that makes it fast, the next card as reward, makes it error-prone. It's structural. Take away the progress bar feeling and you take away the speed.

Daniel said it turns a boring job into something you can get through. So the trick is the cost of that.

Which is why undo isn't optional polish.

Though I'd say the deck is a good place to be wrong. One card is cheap.

Unless it's fed into a model as truth.

Fair. One bad label in a spam set teaches the model that a real invoice is junk.

And it teaches it that confidently, because the model can't tell a slip from a conviction.

So that's the easy half?

And that's where the library ecosystem's immaturity makes sense. The half Daniel cares about is the memory, and it's a different discipline entirely. It's active learning, online retraining, preference aggregation. Not a gesture library.

Same shape as when we looked at building your own speech recognition tool. The visible surface is the easy half and the model is the work.

Same thing. The reference implementation of the loop is Label Studio. Twenty-eight and a half thousand stars, Apache licence, pushed yesterday. Its ML backend does three things: pre-labels data with model predictions, retrains online while new annotations arrive, and does active learning by labelling only the most complex examples.

So for the spam classifier, the model guesses, and the deck shows him the cards it's least sure about.

He doesn't swipe through ten thousand obvious spam messages. He sees the borderline ones. That's the memory making the next card smarter.

Walk me through one round.

Model scores the unlabelled messages. The ones near fifty-fifty go to the front of the deck. Daniel swipes ten of them, the model retrains on those ten, and the next batch is chosen from the updated model. Each swipe moves the boundary a little.

So a newsletter that looks half like a promotion and half like a real receipt gets shown early, and the obvious pharmacy spam never reaches him.

The obvious ones teach the model almost nothing, because it already agrees with him. The ambiguous ones are where a single answer changes the most.

Is the swipe UI part of Label Studio?

Not really, and the maintenance signal is telling. The main repo is thriving, but label-studio-frontend, the embeddable piece, is archived. Four hundred and forty-seven stars, last push April of twenty twenty-four.

So the backend loop is loved and the frontend is abandoned.

That's where the maintenance burden lands. Which also means, I think, you'd build the deck yourself and talk to a backend like that.

Now Daniel's four buttons. Is that just nicer UX?

It's better data, and this is my favourite part. There's a paper from this month, Saravanan and colleagues, best paper at a workshop at ICML. It asks what disagreement in pairwise preference data means. Three possibilities: stable latent heterogeneity, meaning people differ; ephemeral stochasticity, meaning noise; or non-binary responses hidden by a forced-choice interface.

Hidden by the interface. As in, I'd say neither, but you only gave me two buttons.

Exactly that. With a pure binary channel, the aggregate preference is identifiable but the other two aren't. Abstention-enabled feedback identifies the non-binary part directly.

So skip and don't show again are the abstention channel.

They separate "people differ" from "this item is just ambiguous." Adding buttons is a measurement decision, not a UI preference.

Picture two AI outputs that are both fine. Forced to pick, I flip a coin, and the data records a preference that doesn't exist.

And ten annotators flipping coins looks exactly like ten annotators with strong, opposing tastes. Only the abstention button tells those apart.

I'd have guessed skip was just an escape hatch for the lazy.

It's also that. But a lazy skip is itself a signal about the item.

Provided people use it honestly.

Provided, yes. Though a skip button is cheaper than a wrong swipe, so people use it.

Does this really go beyond dating? I mean, beyond what Daniel listed.

Far beyond. Triaging photos, sorting expenses, marking flashcards, approving shifts, grading anything where a person can judge an item in a second and there are a hundred to get through. And survey tools already ship it as a question type. Conjointly has a single swipe card, with outputs like percentage of likes and median response time per card. Intuify has a directional swipe with two, three or four-way modes mapped to matrix columns.

Response time per card. That's the hesitation as data.

A slow swipe is a weak opinion.

Herman, do you swipe fast or slow?

Me? Slow, I read everything. You'd swipe by sunset.

Sunrise, if I'm well rested.

And the academic side agrees. A paper at IUI in twenty seventeen, "Don't Just Swipe Left, Tell Me Why," added reason bins to gestures. That's swipe plus a reason. And SwipeGANSpace uses swipe-to-compare as a preference signal over generated images.

Which is Daniel's pick-the-better-of-two case.

Same one. The gesture is a query, and the memory is what makes the query worth answering.

And now it is time for our regular segment, One-Star Getaways, with Clive.

This is One-Star Getaways, and I have just come back from Hanoi, where I stayed at the Golden Balcony Guesthouse, and I am giving it one star because the balcony was not a balcony.

It was a large photograph of a balcony, laminated, and taped to the window, and when I peeled a corner back to check the weather, the weather was a brick wall.

I recommend it warmly to anyone looking for a disappointing trip this winter, and I will be back next week with another one star.

I'd book it. The brick wall sounds restful.

I would not.

So, what does Daniel say instead of the Tinder line?

Swipe deck for the interface. When the memory is the point, preference elicitation or an active learning loop. The full sentence becomes: I want a swipe deck over the unlabelled set with an active learning loop behind it.

That's longer. But a collaborator knows what to build.

And knows the two halves are different jobs.

...and it was three hundred a day on the tally counter, which is what I settled at, one every twelve seconds or so. The counter was a Veeder-Root, brass, I still have the thumb callus. After about six hours I stopped trusting myself. Not that I got slower. I got faster. Every next one was a relief, Herman. It isn't a reward, you just want the last one gone. Relief makes you quick and it makes you sloppy. Undo is right, I'd have paid for undo. I also don't do that kind of work after two in the afternoon. Nothing I judge after two is worth writing down.

Twelve seconds is slower than the one-a-second the pattern aims for, and you still lost accuracy at six hours. That's a harder number than anything I had.

Three hundred an hour or a day?

A day was the quota. I did it in two hours some days. The sixth hour was the problem.

Then the interface should probably stop offering cards after a point.

The people on that job were good. That's all I'd say about it.

Right.

The relief point matters for the data, too. If fast swipes late in a session are relief swipes, you'd want to weight them down.

You could even detect it. Swipe speed climbing while agreement with the model's own confidence drops.

That would be a decent trigger for a "take a break" card. Not a nag, just the deck declining to deal.

And the break card is itself a data point. If everyone's accuracy collapses at the same card count, that's a property of the task, not of the people.

Which is a number you'd want before you set anyone's quota.

Common misconception time. People think the hard part is the swipe animation.

It's a weekend of Reanimated. The hard part is the loop behind it, deciding which card comes next and what each answer teaches the model.

If that's right, what's the stuff we all call by a brand name because nobody wrote it down?

Plenty, I'd guess. And the four buttons are the thing to take away: a measurement decision wearing a UI costume. Daniel's instinct was already right.

Thanks to Hilbert Flumingtop for producing, as ever. For more along these lines, there's episode eight, Building Your Own Whisper; and episode fifteen, AI Gets Personal. This has been My Weird Prompts. If you liked it, leave us a review wherever you listen.

See you tomorrow.

This episode was generated with AI assistance. Hosts Herman and Corn are AI personalities. It may contain errors: disclaimer · report an error