Frame move up/down buttons are ambiguous — clarify they reorder frames #162

New issue

Open

opened 2026-05-06 11:49:07 +00:00 by AhmedHanafy725 · 2 comments

AhmedHanafy725 commented

2026-05-06 11:49:07 +00:00

Member

Frames have move up / move down buttons in the floating toolbar but the labels/icons dont communicate that they reorder the frame in the slide list (z-order / presentation order). Users see them as arbitrary up/down. Either rename the tooltips to Move frame earlier / Move frame later (or Bring frame forward / Send frame backward) and use clearer icons (e.g. bi-arrow-up-square / bi-arrow-down-square or bi-list-ol-like icons), or replace with explicit Reorder controls. Apply only to frames; the rest of the bring-to-front / send-to-back actions on other shapes are unaffected.

Frames have move up / move down buttons in the floating toolbar but the labels/icons dont communicate that they reorder the frame in the slide list (z-order / presentation order). Users see them as arbitrary up/down. Either rename the tooltips to `Move frame earlier` / `Move frame later` (or `Bring frame forward` / `Send frame backward`) and use clearer icons (e.g. `bi-arrow-up-square` / `bi-arrow-down-square` or `bi-list-ol`-like icons), or replace with explicit Reorder controls. Apply only to frames; the rest of the bring-to-front / send-to-back actions on other shapes are unaffected.

AhmedHanafy725 commented

2026-05-06 12:00:20 +00:00

Author

Member

Spec

Root cause

In _renderFrame (selection_toolbar.js ~L1141–1150) the two buttons use generic bi-arrow-up / bi-arrow-down icons with Move up / Move down tooltips. Their handlers actually call WhiteboardFrames.moveFrameUp/moveFrameDown, which reorder the frame in the slide deck / presentation order (via frameOrder attribute + slide-number badges + sync data.order). They are NOT canvas z-order operations — those live in tools.js (bringToFront/sendToBack) and use bi-front/bi-back.

The context menu already labels the same actions clearly (Move slide up / Move slide down — contextmenu.js L80–81). Only the toolbar surface uses the ambiguous wording.

Files to Modify

crates/hero_whiteboard_ui/static/web/js/whiteboard/selection_toolbar.js — only file (only the two _buildIconBtn calls in _renderFrame).

Implementation Plan

Step 1 — update icons + tooltips on the two frame reorder buttons

Button	New icon	New tooltip
Up	`bi-arrow-up-square`	`Move slide earlier (in presentation order)`
Down	`bi-arrow-down-square`	`Move slide later (in presentation order)`

No handler changes. The square-arrow variants visually differ from the bare arrows used elsewhere in the toolbar, pairing well with the slide-number badge already on each frame.

"Bring forward / Send backward" was rejected — overlaps with canvas z-order (Bring to Front / Send to Back) used on other shapes and would deepen, not resolve, the confusion.

Acceptance Criteria

Up button tooltip: Move slide earlier (in presentation order). Icon: bi-arrow-up-square.
Down button tooltip: Move slide later (in presentation order). Icon: bi-arrow-down-square.
Click behavior unchanged — WhiteboardFrames.moveFrameUp/moveFrameDown, slide badges re-number, sync round-trip via data.order.
Buttons appear only on selected frames.
Canvas z-order on regular shapes (bringToFront/sendToBack icons / labels / context-menu entries) untouched.

What NOT to break

WhiteboardFrames.moveFrameUp / moveFrameDown bodies and contextmenu.js callers.
WhiteboardObjects.redrawAllFrameBadges / .order-badge rendering.
Canvas z-order path: tools.js actions, keyboard shortcuts, context-menu "Bring to Front / Send to Back" entries.
Other _renderFrame controls (title edit).
_buildIconBtn helper signature.

## Spec ### Root cause In `_renderFrame` (selection_toolbar.js ~L1141–1150) the two buttons use generic `bi-arrow-up` / `bi-arrow-down` icons with `Move up` / `Move down` tooltips. Their handlers actually call `WhiteboardFrames.moveFrameUp`/`moveFrameDown`, which reorder the frame in the **slide deck / presentation order** (via `frameOrder` attribute + slide-number badges + sync `data.order`). They are NOT canvas z-order operations — those live in `tools.js` (`bringToFront`/`sendToBack`) and use `bi-front`/`bi-back`. The context menu already labels the same actions clearly (`Move slide up` / `Move slide down` — contextmenu.js L80–81). Only the toolbar surface uses the ambiguous wording. ### Files to Modify - `crates/hero_whiteboard_ui/static/web/js/whiteboard/selection_toolbar.js` — only file (only the two `_buildIconBtn` calls in `_renderFrame`). ### Implementation Plan #### Step 1 — update icons + tooltips on the two frame reorder buttons | Button | New icon | New tooltip | |---|---|---| | Up | `bi-arrow-up-square` | `Move slide earlier (in presentation order)` | | Down | `bi-arrow-down-square` | `Move slide later (in presentation order)` | No handler changes. The square-arrow variants visually differ from the bare arrows used elsewhere in the toolbar, pairing well with the slide-number badge already on each frame. "Bring forward / Send backward" was rejected — overlaps with canvas z-order (`Bring to Front` / `Send to Back`) used on other shapes and would deepen, not resolve, the confusion. ### Acceptance Criteria - [ ] Up button tooltip: `Move slide earlier (in presentation order)`. Icon: `bi-arrow-up-square`. - [ ] Down button tooltip: `Move slide later (in presentation order)`. Icon: `bi-arrow-down-square`. - [ ] Click behavior unchanged — `WhiteboardFrames.moveFrameUp`/`moveFrameDown`, slide badges re-number, sync round-trip via `data.order`. - [ ] Buttons appear only on selected frames. - [ ] Canvas z-order on regular shapes (`bringToFront`/`sendToBack` icons / labels / context-menu entries) untouched. ### What NOT to break - `WhiteboardFrames.moveFrameUp` / `moveFrameDown` bodies and `contextmenu.js` callers. - `WhiteboardObjects.redrawAllFrameBadges` / `.order-badge` rendering. - Canvas z-order path: `tools.js` actions, keyboard shortcuts, context-menu "Bring to Front / Send to Back" entries. - Other `_renderFrame` controls (title edit). - `_buildIconBtn` helper signature.

AhmedHanafy725 commented

2026-05-06 12:01:23 +00:00

Author

Member