# Drag is a desktop idiom; the phone wants a tap

> A drag-and-drop board that feels great with a mouse is often dead on a phone: a press-and-move is read as a scroll, cards never lift, and a calendar that only handles drops has no way to even open an item by tapping. Build the field surface tap-first and keep drag for the desktop planning view.

URL: https://biloh.com.au/docs/engineering-notes/drag-is-a-desktop-idiom
Category: Engineering notes | Audience: builder | Updated: 2026-06-26

A dispatch board built around dragging cards between columns can be excellent on a desktop and completely dead on a phone. The same gestures that feel natural with a mouse don't exist under a thumb, and the failure is silent: nothing errors, the cards just don't move and items won't open.

If your users are in the field — and for field-service software they are — **the touch surface is the real surface.** Build it tap-first.

## Why the desktop board dies under a thumb

Three concrete failure modes, all found on a board that worked perfectly with a mouse:

1. **No touch sensor.** The drag library was configured with pointer and keyboard sensors only. On touch, a press-and-move is interpreted as a page scroll, so a card never begins to drag. The fix is an explicit touch sensor with a short activation delay (a deliberate long-press), so the library can tell "I'm starting to drag this card" apart from "I'm scrolling the page."
2. **Drop without tap.** The calendar handled the drag-to-reschedule gesture but had no tap handler at all. Every event was inert to a finger — you could not even open a job to look at it. Drag and tap are different handlers; having one says nothing about the other.
3. **The card was a dead end.** Even where a card opened, it linked nowhere — no way to jump to the client or site behind it. On desktop you hover and right-click your way around; on a phone, if it isn't a tappable link, it doesn't exist.

> On touch, a press-and-move is a scroll. Until you tell the interface otherwise, your drag gesture is the browser's scroll gesture.

## The deeper lesson: drag is for planning, tap is for the field

You *can* make drag work on touch with the right sensors. But even done correctly, dragging a small card across a cramped grid one-handed, on the move, is a bad field experience. The interaction model — not the CSS — is the problem. A responsive skin on a drag-first board is still a drag-first board.

So split the surfaces by what each is for:

- **Desktop planning views** (a month calendar, a lane board) keep drag — it's fast for an operator allocating a day's work at a desk.
- **The field surface is tap-first**: a run-sheet or list where you tap a job to open it and tap an action to advance it. No gesture that competes with scrolling, every target at least a finger wide, the next action one tap away.

If you only have time to make one surface genuinely good, make it the tap-first one — that's the one a contractor uses in a driveway. This is the mobile-interaction sibling of [scheduling jobs by the day](/docs/concepts/scheduling-jobs-by-the-day): both are about matching the tool to how the work is actually done, not to how it's convenient to build.

## Related

- [Scheduling jobs by the day, not the minute](/docs/concepts/scheduling-jobs-by-the-day)
- [Verifying the tenant that isn't your default](/docs/engineering-notes/verifying-the-tenant-that-isnt-your-default)