Zak Siddiqui
opened 8 hours ago
-
Thanks for the detailed write-up. I checked how the commit-page expander works today so we can file a precise Improvement.
Current behavior
Show more linesis a single action. You cannot choose a direction.- Between two change hunks, each click grows the hidden gap from both ends (about 15 lines toward the hunk above and 15 toward the hunk below). The expander row stays in the remaining gap.
- At the start of the file, the only possible direction is more lines above the first change.
- At the end of the file, the only possible direction is more lines below the last change.
There is no control that expands only downward, or that specifically reveals the context sitting just above the next hunk (“what is above the lines below”). That is the gap you described. The same expander is used on commit pages and other text diffs (pull requests, revision compare).
I will open a linked Improvement after you answer the questions below. A reply like
1B, 2A, 3A, 4A, 5Bis enough.1. Where should directional expand apply?
A. Commit detail page only B. All text diffs (commits, pull requests, revision compare) C. Commits and pull requests only
2. How should the two expand targets be presented?
A. Split the current expander into two side-by-side hit targets, with an angled divider so the “above” side is wider at the top and the “below” side is wider at the bottom B. GitHub-style: two chevrons (up / down) in the line-number gutter C. Two wide side-by-side hit targets with clear up/down chevrons, without an angled divider D. Keep one visible control; use a modifier (for example Shift-click) for the other direction
3. Should the two sides expand independently?
A. Yes — one side expands only toward the hunk above; the other expands only toward the hunk below B. No — either side expands both ends of the gap (today’s behavior, just two buttons) C. Independent directions, plus a third “reveal remaining lines” action on the same row
4. What should appear at the start or end of a file, where only one direction exists?
A. Keep a single expander there B. Still show two sides; hide or disable the impossible direction C. Single expander, and also offer “show all remaining lines”
5. Should “reveal all remaining hidden lines” be part of this same issue?
A. Yes, as a first-class control B. No — keep this issue focused on directional expand C. Yes, but only as a secondary gesture (for example double-click), not another icon
# Pros and cons Recommendation 1 A keeps scope tiny but leaves the same gap on PR/compare views. B is consistent everywhere the widget already exists. C covers the common review surfaces and skips less-used compare views. B. The expander is shared across text diffs; fixing only the commit page would leave the same problem on pull requests. 2 A is easy to click and encodes direction in the shape, but an angled divider can be subtle and harder to theme. B is familiar, but stacked icons on this row are likely too small. C is easy to click and obvious, with less visual risk than an angled cut. D is compact but easy to miss and poor on touch. A. That matches your proposed layout and keeps both targets on one row. Each half should be a large hit area, with a clear up/down cue so the angle is not the only signal. 3 A is the missing capability. B does not solve “expand only toward the lines below.” C is more powerful but a larger UX and implementation surface. A. Independent directions are the point of the request. A third “reveal all” control can wait (see question 5). 4 A stays simple. B is consistent but can look broken if one side is always disabled. C is useful for large files but mixes two features. A. Only show two sides when both directions exist. 5 A is convenient but widens the issue. B keeps the first change reviewable. C hides a useful action. B. File “expand remaining” separately if we still want it after directional expand lands. Once you confirm, I will create the Improvement and link it to this question.
-
- b
- c
- b
- a
-
-
@zaakiy Created the follow-up Improvement from your answers (1B, 2C, 3B, 4A) and closing this Question.
Tracked for implementation as issue #3069.
-
Previous Value Current Value Open
Closed
-
@servicedesk please modify OD-3069 to include the details of the scope as well as an implementation plan, such that it does not need to rely on this issue.
-
@zaakiy Updated issue #3069 so it stands alone: it now includes the full scope, expected behavior, and an implementation plan against the current expander code. You no longer need this question for context.
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
When I click on the expander (
Show more lines), Then only the lines above are expanded.What if I want to expand the lines below? What if I want to show what is above the lines below? There doesn't seem to be any way to do that.
If we create a way to do this, then it must be something that is easy to click on. Perhaps we could split the expander into two sides: one above and one below. It's not intuitive to know which side is pointing to expand above or below. Perhaps the divider that divides the icons (the left and right icons for above and below) could be angled in such a way that the top edge of one icon is wider and the bottom edge of the other icon is wider to indicate the direction that it would be expanded.
One alternative considered is, instead of splitting it into two icons side by side, to split it into two icons, one above the other. However, there is not enough space on the line, and this would make the icon too small.
Please help me create an issue to address this.
Don't assume. Ask high-level clarifying questions if needed.