[Infrastructure UI] Hosts: When linking to the individual host detail page, show breadcrumbs/back option

[formgeist]

Summary

Since we're utilizing the Inventory > Host detail page for showing the detail metrics breakdown for an individual host when clicked within the Hosts table, it would be good to have an option to go back to the Hosts view (that the user was previously on).

We need to implement the breadcrumb for the new Host Detail page. The old version looks like this:

Note that it always contains Inventory, even if the page was accessed from the Hosts View. Ideally, the breadcrumb should contain the actual page history.

Solution

If we don't manage to get the breadcrumb reflecting the previous pages and have the direct previous page fixed as Inventory, the EuiPageHeader supports a link option above the main page title as part of the page template. Link to docs. We can use this to provide an option back to Host for the user. We can also utilize this for any other links to the host detail page even from the Inventory, as it provides a clear option back. The link back will have to preserve the original URL and all its filter params.

Note: if the Host Details Page is accessed directly via link sharing, the breadcrumb will have a fixed Inventory.

✔️ Acceptance criteria

1. Must Have

Must be delivered in this issue in order for the release to be valuable

Name	Description	Notes
Host Details page should have proper breadcrumb	-
'Back' link should be presented which takes the users back to the exact URL they were previously on	-	Inventory UI <> Node Details, Metrics UI <> Node Details, Hosts View <> Node Details, APM Infrastructure tab <> Node Details

2. Should Have

Name	Description	Notes
-	-	-

3. Could Have

Would be nice to have but not critical

| Name | Description | Notes |

The breadcrumb reflect the actual page history	-

4. Will Not Have (for now)

Explicitly will not be looked at within this issue

Name	Description	Notes
-	-	-

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[formgeist]

@roshan-elastic FYI it would be great to add this in order to provide a better UX for the user when linking to the host detail page and back to the Hosts view.

[roshan-elastic]

100% @formgeist . This is one of the pet hates we get in the feedback from users (I'm sure you new this before I did :) ).

I'll start looking at the backlog for Hosts and perhaps set up a session to discuss what we'd like to put in there and how to prioritise.

[formgeist]

@roshan-elastic This is probably regarded as the short-term fix to eventually be able to provide the host details in a more contextual way wherever it may be needed. #120425

[roshan-elastic]

@formgeist - Completely agree with the goal of this ticket. Going to move this out of the backlog to 'no status' for now though as we need to think a bit about how this will work now that we're expanding asset views to be made available in more places in the UI:

• https://github.com/elastic/obs-infraobs-team/issues/1059
• https://github.com/elastic/obs-infraobs-team/issues/1060

For example, if someone accesses a full-screen asset detail view from outside of inventory or the hosts feature - we probably want to allow the user to access the a view of this asset in a place where they can see other assets like this (e.g. for the host detail view - we probably want to allow them to go through to the host feature but filtered by the current host)

Note : Everything we develop in the UI is going to ensure the URL returns you to the previous view exactly as it was (so clicking 'back' is now as feasible option for users). Not perfect I know. I'll work with @kkurstak to think about how the new full-screen detail view should handle navigation like this more gracefully.

[kkurstak]

Hi team,
Thank you @formgeist and @roshan-elastic for suggesting this. I'm fully on board with the idea.

About navigation -

As a way to strengthening the context of the user and providing him with even better navigation, I have also suggested in the new designs to include the change in the view on the left side navigation (this is a screenshot, as Figma is currently down):

What do you think about this? It would be a "shortcut" - only the currently visible host would be shown (instead of all hosts which would be the most "proper" way to present this - but of course with sometimes thousands of hosts, we cannot be listing them all in the nav.). It is connected to this issue, thus posting the comment here.

[formgeist]

@kkurstak We have previously explored adding the selected asset (service, alert, etc.) in other places, but it never seemed to make sense since it's temporary. To elaborate on your suggestion; does the shortcut persist if the user clicks on e.g. Services in APM in side navigation? Is it replaced if the user selected any other host or visits another host from a link in APM? Does the temporal nature of hosts make sense that they're selected in this way, or should we look to "select" an alert or similar that is the starting point of the investigation and keep context for the user on this? Perhaps some new concepts to be explored.

This proposal was mainly a low-effort way of introducing the same concept as in APM where the user can quickly navigate back to the list of hosts (with the previous query), as you might do in many other cases. Perhaps there are some other more integrated long-term solutions we can look at later on.

Thoughts?

[roshan-elastic]

How about a big 'back' button in Kibana? haha!

[kkurstak]

I've learnt yesterday that we're not able to nest items in the current navigation anyway, so it won't work in any case :) Thank you @formgeist for elaborating - I've never intended here to overwrite the original idea, just to add to the discussion.

I thought this would persist only while the user is active on the given host page. There's no way to show all hosts on the navigation, but this could be an additional indication of where am I, as a user, on the interface. The downside to it is that this information would be temporary and indeed it would make things more confusing - as you've kind of hinted. A history of "last visited" hosts would help, but that would require extra design work and probably an extra feature.

Let's stick to the original plan.

[roshan-elastic]

@formgeist / @kkurstak - love this. Prioritised this now as it nicely aligns with the below epic:

• https://github.com/elastic/obs-infraobs-team/issues/1060

Note for engineer, if we can do this before we update the host detail page as per the above epic - go ahead and pick it up. If it makes sense to wait, feel free to wait.

[crespocarlos]

We've replaced the old view. I've updated the ticket description to reflect the work that needs to be done for the new view.

[crespocarlos]

The current Node Details page breadcrumbs are fundamentally wrong

The page's route is not a child route from Inventory, but a sibling. This would make more sense - if we align routing with breadcrumbs

And it help a lot if we think about adding the return button, because the breadcrumb won't reference neither Host nor Inventory making it agnostic and more flexible

node_details_return.mov

We could even explore breadcrumbs like this:

`Observability > Infrastructure > ${assetType} > ${assetId}`

@roshan-elastic @formgeist @kkurstak @neptunian , wdyt?

1. Keep Observability > Infrastructure > Inventory > ${assetId}
2. Remove Inventory from it: Observability > Infrastructure > ${assetId}
3. Replace Inventory with assetType: Observability > Infrastructure > ${assetType} > ${assetId}

assetType won't be a link to Hosts, it's just to add more info to the breadcrumb.

I'd vote for either 2 or 3.

[roshan-elastic]

@crespocarlos - this is brilliant. Clear options and obviously easy to understand with your video!

I think the 'back' button really solves a lot of issues that the user is going to experience around navigation...assuming the user accesses an asset via either 'inventory' or 'hosts' it will easily get them back to where they went.

The one question I have is around how this might work if they are linked directly to a host from somewhere else?

Examples:

a. the APM Infrastructure Tab (example)
b. Being linked directly to a host from a bookmark or a URL?

For (a), if the user is sent back to the previous page - I think that works really well.

For (b), for some use cases perhaps the URL will know the previous page (based on whoever grabbed the URL and shared it)?

What do I think?

Long term, I'm thinking that (3) is the best option for the following reasons:

• If a user clicks 'back' and always gets back to the previous page, that makes investigative journeys very easy and seamless (I almost wish this was everywhere in Kibana)

• If the user is viewing an asset and wants to see the rest of them, they could potentially just click on the breadcrumb and get a to a 'list' of all of them? We haven't figured out any kind of categorisation system yet (other than the existing 'hosts', 'pods', 'containers' etc...) so maybe there is some risk to assuming we could do it like this...

Short-term, I'm thinking that (3) would still work well (for sure for 'hosts' if we could link back to 'hosts' if you clicked on the 'hosts' in the breadcrumb) but when we start upgrading other asset types (e.g. containers) - I'm wondering whether it still makes sense to show 'containers' in the breadcrumb (even if it's un-clickable). The risk I think here is that if someone ends up on a 'container' page from the APM Infrastructure tab and they want to see all containers...they won't have any easy way to get to 'inventory' to see them all.

@neptunian / @smith / @kkurstak what do you think? I feel like there's a trade-off in the short-term and I'd lean towards (3)...

[crespocarlos]

@roshan-elastic cool!

For (a), if the user is sent back to the previous page - I think that works really well.

The user will return to the previous page, in your example, APM.

For (b), for some use cases perhaps the URL will know the previous page (based on whoever grabbed the URL and shared it)?

Tested that too. In this case, I won't show the return button, because there will be nothing in the History stack to return the user to. Basically, I first check whether there are items in the history, if there is, there return button will appear, otherwise, it will be hidden. The return button, therefore, only appear if user is navigating from and to the Host Detail page.

The problem with returning to Hosts by clicking on the breadcrumb "Host" item is to persist/propagate the state, that's why the assetType is not a link . It's much easier to just redirect the user to the last item in the history stack, and by doing so, the URL state/querystring will be retrieved and the host view will load considering the filters previously set.

[roshan-elastic]

Ah I see @crespocarlos...

OK, I've pulled some telemetry on this and it looks like 22% of users use the 'inventory' breadcrumb on the host detail page:

last 30 days - 8.9 version data

However, I'm willing to bet my house on that users are just trying to get back to where they just were and that the 'back' button would actually be fine (I'm trying to figure this out in FullStory but I don't think the pathing is powerful enough to answer this question).

If I had to choose now, I'd go for #3 but I'll wait for Sandra/Nathan/Karolina to share their thoughts...

[neptunian]

The problem with returning to Hosts by clicking on the breadcrumb "Host" item is to persist/propagate the state, that's why the assetType is not a link .

@crespocarlos Are you saying that we would lose the Hosts state if we go from Hosts > Detail View > Click on Hosts breadcrumb link > Hosts? If coming from another app I would not expect state to be persisted but from within our own app, I would think we should be able to persist it.

@roshan-elastic If, from a product perspective, we want to commit to every asset type having a breadcrumb to its asset listing type no matter how they got to this asset detail view, then 3 would make sense. But since it sounds like we might not have a host listing in the future and just an inventory listing (https://github.com/elastic/obs-infraobs-team/issues/989), perhaps it makes sense to just leave as is (1) with every asset type returning to the inventory, ideally persisting state.

[crespocarlos]

@crespocarlos Are you saying that we would lose the Hosts state if we go from Hosts > Detail View > Click on Hosts breadcrumb link > Hosts? If coming from another app I would not expect state to be persisted but from within our own app, I would think we should be able to persist it.

@neptunian it's possible through a new context provider. Given the alternative of using the back button, it removes a lot of complexity and keeps basically the same functionality. Just thinking of how we can achieve the same, without adding too much complexity.

To do something like Host (link) > ${assetId} and Inventory (link) > ${assetId}, meaning that the breadcrumb would dynamically change based on which page the user came from, besides storing both Inventory and Host states, we would also have to know where the user came from by storing it or passing it somehow. Considering that it's a single route, same component, which is not under Inventory or Host.

Alternative 1 means that now the breadcrumbs would look like Observability > Infrastructure > Inventory > ${assetId}. If a user comes from Hosts View, they would see that breadcrumb with a back button, which is not entirely true in terms of navigation history. If the user comes from the Inventory UI, they would see the breadcrumbs and the back button. This seems more confusing IMO.

When everything points to Inventory, then we would still have the case where the user could come from the Hosts View, unless we're planning to drop it at some point. Inventory state I think it's already stored in a context provider, returning to it wouldn't be a problem.

[neptunian]

I am starting to lean toward 2. Right now we have more than one way within our own app to navigate to a detail view. We currently have a Hosts view which may not exist in the future and will just be an Asset inventory. Since having "asset type" as part of the breadcrumb won't really reflect navigation, it's probably best to leave it off. We can rethink it later.

[roshan-elastic]

@roshan-elastic If, from a product perspective, we want to commit to every asset type having a breadcrumb to its asset listing type no matter how they got to this asset detail view, then 3 would make sense. But since it sounds like we might not have a host listing in the future and just an inventory listing (https://github.com/elastic/obs-infraobs-team/issues/989), perhaps it makes sense to just leave as is (1) with every asset type returning to the inventory, ideally persisting state.

Thanks for the thought process and input here @neptunian - let's go with your suggestion of (2) here!

FYI @crespocarlos