J3.07.1keyboard reorderingdesignresearch

Reordering needs move-up/move-down or a position field

Aliases: move up move down · position number · reorder without drag

What it is

If a list, board or play queue changes order by dragging, keyboard and single-pointer users do not need “another gesture”. They need discrete reorder commands: move the current item up or down, or type the position it should occupy. These are the concrete alternative widgets for drag-sorting, not the existence criterion “is there an alternative”.

Move up / down suits short lists and small nudges; a position field suits random insertion in long lists. Both may exist; at least one must be able to place any item at any legal index.

Why it happens

Drag-sorting is a continuous 2D task: grab, travel along the list, release in a gap. Discrete commands turn it into stepping or random access. Each move-up / move-down has a clear new state; focus can stay on the item; switch scanning can finish it. A position field skips the intermediate steps, at the cost of understanding “nth” — heavier cognitively, cheaper on a long queue.

“Pin to top / send to bottom” alone is not enough: arbitrary insertion in the middle is gone, capability already shrunk. A non-focusable icon beside the drag handle is not a discrete command either. The command has to live in that item’s keyboard context: select the item and fire it, rather than hunt a page-corner “sort mode” first.

Studying it

Select an item in the middle of a list from the keyboard. Using only move up / down or a position field, take it to the other end. Record: can every legal index be reached, does focus follow the item, do commands disable at the ends rather than error.

Contrast: do the same reorder by dragging once, and compare the set of reachable slots. If the click path cannot reach a slot dragging can, that is capability mismatch — judged on a later leaf. This leaf first asks whether the widgets are move up / down or a position field, and whether they actually change order.

Where it stops holding

Automatic sort (by name, by date) with no user-defined order does not need these widgets. Playlists, form-field order and cards inside a board column that allow custom order do. “Promote / demote / before / after” on a tree is the same family of discrete commands on a hierarchy, and may replace linear up / down. A touch list that swaps two selected items instead of up / down still counts if any item can reach any position.

Applying it

  • On every reorderable item, provide move up and move down (or equivalent steps), or a numeric field for current position.
  • Keep focus on the item being moved. At the ends, disable that direction instead of bouncing the item or throwing an error page.
  • How to check: disable dragging and move the third item to first and last from the keyboard. If that fails, or only pin-to-top works and mid-list insertion does not, the discrete reorder widgets are not in place.

Related

  • Same group: J3.07.2 Drag-and-drop upload needs a file picker · J3.07.3 The alternative path must match the main path's capabilities
  • Nearby: J3.05 Single-pointer alternatives · H8.03 Drag-and-drop reordering · C3.18 Long-press drag to reorder
  • Search terms: move up move down · reorder · position field

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J3.07.1