Dashboard: Left-hand Navigation

[danielromlein]

Based on wireframes in the design doc UX and navigation that scales, the current hierarchy of sidebar nav content is:

• Overview – High level dashboard of the cluster.
• Workloads – Shows replica sets, replication controllers, jobs, daemon sets, pods, etc.
• Services – Shows services, ingresses, etc.
• Configuration – namespaces, volumes, secrets, resource quotas, etc.

Issue goal

Reach an agreed-upon hierarchy we can use to execute high-fidelity mockups.

Questions

• Are the top-level navigation items listed above the most useful ones for users?
• What sub-categories should be included in each?

[Lukenickerson]

From the mockups in that link it looks like we'll need three levels of navigation using the "Nested side nav" + tabs pattern, so we'll need a hierarchy three levels deep.

Another open question to add: Do we want to also consider navigation based on roles and top tasks? If so we can start with...

Identify your app’s users and their potential roles, such as consumer, business owner, or journalist. Identify the most common tasks they may want to perform.

[floreks]

Here is an issue created to clarify k8s documentation and our menu that will be in sync with it. It's a bit stale but we should post any ideas there. We've agreed already on most parts of menu, but there are still some open points.

[pwittrock]

@johndmulhausen Can you make sure this is up to date. I think we added Cluster and ObjectMetadata sections.

[bryk]

From the mockups in that link it looks like we'll need three levels of navigation using the "Nested side nav" + tabs pattern, so we'll need a hierarchy three levels deep.

This was in initial proposal and can be changed. We look for you creativity here to explore better approaches if you see them :)

And yes, if we stay with this proposal, we need three levels of navigation, which is two-level menu and tabs.

[bryk]

Based on wireframes in the design doc UX and navigation that scales, the current hierarchy of sidebar nav content is: (...)

I think most up to date version is in https://github.com/kubernetes/kubernetes/issues/22687

[bryk]

Are the top-level navigation items listed above the most useful ones for users?

This is a very good question that we've been asking ourselves a lot :) In the proposal in kubernetes/kubernetes#22687 we've grouped resources into use-case driven categories. E.g., "I want to run an app" -> workloads, "I want to configure my app" -> config, "I want to play with the cluster itself" -> cluster, etc. This was based on our experience and user feedback.
So, we can have an answer to this question when we do a research, ship it and get feedback or have additional data points.

Can you suggest any changes?

[danielromlein]

@bryk

Can you suggest any changes?

Still researching and learning so I can make more informed contributions to this based on user flows – if any promising alternative structures emerge I will definitely share! 😊 For now: is there an agreed upon tighter Dashboard hierarchy I can work with for the lefthand nav? There's a discrepancy between @maciaszczykm's comment with the most recent Current State and @pwittrock's proposal of how to subdivide workloads into Continuous Workloads and Run To Completion Workloads.

Also @pwittrock, you mentioned:

Some of these are categorized for the docs now (Labels, Horizontal Pod Autoscalers)

And that others had been fit into existing top level categories. Are those decisions documented somewhere so that I could compile the most recent set of relationships?

cc @Lukenickerson

[bryk]

We've got this from @maciaszczykm proposal:

• Cluster - nodes, namespaces and persistent volumes.
• Workloads - pods, replica sets, replication controllers, jobs, deployments, daemon sets, pet sets, workflows and scheduled jobs.
• Service discovery and load balancing - services and ingresses.
• Storage - persistent volume claims.
• Config - secrets and config maps.
• Policies - resource quotas, limit ranges and pod security policies.

Then @pwittrock and @bgrant0607 propose to split Workloads into Continous workloads and Run to completion workloads.

I'm OKay with this, but when this is not a separate top-level menu item or next level in navigation. This could be just visual separation in a list of menu items, e.g.,:

However, at the end, I wouldn't differentiate this in the menu. We could emphasize this in the pages that deal with batch/continuous resources. But to me this is not a thing you need in the menu.

What do you think?

@janetkuo

[bryk]

For now: is there an agreed upon tighter Dashboard hierarchy I can work with for the lefthand nav?

Go with @maciaszczykm proposal. We should talk about the order, though. And maybe non-functional menu items like "Overview" or "Settings".

[danielromlein]

visual separation in a list of menu items

That makes sense. Do you envision _Continuous_ and _Batch_ links to pages, or strictly as labels for chunks of different workload types in the navigation?

We should talk about the order, though.

Agreed 👍 Prioritization relates back to what @Lukenickerson mentioned regarding identifying most common tasks.

[janetkuo]

I'm OKay with this, but when this is not a separate top-level menu item or next level in navigation. This could be just visual separation in a list of menu items.
However, at the end, I wouldn't differentiate this in the menu.

Can you elaborate more on this? A visual separation for continuous vs. batch inside workloads sounds good to me. Users wouldn't need to click on each workload page to see that.

[pwittrock]

Visual separation makes sense to me as well. I don't think we have enough batch or continuous workloads to warrant separate menu items.

[bryk]

Can you elaborate more on this? A visual separation for continuous vs. batch inside workloads sounds good to me. Users wouldn't need to click on each workload page to see that.

@janetkuo Yeah, I was bit unclear. I would just group batch/continuous workloads in one menu item (with some visual distinction, see my previous mock). I agree with @pwittrock that a separate menu item is not needed.

[bryk]

Agreed :+1: Prioritization relates back to what @Lukenickerson mentioned regarding identifying most common tasks.

@romlein We've had this list for our initial version, but now it is (and will be) broader. I'll gather the team, do brainstorming and propose a list of user stories here.

[danielromlein]

@bryk Where would _Pods_ land in the _Continuous_ / _Batch_ separation? @pwittrock mentioned that that still needs a home...?

[bryk]

@romlein Sorry for not responding. We've met with folks but didn't decide who responds... :) Mistake.

We had a couple of ideas on how to sort the menu. We've settled on the one that puts most commonly visited items at the top and separates ops/dev use cases.

We identified that most often people look at is "Workloads". This is essentially the place where all things running on the claster are. So this goes first. Then there is "Services". Services are directly related to workloads (used to expose them) and used whenever you need to access things running in a cluster. Then we have Sorage, Config and Policies. Finally we end with "Cluster" which is often used by cluster ops or rarely by app dev/ops.

Add to this "Overview" at the top with overview of your _everyting_ and "Settings" at the bottom with user info, preferences, etc.

This boils down to: Overview, Workloads, Services, Storage, Config, Policies, Settings.

What do you think? Does this help?

[danielromlein]

That sounds good @bryk – thank you! I've put together a Google Drawing laying out the Dashboard navigation hierarchy. Please comment with any suggested revisions! I'm adding a few questions of my own.

@bryk: those core categories of _Overview, Workloads, Services, Storage, Config, and Policies_ should be accessible regardless of whether or not a user has an individual _Namespace_, _Node_, or _Persistent Volume_ selected, correct?

cc @Lukenickerson @bgrant0607

[bgrant0607]

@romlein Most users should look at namespaced objects rather than nodes or volumes. The latter are more a matter of concern for cluster administrators, and maybe for debugging in some scenarios.

In kubectl, the selected namespace is recorded in the context in kubeconfig. The default uses the "default" namespace. I'd do similarly in the UI.

[bryk]

@bryk: those core categories of Overview, Workloads, Services, Storage, Config, and Policies should be accessible regardless of whether or not a user has an individual Namespace, Node, or Persistent Volume selected, correct?

Namespaces are like "projects". All things in Overview, Workloads, Services, Storage, Config, and Policies categories are in a namespace. This means that a user can select a namespace ("project") to see only resources belonging to it. Also, the user can select "all namespaces" to see resources from all of them.

Nodes and Persistent Volumes are just global objects. You do not select them. But they do not belong to a namespace, but directly to the cluster. Note that you can get from a Node to, e.g., a Pod (that is in a namespace). So namespaced objects can link to global ones, and vice versa.

[danielromlein]

@bgrant0607 excellent! Thank you. That informs our discussion of User Types and who precisely we want to optimize this navigation _for_.

@bryk that description of namespaces helps a lot – thanks! A few follow-up questions:

1. Is there also the need to have users view and manage the namespaces _themselves_, or are namespaces strictly a means of filtering which objects a user is viewing?
2. Are namespaces the _only_ means by which a user will filter services?

Nodes and Persistent Volumes are just global objects. You do not select them.

1. In what ways _does_ a user need to interact with Nodes and Persistent Volumes (and Namespaces, depending on the answer to #1)?

This InVision prototype is still imperfect, but I think it's starting to get closer to the notion of service filtering + global objects. cc @janetkuo @pwittrock

Comments from any and all are welcome on the InVision mockup! At this point we're still figuring out information architecture, so discussions around look-and-feel are probably best left till further down the road, but these are fairly high-fidelity.

[bryk]

Is there also the need to have users view and manage the namespaces themselves, or are namespaces strictly a means of filtering which objects a user is viewing?

Namespaces are objects. You can create, delete, update them. What's more, namespaces can have resource constraints or policies. So, a cluster operator would definitely like to see a namespace and change its policy.

Are namespaces the only means by which a user will filter services?

Yes.

In what ways does a user need to interact with Nodes and Persistent Volumes (and Namespaces, depending on the answer to #1)?

When I'm cluster ops and I want to see all Nodes. See which are healthy and which are not. See their resource usage. I want to be able to drill down into details and see what pods are running on a node.
Persistent Volumes: As a cluster ops/admin I want to see all persistent volumes and create/read/update/delete them. I also want to see who uses the volumes (nice documentation: http://kubernetes.io/docs/user-guide/persistent-volumes/).

[danielromlein]

RE: @janetkuo's comment on the InVision Mockup:

Put higher-level controllers (i.e. Deployments and Pet Sets) first, lower-level controllers later.

Is there a better, more prioritized ordering for the workloads objects?

Currently we have:

_Continuous_

• Pods
• Replication controllers
• Replica Sets
• Deployments
• Daemon Sets
• Pet Sets

_Batch_

• Jobs
• Scheduled jobs
• Workflow

Also @janetkuo you mentioned Horizontal Pod Autoscaling – I don't know whether or not we're including that in the UI. @bryk?

[danielromlein]

I've updated the Google Drawing diagramming the hierarchy of various objects. Let me know if this makes sense to folks.

[bryk]

@romlein @janetkuo Re Horizontal Pod Autoscalers: we'll not show HPAs as a separate list of things, but only as a characteristics of Deployments or RCs. We've identified that it makes little sense to say "please show me all my HPAs", even though API supports it. It is better to just see your applications and then drill down to their HPAs.

Does this make sense?

[bryk]

Re order: Thats correct. Let's do proper ordering of continous workloads. Start from the bottom. So I propose that Pods go last. They are the smallest unit of workload and are created by everything else. Then we have RCs. RCs are the oldest of controllers and it is not advised to use them anymore. Then repica sets, as they are very similar to RCs. Then daemon sets and pet sets. Finally Deployments, as they are the highest level of workload. This boils down to:

• Deployment
• Pet Set
• Daemon Set
• Replica Set
• Replication Controller
• Pod

Batch: I'd start with workflows, then jobs, then scheduled jobs.

What do you think?

[danielromlein]

Updated InVision prototype. Click "All Namespaces" to see what that dropdown would look like; click "Services" to see the interaction of switching to another top-level menu item. It's not included yet, but clicking the "down" chevron on the right of a menu item would expand to show its contents.

[danielromlein]

What do people think about the sidenav being permanent (shown all the time) vs. persistent (shown in conjunction with a hamburger icon so it can be hidden?

[maciaszczykm]

@romlein IMO there should be possibility to hide sidenav.

[bryk]

I think it all boils down to responsiveness. On large desktops we could make it visible all the time, but when we consider other form factors, we need to have a way to hide the menu under a hamburger menu (or in some other way).

Our target form factors are:

• large desktops and 13'+ laptops - full support, we thrive to have best possible experience here
• less than 13' and tablets - the UI should work nice here, possibly with a couple of glithes
• mobiles - should be usable, but may not feel as mobile-native app. All the functionality should be reachable.

[danielromlein]

Good to know! I'll incorporate the hamburger icon into the mockups then.

[danielromlein]

I've updated the InVision Prototype with a few variations based on the most recent round of feedback. As a permanently visible navigation is the Material spec recommended default for desktop, I think maybe it makes sense just to offer the option to hide the side-nav at smaller viewport widths, but I've included the hamburger icon in these to show what that would look like.

All these are designed as if the user had selected Cluster Operator as their role. Application Developer would be minus the global objects of _Namespaces, Nodes, & Persistent Volumes_. Interested to hear people's thoughts on whether to put these above or below the namespaced objects...?

[Lukenickerson]

The mock ups are looking good!

I'm a fan of a few aspects of the current keep.google.com side menu...

At widths less than 1035px:

• hamburger button opens the menu
• the side bar menu overlaps the left side of the screen
• side bar menu is closed by clicking outside the menu or making a selection (one thing I would consider changing is having a hamburger button to use as a toggle for the menu)

At larger widths:

• side menu is shown on the left side (by being colored the same as the background, it is unobtrusive and does not demand the user's focus)
• hamburger button opens and closes the side menu (sliding in/out from the left)

For dashboard's responsive design, will this be based on _pixel_ dimensions?

Regarding the order: Makes sense that the order of menu items is driven in part by the tasks the type of user is trying to accomplish, i.e. issue 975.

[bryk]

Interested to hear people's thoughts on whether to put these above or below the namespaced objects...?

If the user proactively selected the "Cluster Admin" role, I'd move this to the top, because it is likely that they'll actually do something with the cluster.

[bryk]

For dashboard's responsive design, will this be based on pixel dimensions?

Yes. See material spec break points: https://material.angularjs.org/latest/layout/introduction

[bryk]

Regarding the order: Makes sense that the order of menu items is driven in part by the tasks the type of user is trying to accomplish, i.e. issue 975.

I think this is what we actually did. See one of my previous comments: https://github.com/kubernetes/dashboard/issues/908#issuecomment-229022892

[danielromlein]

In the InVision prototype I've updated both the version based on @Lukenickerson's preference for a Keep -esque sidenav (increased padding on secondary nav items), as well as @floreks's and @bryk's preference of the full-height sidebar. I've also added a version of the full-height sidebar at a width of 1024px to show what it would look like with the option to collapse the side nav.
_Note_: Material_ spec discourages using a persistent side-nav (i.e. one that can be collapsed) in apps with multiple levels of hierarchy that use an up arrow, so that is something to keep in mind. If we planning on using that up arrow / breadcrumb pattern it might make the full-width header a better choice.

[marians]

My 2ct regarding allowing the user to hide the side nav when in "full width": To me it comes down to the usage of the right side panels. I can imagine content there that would benefit from a maximum viewport width, for example: logs. So that's a +1 for allowing the user to hide the nav, even on the widest possible screen.

[bryk]

If we planning on using that up arrow / breadcrumb pattern it might make the full-width header a better choice.

We currently have breadcrumbs and arrow-navigation in the actionbar mainly because of lack of the proper app menu. Once we have the left-nav, we can remove all the nav from actionbar. What do you think?

[bryk]

Re "Policies" menu item: my proposal is that we remove this menu item and fold resource quotas and limit ranges to just properties of a namespace. The reason is that a namespace can have up to one quota/limit range and it makes little sense to look at those resources in isolation. Hence, if we say that those two resources are just properties of a namespace, this should be a better UX. See docs: http://kubernetes.io/docs/admin/resourcequota/walkthrough/

Then there is Pod Security Policy: According to the design doc it is a global object for administrators only. This means that we should move it alongside Nodes and Namespaces.

@romlein @floreks

[bryk]

In the InVision prototype I've updated both the version based on @Lukenickerson's preference for a Keep -esque sidenav (increased padding on secondary nav items), as well as @floreks's and @bryk's preference of the full-height sidebar. I've also added a version of the full-height sidebar at a width of 1024px to show what it would look like with the option to collapse the side nav.

This is two nice proposals and I think we should add some more fidelity to them and settle on final solutions. @romlein Is there anything you need to move this forward?

[danielromlein]

@bryk

add some more fidelity

Great! In the prototype I'll remove _Policies_ as a menu item, add hover states, link a few menu items, and include the namespace dropdown on those two design options so we can better assess.

I'm a little unclear on the ramifications of removing _Policies_ as a menu item: will _Resource Quotas_ and _Limit Ranges_ need to be moved to children of the _Namespace_ nav item?

And just to confirm: _Pod Security Policies_ then will live alongside _Nodes, Namespaces, and Persistent Volumes_?

[bryk]

I'm a little unclear on the ramifications of removing Policies as a menu item: will Resource Quotas and Limit Ranges need to be moved to children of the Namespace nav item?

I'd say: no. All we should do is: when you look at a namespace you can CRUD its resource quota.

And just to confirm: Pod Security Policies then will live alongside Nodes, Namespaces, and Persistent Volumes?

Yep. But I've just checked out and this is going to be in beta no sooner than a quarter from now.

[danielromlein]

@bryk Ok, good to know!

Once we have the left-nav, we can remove all the nav from actionbar.

I think that sounds reasonable, but I don't have a great handle on how those finer levels of navigation need to behave. Are there any further levels of navigation that it would be helpful to incorporate a breadcrumb for, or do you see abandoning the breadcrumb pattern altogether?

I just created Action Bar #1015 to capture specs around designing the action bar.

And thanks for the feedback @marians and @bryk – I've incorporated the ability to hide the side-nav even at widest browser widths.

[bryk]

Are there any further levels of navigation that it would be helpful to incorporate a breadcrumb for, or do you see abandoning the breadcrumb pattern altogether?

I could imagine that we could use breadcrumbs to show your history path (e.g., your path like "Node x" > "Pod y" -> "RC z"), but I doubt this is any more useful than just showing relationship links in the content of a page.
So I say, we don't need breadcrumbs when we have the menu. We should show page title or resource name in the actionbar, though. @floreks

[danielromlein]

A question in my mind still is what would be shown when a user clicks on, say, _Services_, rather than one of the children of _Services_...? On that menu item -level overview, what would we be including?

[floreks]

I could imagine that we could use breadcrumbs to show your history path (e.g., your path like "Node x" > "Pod y" -> "RC z"), but I doubt this is any more useful than just showing relationship links in the content of a page.
So I say, we don't need breadcrumbs when we have the menu. We should show page title or resource name in the actionbar, though.

A little late, but I agree. With sidenav added we could get rid of link to parent view as it will be already available in navigation menu. We can just limit to 1 part and show name of resource/state.

A question in my mind still is what would be shown when a user clicks on, say, Services, rather than one of the children of Services...? On that menu item -level overview, what would we be including?

Good question. I'm not sure here. Maybe we can just make it available to click on top level Services to see all services list and if we expand it then Ingress option will be available.

Any thoughts? @bryk @romlein

[bryk]

A question in my mind still is what would be shown when a user clicks on, say, Services, rather than one of the children of Services...? On that menu item -level overview, what would we be including?

Services page will show Services and Ingresses. Workloads page will show RCs, RSes, Deployments, Jobs, Pods, etc. Lists of resources + some aggregate info/actions

[danielromlein]

I updated the Dashboard nav mockup to include the action bar – split between local and global actions.

[danielromlein]

Thinking more about the side nav and having those menu items collapsible, I wonder if possibly it would make more sense to keep them all permanently expanded? This prototype shows what that would look like.
@bryk do I have the menu secondary items correctly split up?

[bryk]

This is a nice idea. Looks and feels nice. The menu is small enough that we can afford this, I guess.

[bryk]

I updated the Dashboard nav mockup to include the action bar – split between local and global actions.

I looked at it and I love the design! The idea of moving YAML upload and app deploy buttons made stuff much cleared. I.e., the action bar is for the thing you're looking at and the top bar is for global actions. Neat.

[danielromlein]

@bryk OK cool. I'll increase the fidelity of each of those prototypes, but will keep the old versions around for reference.
That "Services" appears duplicated bothers me – any suggestions for how we could change that?

[Lukenickerson]

If we're considering an always-open style for the navigation items, and possibly using icons, then it might make sense to go with a grouping more in line with the material design spec -- with subheaders and dividers for the sections. (I like how inbox.google.com implements this, aside from all the colored icons.) The subheaders could be: Continuous Workloads, Batch Workloads, Services, Storage, Config.

[danielromlein]

I like that idea @Lukenickerson. The spec doesn't have subheaders as clickable, so we'd have to decide if we need those top-level overview pages.
/ @floreks @bryk

[danielromlein]

Also, while this likely isn't a very important factor given our desktop focus, another pro of the always-open nav is it would be easier to interact with on mobile. Users wouldn't have to worry about tapping the expand vs. title.

[danielromlein]

Here is a prototype of the latest options we're considering.

[maciaszczykm]

Considering five options presented in @romlein's last comment I like the last one the most:

It looks really good. I'm wondering if there is a need to split workloads into two categories in the menu. Not sure about it. Also icons can be added here.

[floreks]

This is my favourite option also. Matches inbox style :) One thing that I'm not sure about is hamburger menu icon next to logo and kubernetes text. It looks a bit condensed.

[bryk]

@floreks @maciaszczykm This approach requires us to have information layout that is card-based (as in Keep or Inbox). I'm kind of worried about implications of this. When you look at material spec, all desktop examples there use full overlay navigation drawer. But I can be convinced if the issues are resolved.

[maciaszczykm]

@bryk That's true. My opinion was based on look and feel, but if we want to follow Material specs then it might be difficult to implement it. Some issues may occur while implementing something, that does not exactly match spec...

All other designs looks also good, but this one is my favorite.

[floreks]

@bryk We're kind of using card-based layout right now, don't we? We have card lists and card info. They have only bottom padding that's why they do not look exactly like cards, however they are scaling nicely to available space.

I don't see any major engineering differences between both options. Both can be hidden and all space can be used. Just UX part is different.

[danielromlein]

Updated prototype based on our SIG-UI conversation this morning.

[maciaszczykm]

I like 6th one the most this time, 3rd is also good (only difference is a header I guess). Icons and indents at the same time look strange. For workloads I prefer gear icon.

It's good, that we have so many good-looking options to choose :blush:

[pwittrock]

A few comments on the left hand nav:

• DaemonSets will mostly be used by cluster admin, and are about scheduling Pods to specific Nodes. For non-admins they should not be given prime real estate
• Deployments, ReplicaSets and ReplicationControllers are pretty tightly coupled and cover the same use case. ReplicaSets generally should not be created directly (Deployments create them), and ReplicationControllers should really just be there for legacy reasons. Suggested ordering: Deployments, ReplicationControllers, ReplicaSets

Also, IMHO I prefer the expanded look nav

[danielromlein]

@lukenickerson and I are proposing this navigation design (two variations included), featuring:

• Full-width header, which
  
  
  
  • Is more consistent with other Google products than the full-height side bar.
  
  
  • Elevates the header content above body content, and allows us to put side nav on the same elevation (or below) body content.
  
  
  • Makes _content_ the primary focus of a user’s attention.
  
  
• Shaded navigation background
  
  
  
  • Google Cloud Platform designer Keith Guerin brought up the point that if the side nav background is pure white, that ‘uses up’ a lot of available value spectrum, thereby robbing other content of prioritization through value. The gray-tinted side nav background to either of these options affords us the opportunity to use bright white as the background for areas of the page where we most want to draw users’ attention.
  
  
• Permanently expanded navigation items
  
  
  
  • Collapsible navigation items introduce extra clicks, and also present a challenge for navigating to top-level views (e.g. _Workloads_) that represent an overview for a given category. By keeping everything expanded, we give users a chance to context for what they have to work with. If – after user testing or introduction of more nav items – we decide collapsible nav items would improve UX we could always introduce that later.
  
  

There are two variations here depending on whether or not we would like to pursue a card-based layout.

Thoughts?

_Note: icons used in this design are subject to change as we explore the best representative visualizations for concepts._

[maciaszczykm]

@romlein Personally I prefer second one, but both look good. Icons also look better.

One question about second variant - what top-left corner button would do? Can menu be hidden in this variant? If not we should use Kubernetes logo, or Dashboard logo (if we'll have one in the future).

[danielromlein]

@maciaszczykm the top left menu icon would hide the side nav. Previously we had the Kubernetes heptagon logo _and_ menu icon, but after researching Google products, we found that pattern's not used: having both forms next to each other is too confusing.

[danielromlein]

Updates to the InVision Prototype based on our conversations with Keith Guerin and Greg Bumpus of Google Cloud Platform.

Changes:

• Added a label to the selected namespace, to both help new users and draw more attention to it.
• Added a section label of "Admin" to top-level items to add some sense of grouping to those.
• Added the title of a given page for clarity.
• Made the action bar area sticky, so it will go over content when a user has to scroll down the page.
• Added a label of "Admin" next to the profile icon. We decided this would be helpful for those use cases where a user is switching between Admin and Developer (in, say, a small company).

All decisions are open for critique! Please comment on the InVision prototype with any feedback.

We're still trying to evaluate whether or not cards are the best route for displaying content. Thoughts?

[maciaszczykm]

• Added a section label of "Admin" to top-level items to add some sense of grouping to those.

@romlein What about making this label more descriptive? Admin seems like shortcut, I'd use full name, i.e. Cluster Administration.

[maciaszczykm]

@romlein I'm wondering if it would be possible to reduce borders number on the page. I think too many borders can make app look old. That's why I like 2nd and 5th options, however I know, that it would be hard to use them (scrolling etc.).

We should also avoid using 4 kinds of font in the main toolbar. Maybe we don't need all of those labels?

Left-hand menu looks good. Really good job!

[danielromlein]

@maciaszczykm "Cluster Administration" seems needlessly lengthy to communicate the same thing as the concise "Admin", but I'm open to being persuaded otherwise.

I think borders in these context serve a valuable function of separating up content on the page. More minimal apps like _Keep_ can get away without using as many dividing lines, but given the information density of this product I think they make sense to incorporate.

Agreed that four fonts in the side nav might be a bit much, but I think the uniqueness is still at the point of being more useful than it is disorienting. Having the namespace as Roboto monospace helps set it apart from the rest of the nav.

Thoughts?

[danielromlein]

Here is a version of the side nav that incorporates numbers after each primary nav item to indicate how many _things_ are in each. (These could also follow _every_ nav item). These numbers would change with changing a namespace, and thereby serve as an indication to users that changing the namespace is filtering those objects.
The downside is, of course, that they make the design busier.

[maciaszczykm]

@maciaszczykm "Cluster Administration" seems needlessly lengthy to communicate the same thing as the concise "Admin", but I'm open to being persuaded otherwise.

@romlein It's just my feeling. In my opinion full name looks better, but it's not so important. What about margins here? Space between Admin label and Namespaces entry is smaller than between other menu entries.

I think borders in these context serve a valuable function of separating up content on the page. More minimal apps like Keep can get away without using as many dividing lines, but given the information density of this product I think they make sense to incorporate.

Agreed. If we cannot reduce number of them, let's leave it like it is.

Agreed that four fonts in the side nav might be a bit much, but I think the uniqueness is still at the point of being more useful than it is disorienting. Having the namespace as Roboto monospace helps set it apart from the rest of the nav.

In side nav it looks fine :) I was talking about main navigation bar on the top of the page (blue one).

[danielromlein]

@maciaszczykm was hoping I'd catch you today at the SIG UI, but here'll have to do 😊

Space between Admin label and Namespaces entry is smaller than between other menu entries.

That's to intentionally relate them to the content they're describing – otherwise a user might wonder if they're menu items of their own. I can ask some Google designers more experienced with Material on this one, but I think they'll agree.

In side nav it looks fine :) I was talking about main navigation bar on the top of the page (blue one).

Ah ok: sorry I misunderstood. I don't think that stands out as too diverse to me? Looking at other Google products, it's fairly common to have different styles represented based on the needs of the functionality brought together. I'll ask about this as well though.

Thanks for the input!

[maciaszczykm]

@maciaszczykm was hoping I'd catch you today at the SIG UI, but here'll have to do :blush:

Sorry, couldn't make it yesterday.

That's to intentionally relate them to the content they're describing – otherwise a user might wonder if they're menu items of their own. I can ask some Google designers more experienced with Material on this one, but I think they'll agree.

Yeah, it's good idea to ask them. If they agree, then forget about my remarks :)

Ah ok: sorry I misunderstood. I don't think that stands out as too diverse to me? Looking at other Google products, it's fairly common to have different styles represented based on the needs of the functionality brought together. I'll ask about this as well though.

Thanks for the input!

Sure, no problem.

[danielromlein]

Looking ahead to other levels of navigation, UX and navigation that scales incorporates tabs to display _Overview, Events, Logs,_ and _Exec_ – are those still pages we would like to expose to users? "Exec" seems like a confusing name: what would that comprise? Might it be better placed in _user settings_?

[maciaszczykm]

Looking ahead to other levels of navigation, UX and navigation that scales incorporates tabs to display Overview, Events, Logs, and Exec – are those still pages we would like to expose to users?

Yeah, we want to have these information in this view. Overview is just resource details. Events and logs tabs will list all events and connected to the resource.

"Exec" seems like a confusing name: what would that comprise?

Exec (name still to be discussed I suppose) will give an access to pod console in that case (it's pod details page draft).

We can swtich from tabs into one page, but that should be discussed here. Why it's better from UX perspective?

Might it be better placed in user settings?

These tabs are designed to be displayed only on resource details views. They will be different for different resources. Every pod will have same tab-set, but a replica set can have different tabs.

Let me know if my explanation is not clear, I'll describe it better or we can setup a call :)

[bryk]

I've left some comments in the Invision project, but I have a general question. Are we happy with the general concept of the left hand side menu from here? I think we've been all agreeing on the left nav and now the discussion drifts into the actionbar and page content areas.

I'm asking this because it is right time to start implementation work to have it ready for the next release.

[maciaszczykm]

@bryk I like this version overall, but I'm still a little bit concerned about section labels there. First two sections have labels, Admin, Namespace, but third one has not. I understand why, but it looks a little bit inconsistent to me.

Plus my previous two comments. @romlein will talk (or already did?) about them with Google UX team.

[danielromlein]

@bryk

Are we happy with the general concept of the left hand side menu from here.

I think the side-nav is basically between that – with the content background all a lighter color – and the cards version. I'll try to pull together as many pros / cons as I can for the SIG UI meeting Wednesday and let's plan to make a decision 😎

I noticed your InVision conversation with Keith Guerin today, and I like his idea of responsive tables that compress space, then drop columns and just list items with the addition of another level for details. Interested to hear your thoughts.

@maciaszczykm Keith Guerin and Greg Bumpus (both of Google Cloud Platform) have been our go-to advisors / critique-providers for this. They agree with the basic side nav format we have currently, and think the tabs format for further levels of navigation is a good option. Beyond that I think our specific use case decides the relative successfulness of one solution over another.

@romlein will talk (or already did?) about [spacing of labels from content and number of font styles used in header nav] with Google UX team.

They agreed with both these current designs. They did suggest perhaps changing the _Namespace_ font so that didn't introduce another style to the side nav, but agreed that it had value in drawing attention to the Namespace.

[bryk]

@romlein

I think the side-nav is basically between that – with the content background all a lighter color – and the cards version. I'll try to pull together as many pros / cons as I can for the SIG UI meeting Wednesday and let's plan to make a decision :sunglasses:

Awesome. Looking forward to start work on this. Btw, @Lukenickerson you said that that you like frontend work. Can you collaborate with me or work on the left nav? This is pure frontend work.

[bryk]

I noticed your InVision conversation with Keith Guerin today, and I like his idea of responsive tables that compress space, then drop columns and just list items with the addition of another level for details. Interested to hear your thoughts.

Currently the columns shrink, so are at least decently responsive. In the past we had the pivot-table-into-list solution, but dropped it due to technical reasons. Now we have a technical foundation to make all tables in the project responsive (to pivot into lists). We didn't want to dig into implementation of this before having real design of the contents of pages.

[danielromlein]

Updated side nav in InVision refining the cards styling. Still working with Keith Guerin around some of the action bar UX, but we're feeling solid about the side nav.

For consistency with the rest of the side nav (as well as making "Namespace" stand out more), I've given "Admin" the bold style of other top level nav items such as "Workloads." Is "Admin" something we would / could have an overview page for?
Screen two shows what it would look like when the user scrolls down – the second bar is kept sticky at the top of the page.

/ @maciaszczykm @floreks @bryk

[maciaszczykm]

Updated side nav in InVision refining the cards styling. Still working with Keith Guerin around some of the action bar UX, but we're feeling solid about the side nav.

@romlein I like this side-nav a lot :+1:

Is "Admin" something we would / could have an overview page for?

We could have some kind of administration panel here, but I'm not sure if it really necessary. At the moment I think not.

[bryk]

Awesome. Looks great. I'll have some questions around exact behaviors and pixels, but this is a good base already.

[danielromlein]

*Moving the conversation in #1117 about header / app bar back over here because I think it's more appropriate to keep this all in the same thread.

_Just to standardize: I'm referring to the first bar (with search) as the "top bar", and the second bar as the "app bar."_

This is the current double top bar design solution we're considering.

@Lukenickerson I think you raise some very valid concerns, but I'm still thinking this full-width double header may be the way to go:

• A full width app bar allows us to keep the same app bar on mobile and drop the top bar – shuffling key functionality into the app bar.
• It takes full-advantage of viewport to show breadcrumb objects and actions.
• It avoids splitting up the page into L-shaped regions, which the Material spec cautions against.

@bryk I still see value in the breadcrumb; interested to hear your thoughts.

Responding to your points:

Breadcrumb/title alignment breaks up the visual division between left-hand nav and content on the right.
Due to proximity, the breadcrumb/title may appear more closely tied to left-hand nav than to the actions on the right (echo of what Piotr said: "detached from the page content").

It does, but I think using a breadcrumb helps create that transition for users: starting at the global level, and then as breadcrumb items progress to the right, a user can see they're getting closer to deep content (and the current page).

Confusing to determine what elements on the page are related to global navigation/actions, and what is related to the selected page.

I think the color shading distinction between top- and app- bars helps establish that global / local distinction, as does the breadcrumb.

Most implementations of Material Design have the hamburger in the upper left. If we're going to break convention it should be for a good reason.

Agreed, and I can't find an example of an app with the menu icon in the second bar, _but_ I think the above pros outweigh the cons in this case.

If we do use the single top app bar with side nav extending up to that height, do you have any suggestions on how to deal with the issue of keeping the page title / local actions sticky while scrolling content without looking awkward @Lukenickerson ?

/ @maciaszczykm @floreks

[danielromlein]

After exploring different directions for header / app bar configurations, I think this design with a light top bar and blue app bar is the most successful option.

The user's attention is drawn to the app bar, and global level content can live above that as less prominent. Having the app bar be the only section with a background color establishes it clearly as such, and there's less ambiguity around its holding the menu icon.

/ @bryk @Lukenickerson @maciaszczykm @floreks

[floreks]

For me white top bar is more prominent now. It was the first thing that I've looked at when I've opened the page. IMO contrast between white and blue makes it very noticeable. Both top and app bar. Blue version top bar is blending with app bar thus making it less prominent. It looks more like a whole.

[maciaszczykm]

Just one thing, not so important, but I think it's worth mention. IMO when we consider, that most people use browser with light color theme, then white top bar is not so prominient, and can look like part of browser (especially when its position is fixed):

That's why I like first version a bit more:

Still, both are looking very good.

Perhaps we can add switch in settings? To choose between light and dark top bar theme?

[danielromlein]

Because for 1.4 we won't have search or login / role, I think for this release it makes sense to condense to one app bar.

@maciaszczykm you raise a good point about blending in with the browser chrome. We can explore options for the top bar further, but I feel pretty good about it: this light bar is the pattern used in Firebase, and I think it does put more emphasis on the app bar as such. @floreks something to keep in mind in terms of hierarchy is that there isn't yet any content on the page, so our eyes are naturally gravitating upwards, which I think is somewhat contributing to how noticeable you're finding it.

@bryk if this looks good I'll post the .sketch file and measurements for your tomorrow.

[bryk]

@romlein Looks awesome! I'm very happy with the direction we're heading and the incrementalism of the design. We can split this into top & app bars once we have content for them.

Can you post the sketch file?

[floreks]

@romlein I like the idea to merge bars into one for this release. Looks nice. @maciaszczykm also raised a good point about browser theme. Personally I prefer dark themes, so I guess this is why white top bar is so noticeable for me. :) Anyway most people use light themes which make blue app bars more prominent.

Firebase pattern also looks good. I'm wondering how it would look like if we'd use lighter blue on app bar. Maybe it's something worth exploring.

[danielromlein]

Attached is the Sketch file with fonts / transparencies / colors, and I've updated the InVision prototype to include spacing measurements (and the screen @bryk deleted 😛)

dashboard-nav-1.4.sketch.zip

Please don't hesitate to ask if you have any questions @bryk!

[bryk]

Awesome, thanks @romlein. I'll use this for implementation.

[danielromlein]

@bryk some feedback based on what I'm seeing on your dev environment (disregard if these items are no longer applicable):

1. Namespace font should be Roboto Mono
2. Highlighting behind selected / hover nav item shouldn't extend all the way to the left edge of the viewport. Margin should be 12px for primary nav items, 24px for secondary nav items.
3. Nav item highlighting bg should have 2px border radius.
4. Right edge of nav item highlight and horizontal divider should be aligned.
5. Margin around cards should be 20px on all sides.

[danielromlein]

Also, not sure if I should create a separate issue for this or if it's a quick fix that could easily be resolved here, but card titles currently blend in too much with the content they're above.

Improved version:

Card title section should be 56px tall to match Dashboard header.
Making card titles black (#000, 87%) helps distinguish them from the tables below, and I think it's still obvious enough to users that they're links (add hover state with a background of light gray – like side nav items).

[bryk]

Namespace font should be Roboto Mono
Highlighting behind selected / hover nav item shouldn't extend all the way to the left edge of the viewport. Margin should be 12px for primary nav items, 24px for secondary nav items.
Nav item highlighting bg should have 2px border radius.
Right edge of nav item highlight and horizontal divider should be aligned.
Margin around cards should be 20px on all sides.

@romlein All done. Demo updated. I had problems with scroll interactions, though. So please check this out now.

Card title section should be 56px tall to match Dashboard header.
Making card titles black (#000, 87%) helps distinguish them from the tables below, and I think it's still obvious enough to users that they're links (add hover state with a background of light gray – like side nav items).

I'm in the middle of applying this now.

[danielromlein]

@bryk looking good! What about the app bar? Is there any work done yet on that that I can review?

[danielromlein]

@bryk more revisions based on the demo:

• Primary navigation items should have a height of 44px (currently 40px)
  
• Side nav content should have additional 8px added in at the top.
  
• I didn't include this in the mockup explicitly so this is my fault, but the last object in the side nav should have 32px below it so it doesn't get lost behind the browser notification bar.
  
• Namespace
  
  
  
  • Namespace should have same 32px height, making underscore 10px away (underscore is currently too close to text)
  
  
  • Dropdown arrow should have an opacity of .54 and be aligned to the edge of the underline.
  
  
  • Dropdown arrow should be 24px horizontally from the right edge of the namespace.
  
  
  • Namespace font should be Roboto Mono _Medium_, not Regular (I think the added emphasis is important)
  
  
  • Dropdown dialogue selected should be blue, not blue _and_ have background accent. Spec:
    
    
  
  
  • Dropdown underscore should remain gray, not go blue like this:
    
    
  
  

[bryk]

@bryk looking good! What about the app bar? Is there any work done yet on that that I can review?

App bar looks as now. For the upcoming release, we'll be able to have global create button and contextual buttons for pages.

@bryk more revisions based on the demo:

Awesome feedback. I'll apply it on Monday :)

[floreks]

I might have some time to do it over the weekend. :)

[bryk]

That would be cool!

[danielromlein]

@bryk ah ok cool. In that case:

• Breadcrumb fonts should be Roboto 18px Medium
• Material icon called keyboard arrow right should be used between levels of hierarchy rather than the > character.
• App bar should be 56px tall instead of current 64px.
• "Kubernetes" should be the logo SVG, rather than a font.
  kubernetes-logo-no-icon.svg.zip

[colemickens]

@romlein What was the decision behind making the current namespace monospaced? It feels/looks a bit out of place in the context of the otherwise "Sans"-y dashboard.

[danielromlein]

@colemickens we wanted namespaces to have a high and unique priority in the hierarchy, and because we have the global "Admin" objects _above_ Namespace, a strong differentiator from surrounding elements was needed. Because Namespace titles are displayed code-friendly (don't know the technical term for this, but for example: kube-system rather than Kube System), Roboto Mono seemed like a logical fit.
I'm open to being persuaded otherwise though! Thank you for mentioning it.

What we should definitely do I'm now realizing is have Namespace titles within the dialogue be styled consistently with the original dropdown (i.e. Roboto Mono)

[colemickens]

I'd offer this observation: all other objects that are displayed via their "code" name rather than a human-friendly name are rendered as regulars Sans types: pod/rc/service names anywhere they occur, etc. I appreciate that namespace is special, but it seems visually and hierarchically prominent already, just by nature of it's placement in the sidebar, under the context of "Workloads", but clearly before any of the workload types.

I think it looks visually inconsistent, but I'm not a designer and don't feel strongly enough about it to push it other than this observation.

[danielromlein]

@colemickens thanks for the detailed feedback! I'm torn. Reaching out to some Google designers who're more familiar with Material to get their thoughts. Stay tuned!

[bryk]

I'd personally go with less fonts in the nav. And differentiate items by spacing/layout.

[danielromlein]

Keith Guerin with Google Cloud Platform agreed that a more effective way to differentiate than Roboto Mono might be either the pipeline that's already below or possibly the introduction of an icon. I think we should change it to Roboto Medium to be more consistent with the rest of the UI. I'll include that in the batch of fixes I'm drafting.
/ @colemickens @bryk