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:
- 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."
- 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.
- 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: both are about matching the tool to how the work is actually done, not to how it's convenient to build.