Breadcrumbs on mobile — proposed implementation for docs.rh

[wesleymiles]

Hi RHDS team,

We've been working through DOCS-2212: adding breadcrumbs to smaller screens on the doc site — and wanted to share where we've landed so you're in the loop and can let us know the best way to feed this back into the design system.

Design goals for the ask:

• add to smaller screens
• minimize wrapping / vertical real estate
• give ability to scope back to a higher level page
• lean on component

Proposal

After digging in and running a competitive analysis of 32 docs sites, we're proposing the following:

• Front-truncation instead of middle-truncation: We'd like to move the truncation ("…") to the beginning of the breadcrumb trail (the left side). On mobile, this saves precious real estate and keeps the most relevant ancestor items visible.

• Limit visible items to three: Docs can get deeply nested, and showing the full breadcrumb trail creates more noise than signal. We're proposing capping the visible breadcrumb items at three. For deeply nested pages, users can rely on the TOC to understand and navigate the full hierarchy. We can continue to use JSON-LD Schema markup under the hood for seo and accessibility. See IBM for an example.

• Trailing chevron on the last visible item: This gives users a visual connector from the breadcrumbs to the h1. This is also common on competitors, see microsoft learn.

See a figma (the Round 4 artboard) showing a docs + learn page example. We feel good about this direction and are talking through implementation with engineering now.

That said, we know this touches the breadcrumb component more broadly, and we want to make sure any learnings or patterns that are useful get back to RHDS. Thanks for any guidance, and happy to walk through anything.

Wes

[marionnegp]

• I like the idea of front truncation. I think it should be a new option rather than a change to the default behavior.
• Question for the RHDS team: Would limiting the visible items to three be a design system change or something done on the RHDS user's end?
• The trailing chevron before the <h1> tripped me up for a second. This is a change that I think we'd want to make consistent across all breadcrumbs, so users don't think it looks broken only on Docs. However, we'd need to make sure that this works for everything that currently uses breadcrumbs. We'll also need to make sure that trailing caret doesn't look like it's pointing to something else, like an Ask AI button, in the same section.

[wesleymiles]

FWIW I don't think docs is too tied to having the trailing chevron

[bennypowers]

The truncation behavior is currently hardcoded, so this requires a development cycle in RHDS

[markcaron]

@wesleymiles all very good ideas, IMO!

At the moment, however, we're focusing on design system alignment on Project Felt in Q3 and Q4. So, any design changes should go through the DPO (or at least in collaboration with UXD) on what Felt breadcrumbs should look like and what the API should be, etc. We'll need full design + API specs on this too. This way we can just build Felt breadcrumbs, instead of using critical dev cycles (we have very limited resources ATM) to build/maintain a divergent breadcrumb component.

[wesleymiles]

@markcaron Makes sense on Felt alignment and DPO ownership — we don’t want a divergent breadcrumb either.

So, we'll consider adding breadcrumbs on mobile as it is out of the box, even though it's not ideal as some titles are long.

I can continue owning this proposal though, for whenever the team is ready to start talking about it.