@JFernandez-WMF the Growth uses cases appear to be single links to return to a previous (or higher order) page ("back links"), while the other use cases are what I would call more traditional "breadcrumb" examples. Are there situations where the Growth use cases would have deeper nesting, or it is always just a single "back link"?

Thank you @Dogu for volunteering to develop this component. @egardner @DTorsani-WMF are available from the design system team to support you with this contribution! And thank you @Sneha for contributing the design!

@DTorsani-WMF, @Sneha, I currently don't have access to the linked spec files. I've requested access, and I would appreciate it if someone could approve my request. Thank you!

Hi @Dogu thanks for the heads up. We have updated the permissions for the Figma file so you should be able to view it now. Let me know if you have any issues.

In T361745#10358083, @DTorsani-WMF wrote:

Hi @Dogu thanks for the heads up. We have updated the permissions for the Figma file so you should be able to view it now. Let me know if you have any issues.

Thanks!

In T361745#9694315, @CCiufo-WMF wrote:

@JFernandez-WMF the Growth uses cases appear to be single links to return to a previous (or higher order) page ("back links"), while the other use cases are what I would call more traditional "breadcrumb" examples. Are there situations where the Growth use cases would have deeper nesting, or it is always just a single "back link"?

Yes to deeper nesting. That Growth example entry is just showing the default MediaWiki display of breadcrumbs/subpages. E.g. Here are a few sub-sub-subpages

• https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks/Add_an_image
  • (& RTL) https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks/Add_an_image/ar?uselang=ar
• https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_in_Red/Missing_articles_by_dictionary/Dictionary_of_Women_Worldwide/Occupations_A_to_F
• https://meta.wikimedia.org/wiki/Wikimedia_Foundation/Advancement/Community_Growth/Community_Programs
• and a sub-subpage from a 3rd party wiki: https://terraria.wiki.gg/wiki/Ankh_Shield/Crafting_tree/es
• All of these are just separated by https://www.mediawiki.org/wiki/MediaWiki:Pipe-separator (which is simply overridden with CSS at that 3rd party wiki)

Whereas the Wikivoyage and Wiktionary examples are showing the output of custom templates at those specific wikis (https://en.wikivoyage.org/wiki/Template:IsPartOf and https://en.wiktionary.org/wiki/Template:auto_cat respectively).

I noticed that in some of the examples above the breadcrumb trail seems to be reflected in the title itself in addition to breadcrumb. Ideally the title would just be the current page but I have noticed this pattern of showing the full trail in the title. It can be useful for short trails but I can imagine it become too large for long trails. The title is not related to breadcrumb component but we could take a note of this and possibly include in the guidelines? @DTorsani-WMF

+1 to the title of the page being only the current page. We can certainly provide this guidance in the guidelines. Something like, "The trail of breadcrumbs should not be repeated in the heading of the page."

I would push back on that proposal. Technically, it's the full page-name that is showing, and I think it would be very unwanted, to trim that in a majority of cases, as the full-name is often crucial context to read all at once.
E.g. https://meta.wikimedia.org/wiki/Tech/News/2024/50 should not just show "50" as the page-title, and https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Record_charts/Sourcing_guide/Japan should not just show "Japan" as the page-title, as those would be confusing for people who didn't notice/understand the breadcrumbs.

Workflow-wise, as an editor, I copy&paste full page-names from that <h1> location dozens of times every day. It's the easiest way to link to another page, especially if the page is on another wiki (and hence autocomplete link-wizards don't work). One existing alternative is to copy the text from the end of the URL, but then we're left with ugly_underscore_links that most people dislike reading and need to be manually removed.

It's also important to note that the default breadcrumb-trail only shows breadcrumbs for parent-pages which actually exist - it doesn't show unused gaps in the hierarchy. E.g. https://meta.wikimedia.org/wiki/Tech/News/2024/50 doesn't have a breadcrumb link for "2024" because that level of page doesn't exist and isn't wanted.
I hope that helps!

Thanks for sharing this context @Quiddity. This is really helpful information. I don't disagree with you at all. Maybe it's just a matter of how we define a difference in the example you gave, and the Wiktionary categories example from the task description. I imagine that one is also intentional to only have "Category:Monkeys" as the heading, and not listing every breadcrumb item before the current page. Knowing the how this differs from the example you gave would help us compose the correct guidance on this. Can you help us understand how these differ?

Yup! I would say there's a firm distinction between the pages which are using the default MediaWiki "subpages automatically create breadcrumbs" feature (documented at https://www.mediawiki.org/wiki/Help:Subpages), versus the custom examples at Wiktionary and Wikivoyage.
I.e. The results of this task might affect the former, but wouldn't touch the latter (unless those communities decided to update their templates as a result).

For example, the Wiktionary category-page (in the task Description) is just using a custom template to create those breadcrumb links. I.e. the only wikitext-page-content of https://en.wiktionary.org/wiki/Category:Monkeys is {{auto cat}}.
That template's documentation (https://en.wiktionary.org/wiki/Template:auto_cat) says "Most categories have an Edit category data button in the upper right that takes you directly to the module that implements the category."
If we click that button in the example category-page, it sends us to this Lua page (https://en.wiktionary.org/wiki/Module:category_tree/topic_cat/data/Animals#L-1) where they are manually defining the category-hierarchy that they want displayed in these breadcrumbs.

Similarly at Wikivoyage. They're using a complicated custom setup. It's documented at https://en.wikivoyage.org/wiki/Wikivoyage:Breadcrumb_navigation

In other words: Automatic Sub-page breadcrumbs, versus custom-template-based-breadcrumbs, are completely different use-cases, which coincidentally are all using a very similar UI at the moment. Overall, I believe they should become more distinct, not more similar.

Thanks for this additional context. Is there a specific piece of guidance around this topic that you would recommend, to ensure that headings on pages which might look like breadcrumbs but are not links, and breadcrumbs which are links and possibly repeating what is available in the header are not totally redundant? Or do you think that's just how it will need to work?

I think that's just how they need to work. I.e. Unfortunately, I suspect it's too complex (filled with edge-cases) to change anything significantly, for the default subpage-breadcrumbs feature.
The only design I can imagine (but not support!), that would both eliminate the duplication, and retain the important prominent contextual-clues (of the full page title displayed at top), and also support the copy&paste workflow, would be to split the <h1> header itself into separate parts and link the parts that exist.
But there are so many drawbacks and edge-cases to that idea that I imagine it would add just as many frustrations as it solved.
E.g. Would the headers then become partially Blue? (cf. https://www.mediawiki.org/wiki/User:Quiddity/Blue_link_color ) I.e. A page like https://meta.wikimedia.org/wiki/Tech/News/2024/50 could theoretically have a page-title that looks like "Tech/News/2024/50"
However that would be counter to the Manual of Style on Enwiki (and possibly/probably others?), that states: "Section headings should not themselves contain links; instead, a {{main}} or {{see also}} template should be placed immediately after the heading." -- and I expect changing the page-title headers like that would lead to a lot more newcomers creating links in sub-headings and then getting reverted.

One other important note: (Although this is based on fuzzy-memory and a few spot-checks of Special:Random and some Featured Pages at each English Sister project, so I might be missing examples) -- Subpages are almost never used directly in the Main-Content namespace at our wikis, except for at Wikibooks (example) and Wikiversity (example) which do often use subpages in mainspace. I.e. The only time that readers will commonly encounter breadcrumb links (aside from those 2 sister projects), are in "back-stage" pages, like WikiProjects, or at Meta-wiki & MediaWiki. In other words: I believe they are primarily used by editors.

Okay, thanks for this. So it sounds like we will just not write any guidance around the heading of the page, we will solely stick to guidance around the breadcrumbs, which may mimic the format of headings in a way.