Kibana: Breadcrumb taxonomy

[snide]

Core rules

Other notes:

• Flyouts, modals and tabs are not distinct pages.
• Sentence case. Only capitalize proper nouns after start of sentence

Breadcrumb examples for every app

Home

Home
Home / Add data
Home / Add data / APM
Home / Add data / Cloudwatch logs

Discover

Discover
Discover / Saved search name

Visualize

Visualize
Visualize / Create visualization
Visualize / Untitled visualization
Visualize / Visualization name
Visualize / Edit visualization name

Dashboard

Dashboard
Dashboard / Dashboard name
Dashboard / Editing dashboard name

Management

This section is under the assumption they break out of their tab system now and move to the side nav K7 stuff.

Management
Management / Security
Management / Index management
Management / Rollup jobs
Management / Rollup jobs / Create job
Management / Rollup jobs / Rollup job name
Management / License management / Update
Management / Watcher
Management / Watcher / Create watch
Management / Watcher / Watch name
Management / Index patterns
Management / Index patterns
Management / Index patterns / Index pattern name
Management / Index patterns / Create index pattern
Management / Spaces / Create
Management / Spaces / Space name
Management / Spaces / Advanced settings
Management / Reports
Management / Beats
Management / Beats / Enroll beat

Canvas

Canvas
Canvas / Workpad name

Monitoring

Monitoring
Monitoring / Clusters
Monitoring / Clusters / Cluster name
Monitoring / Clusters / Cluster name / Elasticsearch
Monitoring / Clusters / Cluster name / Kibana

[snide]

Hat tip to @cchaos who set this up with me

[snide]

cc @mattkime since it sounds like he's working through similar taxonomy stuff in the management nav stuff.

[spalger]

Thank you @cchaos and @snide, this is really helpful!

[mattapperson]

Should breadcrumbs work as a structural way? Or a flow based system?

Like in beats cm a user can get to the tag details screen from the tags list, or from the beat details screen. Should the breadcrumbs always follow the url structure in this case or the user flow?

[cchaos]

The breadcrumbs should follow the URL structure. Dynamically changing the breadcrumbs based on user path can get confusing if they can land on the same page different ways. It should be more of a description of the hierarchy of content than the user flow.

They can just use their browser's history stack for navigating their flow.

[spalger]

This section is under the assumption they break out of their tab system now and move to the side nav K7 stuff.

Since that's not something I'm planning on doing before working on the breadcrumbs for alpha2, do you think we should update the breadcrumbs for the Kibana management sections?

I do plan on filing an issue and maybe fixing the elasticsearch management sections to not include the disabled elasticsearch "page"

[spalger]

I'm thinking we should remove the Kibana breadcrumb and instead reuse the title from the tab bar as the last breadcrumb, except on sub-pages like "Edit Space" which should become the last breadcrumb instead of only existing within the tabs:

[cchaos]

I'm not sure it makes sense to duplicate the tab name in the breadcrumbs as it then breaks down that hierarchy. Instead, all "Space" pages should always have the "Space" tab in the selected state.

But a definite yes to removing "Kibana" and "Elasticsearch" from the breadcrumbs since these do not exist as actual pages.

[spalger]

Okay, sorry for all the noise, apparently @mattkime is working on the side nav stuff for Management

[jasonrhodes]

Hey friends, after hearing from @spalger in #25906, I've got some thoughts re: tabs and navigation.

In APM, we have a number of cases where tabs are represented in the actual URL path. For example, based on some work we just did, we have "/apm/services" and "/apm/traces" routes which each represent the same overall page, but with a different tab active (for linkability, back button preservation, etc).

Another case is on each service page, there are tabs for transaction types and for "Errors", like so:

Once you click on one of the individual errors on this tab, you go to that error page:

Without the "Errors" breadcrumb, you could only return back to the full service page which would default to a different tab, so in these cases I think representing the active tab state in the breadcrumb is a good thing. Thoughts?

_Sidenote: you could easily argue that these states shouldn't be tabs, but my understanding is that the single-depth Kibana navigation system doesn't give Kibana apps a ton of options when it comes to in-app navigation. Happy to hear other options._

[elasticmachine]

Pinging @elastic/kibana-design

[snide]

Sorry for the late response on this. I meant to throw something up earlier in the week. First, tabs are totally fine here. What we're trying to show though is that breadcrumbs aren't navigation, they are simply a method to backtrack through deep views. We don't think anything that is a sub page view of content should be represented there. Ultimately, people can get to the errors tab very easily by clicking on Opbeans-java and clicking through whatever navigation exists on that page. Routing can still exist however you want it, and have distict views, but as a rule that will work 99% of the time, only put distinct top level pages inside the breadcrumbs. The tabs are merely a filter of that page.

In contrast, the second screen, an error, IS a distinct view, one deep within Opbeans-java, but still its own thing, and should be the active breadcrumb.

Put another way. Breadcrumbs should represent each H1 you see as you navigate deeper into the content. It is the title of the page.

[jasonrhodes]

@snide that makes sense to me _mostly_, but as I understand it, Kibana doesn't give us a lot of options for in-app navigation, so I think tabs often become pages (not always). In our example, "Errors" is itself a distinct page that happens to share the kuery bar with a couple other pages, but there is definitely a distinct page hierarchy from Home > Service > [Section] > [Element] where "Section" could be Transactions, Errors, or Metrics and "Element" is an individual resource in a given section.

We can work around whatever you all think is best, but if we lose "Errors" from the breadcrumb, how do you suggest the breadcrumbs work when someone is on an individual error page inside of "opbeans-java"? From your screenshot edit, it looks like you would have them click back to the service level page, which would then auto-redirect to the first tab, which is "Transactions", which just seems like a pretty bad experience to us, especially since "/errors" is represented in the actual page path as a navigable location. Thoughts?

(My perspective has been that if your tabs push state onto the URL path, they are pages themselves so they deserve a breadcrumb.)

[snide]

I think there is always going to be outliers. I'll take a clear, consistent spec (page titles are breadcrumb taxonomy) any day. Usually if this doesn't work it's because of some problem with the inner navigation itself, not the breadcrumbs (which should never be primary nav of your app, but more of a "where am i?" in Kibana).

As a simple example, putting a "See all errors" link or something on your individual page under your title solves your problem, and makes it clear to the user that they are looking at a single item of a larger list. My guess is you'd have more context to pass there as well. Error 54 of 156...etc.

[jasonrhodes]

@snide yeah, I think I'm just confused why that clear, consistent spec wouldn't be "every segment of the current path that resolves to a real URL is a breadcrumb". I'll talk to Rasmus and the other APM folk about what they want to do here. Thanks!

[snide]

Closing out this issue. Thank you @spalger for doing the wrangling here.