-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve breadcrumb bar accessibility #6912
Conversation
Co-authored-by: Daniel Beck <[email protected]>
Co-authored-by: Daniel Beck <[email protected]>
/reviewer @jenkinsci/sig-ux |
/label web-ui,enhancement |
I wasn't able to add the following labels: enhancement Check that the label exists and is spelt right then try again. |
/label rfe |
I think that both improvements make sense and clean up the UI! |
Makes sense to remove it, it displays content you already have on the page available.
+1 |
I'm not sure if I understand your argumentation. The view that renders the URL |
The There would never be a use case for a full (non- |
I see. So the same |
It has always worked like this and any attempt to change this will require changing practically every plugin that defines custom views. Just to make sure this is clear: Every view not named |
Tanks for clarifying. In my opinion having a |
|
Hey folks, Thought I'd comment on a few points just to share my thoughts:
I'd be opposed to giving every page their own breadcrumb item, IMO pages inside of the two column navigation sidebar (like the build page, plugin manager, design library) should only have the one breadcrumb (that being the parent page). I see the sidebar for switching part of a pages content, much like a tab bar, hence not having an additional breadcrumb for its children pages. To go back from the console output, clicking 'Status' should work just fine (unless there's a plugin/situation where that's not possible?)
In a similar fashion to the use of the breadcrumb bar item to refresh the page (sorry again!) the component wasn't designed to jump to the top of the page, although I can definitely see how that'd be helpful in both cases. In the current prototype design for Jenkins there's a button to do so in the sidebar which might be of interest to you. As for a possible reversion - if this is wanted (and I have no quarrel with that if that's preferred) I'd rather myself revert the change to the last breadcrumb (from a link to text) rather than revert the entire PR as there's still benefits to the component outside of the mentioned change. |
That might be an nice option, Another option is to stick the sidebar on scrolling down (position: fixed), allowing easy navigation between the different components (console, config etc.) |
No need. We can just revert part of this PR.
… necessitating even more changes, and not just in views. This is even worse than just adding breadcrumbs everywhere. |
if the URL is not the URL of the last breadcrumb - use the page title as a fallback if not specified? Will be a little "verbose" in many cases "Manage Jenkins -> Plugin Manager -> Plugin Manage Updates" (or something like that) (possibly will break somewhere though, and there is the question of if trying to infer a breadcrumb is even a good idea or not) |
(OT: to go to the top of the page with the mouse as would happen with the old behaviour there is a handy "reload" button in almost every browser just above the breadcrumb bar) for some accessibility there is keyboard for this too (ctrl+r, and F5 on windows (option something on mac?)) for assistive tech, not sure but I would expect a "reload" option to control the browser too. |
In case of https://weekly.ci.jenkins.io/view/all/builds, that would still result in a duplicate "All" link. Now what?
Just Home, which is Fn+Left on small keyboards. Also for iOS it's tapping near the top of the screen. Given the myriad options this feels like less of a necessity to me, although I guess some pages with dynamically loaded content still benefit from easy reloading. But that seems to me that the pages themselves should be looked at critically.
Firefox has reload in the context menu. |
@janfaracik multiple options on the sidebar should be taken into account but in general this is the idea fixed_sidebar.webm |
Yes, this is the concept we should use for the sidebar. |
I'm definitely in favour of the sidebar being stuck to the side of the screen 👍 The project config screen already does this, would be good to get it adopted by other pages consistently (only issue is pages with sidebars that are too long). |
see https://groups.google.com/g/jenkinsci-dev/c/2Z1OuI6XC90/m/Se_zVkfwGwAJ for a mailing list request of a revert or partial revert, @janfaracik are you able to take a look at this please? |
This reverts commit 12100d5.
What's new
Behaviour changes
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
Proposed changelog entries
section only if there are breaking changes or other changes which may require extra steps from users during the upgrade@Restricted
or have@since TODO
Javadoc, as appropriate.@Deprecated(since = "TODO")
or@Deprecated(forRemoval = true, since = "TODO")
if applicable.Desired reviewers
@jenkinsci/sig-ux
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are accurate, human-readable, and in the imperative moodupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate
to be considered (see query).