Zak Siddiqui
opened 11 hours ago
-
The height jump is real: the workspaces button (and the pin button next to it) live in the wrapping title row and are hidden until hover. When the title already fills that row, revealing the button wraps it onto a new line.
Your idea of placing it next to the state badge is a strong default. The fields row is already there, so we do not add a line, and the icon stays in a stable, easy-to-scan zone. One caveat: State can be hidden via Fields & Links, so if we go that way the button should fall back to the start of the fields row.
Please pick from the options below so we can lock the design.
1. Where should the workspaces button sit?
- A. Next to the state badge
- B. Stay after the title, overlay so it cannot wrap
- C. Always-visible slot at the start of the fields row
- D. Dedicated column beside the issue
# Option short title Explanation Pros Cons A 🎯 Next to state Place the icon immediately after the state badge in the existing fields row. If State is not shown, put it at the start of that row. Reserve its width so hover does not shift other fields. ✨ No extra row, so no height jump
🎯 Stable, easy-to-find zone next to state
👍 Matches how people already scan status⚠️ Exact pixel position still shifts a bit with state label width
😕 If State is hidden, the fallback spot is slightly less obviousB Overlay on title row Keep the current “after title” placement, but take the button out of document flow so it cannot wrap. ✨ No layout shift
👍 Same place people see it today
🎯 Horizontal position stays more consistent⚠️ Can overlap a long title or nearby controls
😕 Still not tied to a semantic landmark like stateC Always-visible fields-row slot Same place as A, but always shown (not hover-only). ✨ No hover surprise or height jump
🎯 Always findable
👍 Small icon, low clutter if we keep it muted⚠️ Adds chrome to every row
😕 Less consistent with pin, which is hover-only todayD Dedicated action column Add a fixed-width column for workspaces (and possibly pin). ✨ Perfect alignment across rows
🎯 No wrap, no height jump⚠️ Uses extra horizontal space
😕 Heavier change to list density2. Should the pin button follow the same placement?
Pin has the same hover-wrap behavior today.
- A. Yes, move pin with workspaces
- B. No, only change workspaces
- C. Keep pin after the title, but overlay so it cannot wrap
# Option short title Explanation Pros Cons A 🎯 Move pin too Treat workspaces and pin as one hover action group next to state (or in the same reserved slot). ✨ One consistent hover behavior
👍 Fixes both height jumps
🎯 Easier to learn⚠️ Two icons beside state, slightly busier
😕 Pin is project-list-only, so the group size variesB Workspaces only Leave pin in the title row. ✨ Smaller change
👍 Pin stays near the title⚠️ Title-row wrap can still happen when pin appears
😕 Two different hover patternsC Overlay pin only Move workspaces to state; keep pin after the title without letting it wrap. ✨ Pin stays near the title
👍 Workspaces still get the landmark placement⚠️ Two different homes for similar hover actions
😕 Slightly more complex3. Should the workspaces button stay hover-only?
- A. Hover-only, with reserved space
- B. Always visible
- C. Always visible when the issue already has workspaces; hover-only otherwise
# Option short title Explanation Pros Cons A 🎯 Hover-only, reserved space Keep today's hover reveal, but reserve the icon width so nothing shifts. ✨ Quiet list until you need the action
👍 No jarring movement
🎯 Same interaction people already know⚠️ Still hidden until hover (harder on touch)
😕 Reserved gap is empty when not hoveringB Always visible Show the icon on every eligible row. ✨ Easy to find and tap
👍 No hover dependency⚠️ More visual noise
😕 Breaks the current “actions appear on hover” patternC Visible when in use Show it when the issue already has workspaces; otherwise hover-only. ✨ Highlights issues that already have workspaces
👍 Less noise on unused rows⚠️ Inconsistent appearance across rows
😕 Harder to discover “create workspace” on issues that have none4. Apply the same treatment to the pull request list?
The PR list uses the same hover-wrap pattern for its workspaces button.
- A. Yes, keep issue and PR lists consistent
- B. Issues only for now
- C. Same placement rule, but next to PR status instead of issue state
# Option short title Explanation Pros Cons A 🎯 Same treatment on PRs Use the same placement and hover rule on the PR list. ✨ Consistent product language
👍 Fixes the same jump in both lists⚠️ Slightly larger change
😕 PR rows already have status, branches, and jobs competing for that rowB Issues only Change the issue list now; leave PRs as they are. ✨ Smaller scope
👍 Lets us validate the issue-list design first⚠️ PR list keeps the height jump
😕 Two different workspaces-button behaviorsC Next to PR status Same idea as issues, mapped to the PR status badge. ✨ Same landmark-next-to-status idea
🎯 Easy to find on PR rows⚠️ PR status is already a distinct column-like block
😕 Not a pixel-identical twin of the issue listMy recommendation is 1A + 2A + 3A + 4A: put workspaces (and pin) next to state, keep them hover-revealed with reserved space so the row never jumps, and use the same rule on the PR list.
Reply with your letters (for example
1A 2A 3A 4A) and we can implement from there.
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
Issue Votes (0)
Watchers (3)
In the issues list, the workspaces button for each issue is hidden by default. When the mouse hovers over the issue, the workspaces button is shown, but it is in its own row. Instead, it should be part of the same row as the previous one.
The reason for this is that when you hover over it, the row height expands, and that has a jarring effect on the UX.
At the same time, I can understand why the current implementation is more beneficial: it means the horizontal alignment of the workspaces icon is always on the left, making it easier to find visually. If we simply added it to the previous row, the workspaces button would be in a different position every single time.
Perhaps what we could do is put the workspaces button right next to the state of the issue (for example, open, in progress, etc.). This way, the horizontal position need not be hunted down, even though it won't be exactly the same number of pixels due to the variable width of the state label. At least it's still a very good place for us to find it when we need it. Since we're not creating a new row to display it, we are not going to have that same jarring effect on the UX.
Let's work together to create a design.
Don't assume. Ask high-level clarifying questions if needed.