rustdoc: use a button instead of a bar for search #133279
Conversation
This is a response to complaints that the header area takes up too much vertical space, forcing the user to scroll more than they ought to need. It also adds a reasonable way to pick the crate name before actually searching, which was also a feature that people ask for.
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
|
My immediate concern is how this will look on mobile, expecially with long crate names. the status quo is already pretty bad.
|
|
I'm not too sure what to think about it. Turning the search input into a button (to make the search input appear) makes it more tricky to access the search feature. Also, on mobile it's really not great as the space available is very little. However I like a few things from this PR:
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
A little bit, but it does have an explicit "Search" label, and the magnifying glass is very popular anyway.
Here's one concept I came up with to try to claw back more space:
I don't want to make focus do that on its own, because it acts badly when tabbing through the page. A switch like that needs to be a button or link.
The button I have now should act just like a normal link. To exit, use your browser's back button. It's a very deliberate choice, to avoid bugs like I mentioned under bullet point 2: you should never be in the search page unless the It happens to be implemented in JavaScript, but that should be invisible to the end-user. As far as the interaction model is concerned, that search button should be indistinguishable from an ordinary link. You can even right-click on it and open it in a new tab. |
|
making things behave like links instead of magically doing stuff on hover is much better ux, that's the main reason I abandoned the old popover-on-hover PR. |
|
The whole mobile experience is big downgrade: the search button is small compared to the rest of the elements, and it's not necessarily obvious what we'll be search. The search input is doing a perfect job for this case. For desktop, like I said I'm very shared. I like some improvements, but having to click on a button to have access to the search feature is (in my opinion) a big inconvenience. The search in the rust docs is a major feature and something we want to make as accessible as possible. Hiding it behind a button, even if it seems like a small inconvenience is actually (again, since in my opinion) a huge step back.
Fair enough. Maybe we could have some "down arrows" button appearing below the search input when focused which would switch to this view? |
r? @GuillaumeGomez
CC @lolbinarycat @liigo
This is an attempt to address three complaints:
The header area takes up a lot of vertical space, and is generally quite "heavy" feeling.
Fixes [rustdoc] issues of the three-big-buttons #132386
Back and forward are kind of wacky, because there's no "single source of truth" for whether the search mode is open or not. Can't find an issue, but here's a screen recording where I reproduce it.
screen-record-history-bug.mp4
https://imgur.com/ZVnHv3o
You can't see the crate picker list, or anything else that we might want to show you, until after you've already typed your search term. [rustdoc search] allow setting crates to search in before showing results #129537 (also notice the example searches, which exist in Hoogle and this tweak adds)
Preview page: https://notriddle.com/rustdoc-html-demo-15/search-button/std/index.html
Video:
screen-record.mp4
https://imgur.com/c37VxLb
Screenshot: