Overview pages - UX and content

[Lukenickerson]

Given the current navigation, we're looking at having an overview page for each of the main sections -- Workloads, Services, Storage, Config -- as well as a main overview for the entire workspace. This issue is to discuss what content should be on each of these overviews, and how it should be displayed.

Initially I'm thinking the section overviews should have these goals:

• Alerts - What needs alerting + what action can be done to resolve the alert -- Inform the user of anything that is cause for concern and provide them with both a suggested course of action and the navigation to perform this action.
• History - What has changed -- Let the user know how the items have changed since the last time they checked or within the last day or two (precise timeframe TBD)
• Health Metrics -- Give the user some indication of the status of the items in the section (could be combined with the two above in some way)
• Navigation -- User should be able to get to the details of each of the items.
• Education -- We should help explain what each item is. It's important to consider the new user experience, and these overview pages are a good place to further explain some of the basic concepts.

The main overview could either have the same goals and content as the section overviews, or could have something different. (As an aside: Is there better wording for "main overview" and "section overview"?)

Regarding the UI and style, I think some obvious things to consider are:

• Card format - at least one card per section item
• Graphs / Visualization where it makes sense
• Real-time updates (have the data pushed to the front end)
• "As simple as possible, but no simpler." When providing lots of information in a single view there is fine line between providing a helpful summary and information overload.

There are many good examples of "dashboards": Datadog has some good examples (here, here), as does google cloud platform, google analytics, and many others.

[bryk]

Alerts - What needs alerting + what action can be done to resolve the alert -- Inform the user of anything that is cause for concern and provide them with both a suggested course of action and the navigation to perform this action.

I think this is not strictly alerts, but things that require your attention. Alert would be something that wakes you up at night. This may be "pod x is in a crash loop, fix this" or "node x cannot schedule any more pods".

History - What has changed -- Let the user know how the items have changed since the last time they checked or within the last day or two (precise timeframe TBD)

Yeah, like recent changes to all your workloads. This is super nice, but I'm worried that there's technical challenges with this. I.e., no one provides us a history of changes, so we'd have to architect it by ourselves. But this is to be researched.

Health Metrics -- Give the user some indication of the status of the items in the section (could be combined with the two above in some way)

Do you mean something like CPU usage or similar? @PiotrDabkowski works on this at the moment. The idea is to combine metrics like CPU/memory usage with events stream and display this on a single graph.

[bryk]

Navigation -- User should be able to get to the details of each of the items.
Education -- We should help explain what each item is. It's important to consider the new user experience, and these overview pages are a good place to further explain some of the basic concepts.

I agree with you here.

Do you have any proposal how section overview page would look like when incorporated all those five goals? You know how it looks now and you've probably seen the balsamiq wireframes. Can we work with @romlein here?

[bryk]

Card format - at least one card per section item

I think whether we use cards or not depends on the style we settle on in the nav discussions. Things can be here in cards and in "blocks" as on any other website.

[bryk]

@digitalfishpond @batikanu Any comments here?

[digitalfishpond]

As an aside: Is there better wording for "main overview" and "section overview"

Overview / Section Summary ?

[digitalfishpond]

I think this is not strictly alerts, but things that require your attention

Maintenance tips ?

[digitalfishpond]

Card format - at least one card per section item

Is it not feasible that a section item may be in a state where it has no cards yet? In that case maybe a place-holder card could mark the space, something saying "There are no ... in ... yet, create one" with a link to the relevant area of creation.

[batikanu]

Education -- We should help explain what each item is. It's important to consider the new user experience, and these overview pages are a good place to further explain some of the basic concepts.

Maybe short hover help text for each item which links to corresponding kubernetes documentation sections for more details.

[Lukenickerson]

Now that I think about it more I like the word "Notifications". Like Piotr says, they would be "things that require your attention" but don't necessarily keep you up at night. They could be analogous to Notifications in GitHub, Facebook, etc. I think there is considerable overlap between notifications, history, and health metrics so I'll have to give this more thought and see if Dan and I can get some mockups.

Regarding the history:

no one provides us a history of changes, so we'd have to architect it by ourselves. But this is to be researched

My initial thought is that this could be something that is better to have built into the core of Kubernetes, so that others (kubectl) can make use of the same APIs. @bryk What's the best way to figure this out?

For the health metrics, I was thinking more about individual numbers or statuses that would indicate whether a particular thing (e.g., pod, node) is "healthy" or "unhealthy". But we might be able to utilize some minimal graphs from #1010.

To some of the other points...

a place-holder card could mark the space, something saying "There are no ... in ... yet, create one" with a link to the relevant area of creation

👍 Yes, that sounds good for a zero state.

short hover help text for each item which links to corresponding kubernetes documentation sections for more details

👍 I like that!

[danielromlein]

I'm realizing we seem to have an 'overview overload' situation here:

• There's an Overview for the entire cluster
• Each main item like Workloads we've been referring to as an Overview, and...
• Based on the wireframes from UX and navigation that scales, each object (e.g. Pods) will have an Overview.

This many "Overviews" will confuse users, so I think we should reconsider information architecture, or at the least rename each to be unique.

[danielromlein]

Paper sketch in InVision of what a section (Workloads, in this case) could look like. Thoughts? Toggle on "Comments" to view a few notes I've left.

[maciaszczykm]

@romlein Hmm, I couldn't see any comments after turning them on... don't know why.

Regarding this view and card design - I think it may be a problem. Especially with this grid layout and two cards in a row. It can cause additional problems during implementation and I'm not sure if we will be able to put all data in shrunk cards. Otherwise it looks good. I like these two graphs in the top, but still I'm not sure what to put here.

[bryk]

@Lukenickerson

Now that I think about it more I like the word "Notifications". Like Piotr says, they would be "things that require your attention" but don't necessarily keep you up at night. They could be analogous to Notifications in GitHub, Facebook, etc. I think there is considerable overlap between notifications, history, and health metrics so I'll have to give this more thought and see if Dan and I can get some mockups.

Fully agree.

My initial thought is that this could be something that is better to have built into the core of Kubernetes, so that others (kubectl) can make use of the same APIs. @bryk What's the best way to figure this out?

Yes, we can (and should) build this into K8s core. But this is a quarter-long task, so we should do this only when we have all the basics.

[bryk]

@romlein

I'm realizing we seem to have an 'overview overload' situation here:
There's an Overview for the entire cluster
Each main item like Workloads we've been referring to as an Overview, and...
Based on the wireframes from UX and navigation that scales, each object (e.g. Pods) will have an Overview.
This many "Overviews" will confuse users, so I think we should reconsider information architecture, or at the least rename each to be unique.

I agree. I think that we can (and should) remove the Overview from resource detail page.

Regarding the pages pages like "Workloads", how about we call them "category pages"? What they really show is all your workloads/services/foos, which could be called "overview", but I think that there is no need.

Regarding cluster overview - this should be the overview.