rustdoc: clean up source sidebar hide button by notriddle · Pull Request #119066 · rust-lang/rust (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

notriddle

@notriddle

This is a redesign of the feature, with parts pulled from rust-lang#119049 but with a button that looks more like a button and matches the one used on other sidebar pages.

@rustbot

r? @fmease

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-rustdoc

Relevant to the rustdoc team, which will review and decide on the PR/issue.

labels

Dec 18, 2023

@rustbot

@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez

I found the previous design way more obvious. In this case, nothing indicates that:

  1. There is a sidebar
  2. The sidebar is not about the content but about files hierarchy

Also I really don't like the appearance when sidebar is opened for the title and close button (that is very much personal taste).

@notriddle

There is a sidebar

Is this about the empty vertical column when the sidebar is closed, or is it about the icon?

I had removed the vertical column because it ate into horizontal screen real estate, which is at a premium since code isn't line wrapped. But if you find that helpful, it could be redesigned to put it back.

The sidebar is not about the content but about files hierarchy

The > icon doesn't seem better about that.

Also I really don't like the appearance when sidebar is opened for the title and close button (that is very much personal taste).

I'm hoping to lean on people's existing familiarity with GitHub.

image

The fact that this particular icon doesn't seem to have a tooltip in GitHub's design should be criminal, and this PR does include a tooltip for this exact reason. But the icon isn't exactly the same (it's closer to Apple's).

@GuillaumeGomez

Is this about the empty vertical column when the sidebar is closed, or is it about the icon?

I had removed the vertical column because it ate into horizontal screen real estate, which is at a premium since code isn't line wrapped. But if you find that helpful, it could be redesigned to put it back.

On mobile the vertical column isn't visible and I think the problem is quite limited on desktop. But yes, I think it'd help to make the connection between the button and the sidebar.

The > icon doesn't seem better about that.

Indeed.

I'm hoping to lean on people's existing familiarity with GitHub.

And because of this comment, I just realized that this sidebar could be collapsed. I'm not sure if it's bad UI or just me who's very bad at that... 😅

The fact that this particular icon doesn't seem to have a tooltip in GitHub's design should be criminal, and this PR does include a tooltip for this exact reason. But the icon isn't exactly the same (it's closer to Apple's).

The button doesn't stand out much either in their case, hence why I never paid attention to it.

@rust-log-analyzer

This comment has been minimized.

@notriddle

@GuillaumeGomez

On mobile the vertical column isn't visible and I think the problem is quite limited on desktop. But yes, I think it'd help to make the connection between the button and the sidebar.

No problem. I've just pushed a new version of the preview docs and PR with the vertical placeholder column.

And because of this comment, I just realized that this sidebar could be collapsed. I'm not sure if it's bad UI or just me who's very bad at that... 😅

Do you think this is because:

@rust-log-analyzer

This comment has been minimized.

@notriddle

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@notriddle

It doesn't look quite right, because the lines are too far apart, and it's not going to be announced by screenreaders as a menu button, since that's not what the symbol means.

This adds a real tooltip and uses a better drawing of the icon.

@GuillaumeGomez

No problem. I've just pushed a new version of the preview docs and PR with the vertical placeholder column.

Much better for when the sidebar is closed. Now my only question is about the mobile version: currently we can open the sidebar wherever we are on the page. With your change, it's not possible anymore. I think to be taken into consideration as some source code pages can be quite huge and if you're at the bottom, it's quite annoying to go back to the top. And also, it makes the sidebar harder to "discover" if you're not already aware of its existence in this case.

Now for when the sidebar is open, I think the title should still be centered and the button remaining on the left side (as currently). You also removed the line which was used as marker to differentiate the "title" and the "content" before. Any reason for that change?

Do you think this is because:

* The buttons doesn't look like buttons? GitHub's buttons are pretty similar to ours, and if they don't look like buttons, then we should probably add more shading or otherwise try to improve clickability signifiers.

I think it would be already a pretty good improvement. I think it's because there is not a strong enough visual marker that I don't notice it.

* The icon is bad? What does a good sidebar icon look like? (hamburger buttons should open a modal slide-out, not toggle a persistent navigation panel)

Not a strong opinion on this one. But in this case, I think we should use the same icon for both mobile and desktop, whichever it is.

* This particular button is badly designed for some other reason?

Since you moved it back inside a "column" on desktop, looks good to me. On mobile I still have worries I described above.

@notriddle

Much better for when the sidebar is closed. Now my only question is about the mobile version: currently we can open the sidebar wherever we are on the page. With your change, it's not possible anymore.

That's odd. What browser are you testing on? The hamburger button is supposed to stick while you scroll, the same way the > button did.

Now for when the sidebar is open, I think the title should still be centered and the button remaining on the left side (as currently).

I prefer left alignment because the docs sidebar does it the same way.

You also removed the line which was used as marker to differentiate the "title" and the "content" before. Any reason for that change?

Not really. If you want it, I'll put it in.

Not a strong opinion on this one. But in this case, I think we should use the same icon for both mobile and desktop, whichever it is.

I guess it would need to use a hamburger in on both desktop and mobile, then, since the sidebar icon would be wrong (the file browser fills up the entire screen on mobile, but the icon depicts it as only partially filling the screen).

@notriddle

@GuillaumeGomez

That's odd. What browser are you testing on? The hamburger button is supposed to stick while you scroll, the same way the > button did.

After a force refresh, problem gone. All good there. :)

I prefer left alignment because the docs sidebar does it the same way.

Depends on the "mode": on mobile, the button is on the left and the title is on the right. There is no equivalent for desktop to compare to unfortunately.

Not really. If you want it, I'll put it in.

Let's see how it looks with it then. 👍

I guess it would need to use a hamburger in on both desktop and mobile, then, since the sidebar icon would be wrong (the file browser fills up the entire screen on mobile, but the icon depicts it as only partially filling the screen).

Sounds good to me.

@notriddle

Depends on the "mode": on mobile, the button is on the left and the title is on the right. There is no equivalent for desktop to compare to unfortunately.

That's how the top bar looks. I was thinking of the sidebar logo lockup and its headers.

Sounds good to me.

It doesn't sound very good to me, because that icon usually opens a modal instead of toggling a setting.

Backing up and trying to think of a different approach, maybe we should use an icon based on its purpose instead of its mechanics, which is the same across all viewport sizes.

Old versions

Before After
Closed image image
Open image image
Mobile Closed image image
Mobile Open image image

image

image

image

image

@notriddle

@GuillaumeGomez

Apart from the question I asked, looks good to me, thanks! Once it's answered, we can start the FCP.

@GuillaumeGomez

Time to start the FCP then.

@rfcbot fcp merge

@rfcbot

Team member @GuillaumeGomez has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@Nemo157

The fact that this particular icon doesn't seem to have a tooltip in GitHub's design should be criminal

Interestingly they do have a tooltip on this exact icon in the PR-diff-view.

The biggest thing I notice with this (and github's similar button) is that it feels wrong to me that it's on the left, the button to close a panel should be in the top-right. But that's likely platform-specific behavior, and I don't think rustdoc has any similar UI anywhere to be self-consistent with (unlike github which uses top-right-close everywhere I can see except this one panel).

@rfcbot

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@GuillaumeGomez

@bors

📌 Commit 9566db1 has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Dec 31, 2023

@bors

@bors

@notriddle notriddle deleted the notriddle/sidebar-source-redesign branch

December 31, 2023 17:43

@bors bors mentioned this pull request

Dec 31, 2023

@rust-timer

Finished benchmarking commit (67b6975): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) 1.2% [1.2%, 1.2%] 1
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) 1.2% [1.2%, 1.2%] 1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) 2.6% [2.6%, 2.6%] 1
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) -2.2% [-2.2%, -2.2%] 1
All ❌✅ (primary) 2.6% [2.6%, 2.6%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 666.618s -> 665.69s (-0.14%)
Artifact size: 311.73 MiB -> 311.76 MiB (0.01%)

@notriddle

Not even a change to the doc build. It's spurious.

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Mar 29, 2024

@he32

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Oct 13, 2024

@he32

This is based on the pkgsrc-wip rust180 package, retaining the main pkgsrc changes as best as I could.

Pkgsrc changes:

Upstream chnages:

Version 1.80.1 (2024-08-08)

Version 1.80.0 (2024-07-25)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

Version 1.79.0 (2024-06-13)

Language

Compiler

Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Misc

Compatibility Notes

Version 1.78.0 (2024-05-02)

Language

Compiler

Target changes:

Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Misc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

Version 1.77.0 (2024-03-21)

Compiler

Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

Cargo

Rustdoc

Misc

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.