Improve breadcrumb bar accessibility and appearance

[janfaracik]

Small followup to #6837 in which it was mentioned that it would be good to highlight visually the difference between the breadcrumb which the user is on, and its parents.

Before

After

What's new

• The active breadcrumb is now a text element rather than a clickable link (better for accessibility)
• The active breadcrumb now appears differently to its parents
• Cleanup to the code to bring it inline with modern Jenkins BEM practices

---

Behaviour changes

• The active breadcrumb (due to it being text and not a link) no longer has a dropdown menu
  • I'd argue the menu wasn't necessary as it just duplicates what's on the page
  • For the Configure System page, the section-to-sidebar-items solution would be better suited
• The chevron after the active breadcrumb has been removed
  • It suggests there is more after the active breadcrumb, but that's never the case

Would be good to hear thoughts on the above ^

---

Bugs

• [x] ~There is no active breadcrumb on plugin manager subpages~

Proposed changelog entries

• The active breadcrumb bar item is now more apparent

Proposed upgrade guidelines

N/A

Submitter checklist

• [ ] (If applicable) Jira issue is well described
• [ ] Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• [ ] Appropriate autotests or explanation to why this change has no tests
• [ ] New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• [ ] New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO") if applicable.
• [ ] For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@jenkinsci/sig-ux

Maintainer checklist

Before the changes are marked as ready-for-merge:

• [ ] There are at least 2 approvals for the pull request and no outstanding requests for change
• [ ] Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• [ ] Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
• [ ] Proper changelog labels are set so that the changelog can be generated automatically
• [ ] If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

/reviewer @jenkinsci/sig-ux

[timja]

/label web-ui,enhancement

[comment-ops-bot[bot]]

I wasn't able to add the following labels: enhancement

Check that the label exists and is spelt right then try again.

[timja]

/label rfe

[uhafner]

Behaviour changes

• The active breadcrumb (due to it being text and not a link) no longer has a dropdown menu

  • I'd argue the menu wasn't necessary as it just duplicates what's on the page
  • For the Configure System page, the section-to-sidebar-items solution would be better suited

• The chevron after the active breadcrumb has been removed

  • It suggests there is more after the active breadcrumb, but that's never the case

Would be good to hear thoughts on the above ^

I think that both improvements make sense and clean up the UI!

[NotMyFault]

Behaviour changes

• The active breadcrumb (due to it being text and not a link) no longer has a dropdown menu
  • I'd argue the menu wasn't necessary as it just duplicates what's on the page
  • For the Configure System page, the section-to-sidebar-items solution would be better suited

Makes sense to remove it, it displays content you already have on the page available.

• The chevron after the active breadcrumb has been removed
  • It suggests there is more after the active breadcrumb, but that's never the case

+1

[jtnord]

To me the screenshot looks like the breadcrumbs are now disabled (non interactive) which removes the visual hint that you can interact with them, which to me is not a good thing.

The active breadcrumb (due to it being text and not a link) no longer has a dropdown menu I'd argue the menu wasn't necessary as it just duplicates what's on the page

but the breadcrumb was a much more concise and easier to use way to get to it - with less scrolling (esp on long pages where want you want is somewhere in the middle between several graphs).

The chevron after the active breadcrumb has been removed

but there can be things after it like:

I believe the API for that is https://javadoc.jenkins.io/jenkins/model/ModelObjectWithChildren.html Whilst it would be silly to put things only in the context menu and not on the page, having things on the page but not in the context menu to reduce clutter is not unheard of.

[janfaracik]

To me the screenshot looks like the breadcrumbs are now disabled (non interactive) which removes the visual hint that you can interact with them, which to me is not a good thing.

I understand your point, we need some way to visually separate the breadcrumbs so I went with dimming the inactive ones. I'd worry that if we were to make them look like links (e.g. blue) we'd draw too much attention to them, and if we were to highlight the active breadcrumb it might look interactive which it isn't. It's a tricky one.

but the breadcrumb was a much more concise and easier to use way to get to it - with less scrolling (esp on long pages where want you want is somewhere in the middle between several graphs).

I understand that too, I think that the breadcrumb menus are more of a bandaid to the problem however, the problem being overall page complexity/poor use of space.

Using a sidebar like the new config screen/plugin manager is a better use of the real estate imo and it's also more obvious for the user, rather than a dropdown menu in the breadcrumb - a pattern which I think is exclusive to Jenkins. The project/build screens need a lot of work (if not a total rework) and I think it'd be great to see it reorganised so it's faster for the user to get to what they need.

[jtnord]

Using a sidebar like the new config screen/plugin manager is a better use of the real estate imo and it's also more obvious for the user

that would not work very well (if at all) for Multibranch projects or folders. I would not expect it's children to be listed there.

a pattern which I think is exclusive to Jenkins

FWIW windows explorer does show the chevron after the last item to allow you to select children so it is not a completely unexpected / unusual paradigm

the chevron also acts as an indicator there is further navigation possible (for example you do not get it when there are no "children" present from the API call (e.g. a specific build)

[github-actions[bot]]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[basil]

The gray background intended for the default theme applies even when I choose the Dark Theme, which makes Jenkins unusable in the Dark Theme.

[janfaracik]

that would not work very well (if at all) for Multibranch projects or folders. I would not expect it's children to be listed there.

FWIW windows explorer does show the chevron after the last item to allow you to select children so it is not a completely unexpected / unusual paradigm

Ah, I had forgotten Windows had that - haven't properly used a Windows machine for a few years now.

I've restored the last chevron (if it's clickable), we can always take another look at it in the future once some layout improvements roll in to Jenkins. Hope that addresses your issue :)

---

The gray background intended for the default theme applies even when I choose the Dark Theme, which makes Jenkins unusable in the Dark Theme.

There's a PR open for that https://github.com/jenkinsci/dark-theme-plugin/pull/219 :)

[basil]

Thanks Jan, sorry I missed that - I searched this page for "dark" but didn't search the dark theme plugin's open pull requests.

[timja]

I've restored the last chevron (if it's clickable), we can always take another look at it in the future once some layout improvements roll in to Jenkins. Hope that addresses your issue :)

~Doesn't seem to be working right.~

~e.g. take a freestyle job and click the last chevron (which is there now) it does nothing.~

job needs to be built once for that to do anything, maybe it should be hidden if that's the case. but I've verified that it's a pre-existing issue

[timja]

@NotMyFault can you re-check please?

[timja]

Actually I found an issue.

the context menu isn't working for credentials on: http://localhost:8080/manage/credentials/

e.g. There's no context menu for:

on weekly.ci.jenkins.io:

[timja]

(FWIW I'm working on a credentials plugin improvement currently in this area)

[timja]

(credentials plugin PR that makes removing the breadcrumb from there okay: https://github.com/jenkinsci/credentials-plugin/pull/364)

[NotMyFault]

Hey @jtnord, do you mind taking a look again, to verify whether your concerns have been addressed? :)

[jtnord]

So a quick run through this locally and it all seems to work, however I still believe that the grey for breadcrumbs is not the right choice.

As you can not actually click on the current breadcrumb (it would just take you to the page you are on) so in essence we highlight the current breadcrumb using the same colour as we do for interactive links (in the sidebar) , but it is the only non interactive breadcrumb out of all of them. Given the "disabled" appearance of the other breadcrumbs I feel this is a backward step, leading to a worse discoverability and adding to cognitive overload (it is disabled if x or y but not in the breadcrumb. its a link in most of jenkins but not if it is text in the main panel or in the breadcrumb bar)

For example - https://getbootstrap.com/docs/4.0/components/breadcrumb/ shows that all the bread crumbs except the current page crumb should be highlighted, which is a more usual paradigm esp given you can interact with everything except the current element. I will note however that https://www.adobe.com/uk/products/photoshop.html uses the opposite of that (which is what this PR uses).

from the description

The chevron after the active breadcrumb has been removed It suggests there is more after the active breadcrumb, but that's never the case

I think this is now out dated - if the active crumb is a ModelObjectWithChildren the crumb is still shown.

[cristina-pizzagalli]

FWIW, I agree with @jtnord 's point about the inversion of typical link colours. A user will generally expect the active links to be the darker colour, with disabled links being lighter. If the colours used could be swapped, I think it would help improve the usability of the breadcrumb nav. Thanks :)

[janfaracik]

So a quick run through this locally and it all seems to work, however I still believe that the grey for breadcrumbs is not the right choice.

As you can not actually click on the current breadcrumb (it would just take you to the page you are on) so in essence we highlight the current breadcrumb using the same colour as we do for interactive links (in the sidebar) , but it is the only non interactive breadcrumb out of all of them. Given the "disabled" appearance of the other breadcrumbs I feel this is a backward step, leading to a worse discoverability and adding to cognitive overload (it is disabled if x or y but not in the breadcrumb. its a link in most of jenkins but not if it is text in the main panel or in the breadcrumb bar)

I 100% get where you're coming from, my only gripe is that for me that colour scheme just doesn't feel right for the breadcrumb bar. Maybe that's just a me thing though, like you mentioned though there are a lot of different design systems that handle it in various different ways - there isn't one ideal way of approaching it.

vs

How would you feel about me undoing the change in colour for now and coming back to it at a later date? It's only a couple of colour vars so it wouldn't be too much pain to come back to (especially when more of Jenkins gets restyled etc). That way we could get the improved accessibility features in.

I think this is now out dated - if the active crumb is a ModelObjectWithChildren the crumb is still shown.

I've updated the PR description, and I've also added the aria labels from the Bootstrap link you sent - thanks! :)

[timja]

Out of the two screenshots you posted the second one looks better to me

[jtnord]

How would you feel about me undoing the change in colour for now and coming back to it at a later date?

probably better so this can move on.

Out of the 2 screenshots I prefer the first - however would also expect the > to be dark as they are also interactable elements. That said I wonder if things could be improved with a more radical change than just colour, but as we said for a discussion elsewhere but leaving here just to get people thinking (and I expect several people to say OMG that is ugly!).

I think the main issue we have is that the breadcrumb bar is not just a breadcrumb bar. It has navigation from the element (to the page), from the end of the element (to children) and for some things from and extra bit that is neither the element nor the end of the element (the context menu).

[janfaracik]

How would you feel about me undoing the change in colour for now and coming back to it at a later date?

probably better so this can move on.

Awesome, I've removed the styling changes so the breadcrumb items look the same as they did before now.

I think the main issue we have is that the breadcrumb bar is not just a breadcrumb bar. It has navigation from the element (to the page), from the end of the element (to children) and for some things from and extra bit that is neither the element nor the end of the element (the context menu).

Agreed. There was an attempt at simplifying the breadcrumb bar quite a while back now in #6084 in which the two dropdown menus were merged into one - would be good to take another look at that and menus in general in Jenkins in the future.

[timja]

@jtnord are you able to re-review this please?

[jtnord]

@jtnord are you able to re-review this please?

I won't be able to look at this today, however based on

Awesome, I've removed the styling changes so the breadcrumb items look the same as they did before now

I think that should have addressed my concern.

[timja]

I won't be able to look at this today, however based on

doesn't have to be today, did you want to look before merge or should we ship and iterate if needed?

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[benipeled]

As mentioned above by @jtnord, the side-effect of this change is that the last object in the bar is not clickable at - ex. the build number - and this is kind of "regression" since it was quite useful in case of long pages (console) that we want to quickly return to the top of the page,

@janfaracik can we add back the clickable behavior?