Design doc for next version of user experience of the UI #589
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,159 @@ | ||
| # UX and navigation that scales | ||
|
|
||
| This design document is a proposal for Dashboard UI user experience that | ||
| covers navigation and the way of displaying and interacting with K8s objects. | ||
|
|
||
| ## Background | ||
|
|
||
| Currently Dashboard UI allows users to see and interact with a very limited | ||
| subset of Kubernetes resources. For example, it shows Replication Controllers, | ||
| while ignoring existence of Replica Sets, Deployments, Daemon Sets, etc. | ||
| Additionally, it does not allow for creating or modifying individual | ||
| resources, while supporting only application creation (akin to `kubectl run`) | ||
| and scaling. For more details see [mockups](mockups/11-11-2015-initial) of | ||
| current implementation. | ||
|
|
||
| These limitations have been number one source of feature requests and | ||
| user complaints (e.g., #564, #524, #509, #510, #232). The core team also | ||
| considers solving these limitations as a natural evolution of the UI. | ||
|
|
||
| ## Problem statement | ||
|
|
||
| * Scale the UX to support displaying and editing all current and future | ||
| Kubernetes resources (e.g., replica sets, daemon sets, container, nodes, | ||
| volumes, secrets, deployments, etc.). | ||
| * Scale for the number of objects displayed (currently: cards are suitable for | ||
| O(20), desired: show any number of objects). | ||
| * Guide users through use-case based views (don't just do API dump). | ||
| * Make the UI aware of namespaces and multi-cluster installations. | ||
|
|
||
| # Design | ||
| The design is based on a few novelties to the UX of Kubernetes Dashboard. This | ||
| is: | ||
| * introduction of use-case based navigation menu and views | ||
| * replacement of free-form cards by tabularized resource lists | ||
|
There was a problem hiding this comment. Total replacement, or alternative formats? For instance, file explorers generally allow users to choose between icons and detailed lists, or in some cases choose automatically based on the number of items. There was a problem hiding this comment. I say total replacement for forseeable future. I agree that it'd be nice to have both. We must be realistic though - we don't have eng capacity to implement and maintain both. The plus is that we don't propose using raw tables. We propose using tabularized lists, which can display exactly the same information as currently cards do. So all that changes is form factor: cards get wider and get columnized. There was a problem hiding this comment. Question: what happens if a column contains multiple values (like labels) and the users sorts on this column? Is the result predictable or understandable? There was a problem hiding this comment. Multiple values make sense for row-oriented formats, not for columns. They should be split into multiple columns |
||
| * being explicit about Kubernetes resources displayed in the UI | ||
|
There was a problem hiding this comment. This is a tradeoff. kubectl run and expose deliberately gloss over the underlying resource model. There's a place for that in the getting-started/demo experience. There was a problem hiding this comment. There will still be the "app creation form" which is basically |
||
| * introduction of action bar for performing all actions on resources | ||
|
|
||
| ## Navigation | ||
| Navigation is realized by left hand side menu. The menu consists of use case | ||
| driven categories that group Kubernetes resources. For example, there may be | ||
| category called "Apps" which deals with Replication Controllers, Pods, | ||
|
There was a problem hiding this comment. We should talk about how to present the concepts, because I want to align our docs and the UI. cc @kubernetes/docs There was a problem hiding this comment. "Apps" doesn't correspond to anything in the system or docs. "Controllers" would correspond to system concepts, but might not be intuitive for new users, and is somewhat broader (e.g., HorizontalPodAutoscaler). Maybe "Workloads"? There was a problem hiding this comment. "Apps" category is just an example category to illustrate this design doc. We intentionally didn't propose the categories here, as this requires broader coordination. Ideally we'd like to have some initial category definitions in a few weeks and something stable by 1.3. Is there somebody from UX or docs team that is driving this effort? Or should we drive this? There was a problem hiding this comment. Would like to stay involved in this particular part of the discussion. We are looking at reorganizing the OpenShift UI's left nav (some early discussion here https://trello.com/c/dWIKyBWi ). Would like to keep consistent terminology where we can. From our users' perspective a service is just a part of their application/microservice, which is why we chose to organize our dashboard with service as the "parent" element and organized the things the service points to underneath of that. There was a problem hiding this comment. We were just discussing jobs yesterday actually. Jobs (and things like On Fri, Apr 1, 2016 at 2:33 AM, Brian Grant [email protected]
There was a problem hiding this comment. Thinking out loud:
"Workloads" still seems best (relatively). Where we discuss just controllers (and not controller-less pods), I might use "Workload controllers". A more infrastructure-y approach would be Compute, Networking, Storage. This could be clarified with tooltips and/or help buttons. |
||
| Deployments, etc., and "Config" which deals with Secrets, Volumes, | ||
| Namespaces, etc. The exact definition of categories will happen in a separate | ||
| design. | ||
|
There was a problem hiding this comment. We should consider a cluster admin category. |
||
|
|
||
|  | ||
|
|
||
| Menu categories may be expanded into raw resource subpages for expert users. | ||
|
|
||
|  | ||
|
|
||
| Menu follows standard responsiveness practises where it folds into icons and | ||
| hamburger menu when space is limited. | ||
|
|
||
|  | ||
|
|
||
| ## View templates | ||
|
|
||
| This section shows concepts used as templates for all views. | ||
|
|
||
| View which does not deal with a resource or a resource list, e.g., landing | ||
| page which shows an overview of a cluster. The page consists of, potentially | ||
| dismissable, blocks that display data. | ||
|
There was a problem hiding this comment. Like the idea of pointing to docs. Would like to chat about how we could make docs a more effective help tool for UI users. cc @kubernetes/docs There was a problem hiding this comment. recommendation, keep all help links in one single location / helper utility in the code and reference them based on unique topic names everywhere else, because inevitably doc links will change and its much easier to update a link in one place, see https://github.com/openshift/origin/blob/master/assets/app/scripts/filters/util.js#L168 and https://github.com/openshift/origin/blob/master/assets/app/scripts/constants.js There was a problem hiding this comment. Thanks @jwforres for the suggestion! |
||
|  | ||
|
|
||
| Category view which shows lists of resources. In this mockup it is | ||
|
There was a problem hiding this comment. I probably wouldn't put pods in the same view as all controllers. We should chat about how to organize the pod view: sorting, grouping, filtering, aggregation, etc. By names, labels, controllers, services. There was a problem hiding this comment. I don't think status info should only be presented as freeform info in the card. Info like number of available replicas in a Deployment, number of container restarts in a pod, etc. is useful to sort on. We'll want logs links on pods for debugging use cases. An exec widget would be awesome, too. Rather than just one labels column, I'd like users to be able to add labels as columns, as with kubectl -L, to facilitate grouping and sorting. There was a problem hiding this comment. In general, take a look at what we've been doing with kubectl output. We moved big, unstructured info like images, labels, selectors to optional "wide" output. We also don't display nodes by default for pods. There was a problem hiding this comment. Idea: profiles (perhaps customizable/user-definable) to select columns displayed. For example, a "Debugging" profile might show status info (number of ready pods, number of restarts, etc.), logs, exec, last termination info. A "Rollout" profile might show image and a subset of status info, perhaps highlighting recent changes in some way. A "Resource" profile might show cpu, memory, disk stats. There was a problem hiding this comment. We could also think about groups to eliminate the need for columns in some cases. For example, group pods by controller (identified via controllerRef in 1.3 kubernetes/kubernetes#2210 (comment)) and/or labels. There was a problem hiding this comment.
Yes, there's a place for that in the actions column and/or action bar. There was a problem hiding this comment. I like most of your ideas presented here. Is this something that blocks this design? Or nice-to-have future work? I'd say this is for future work. We're aiming for Q2 with using this UX language, so we have to be cutting features and complexity aggressively. Can I add your ideas to future work section so that this serves as a base for future development? There was a problem hiding this comment. @bryk We don't need to add features in Q2, but how hard would it be to tune how the data is presented, such as to add or remove columns, or present data in columns rather than freeform text? There was a problem hiding this comment. Such things are not hard, but just require a lot of work. Whenever you do something for the first time in the project, you need to design, discuss and then implement. You know, this takes time and effort. So, my realistic view is that all we can have for Q2 is: static structured data in static columns + freeform text with unstructured data. Columns can be sortable. Rearranging, customization, label pivoting, profiles are things I like a lot, but this is for Q3+ There was a problem hiding this comment. I like the idea of customizing the columns as I am a bit worried about squeezing too much into too many columns, leaving not enough space for content. |
||
| (not defined yet) "Apps" category which was selected through the | ||
|
There was a problem hiding this comment.
Our idea was to have a list of all pods accessible from somewhere. This is because there will always be people using unattached pods (e.g., for experimenting) or people looking for a specific pod. No matter what menu category pod list lands on, we'd like to make the list very limited (e.g., show 5 pods and "see all" link) and placed at the very bottom to indicate that controllers (replica sets, jobs, etc.) are the thing to use on everyday basis. Does this make sense? There was a problem hiding this comment. Agree with these points, standalone pods are less important / go at the bottom but you should still see that they are there and be able to get to them. We took the approach that things that have services pointing to them come first, things that are controllers without services come next, and standalone pods last. There was a problem hiding this comment. I like the approach suggested by @jwforres |
||
| navigation menu. | ||
|  | ||
|
|
||
| Action bar replaces floating action button. The reason for this change | ||
| is the fact that floating action buttons do not work well on desktop | ||
| form factors, which are used by vast majority of our users. On the other | ||
| hand, action bars work well on any form factors (desktop, mobile) | ||
| and can scale for different actions on different resources. | ||
|  | ||
|
|
||
| Details of the resource list block: | ||
|  | ||
|
|
||
| While the concept of cards used for displaying resources has some nice | ||
| characteristics (like information density) it has been a constant source of | ||
| problems. Users and developers complained about many issues: how do you sort | ||
| cards? how do you change their order? how do you paginate them? how do you | ||
| compare resources against each other? how do you distinct different resources | ||
| in a card stream? how do you do bulk operations? | ||
|
|
||
| We have identified that in order to solve these problems the cards can evolve | ||
| into tabularized list items which can show exactly the same information as | ||
| cards. This solution has many advantages, some of which are: pagination, | ||
| ordering, bulk actions or visual comparison. Following mockup outlines | ||
|
There was a problem hiding this comment. How will bulk actions work? Will each item have a checkbox, similar to gmail? There was a problem hiding this comment. checkboxes would be the typical approach, it provides a clear indicator that the row is selectable, and provides a browser-native accessible selector for keyboard+screenreader users There was a problem hiding this comment. Yes. I'll add this to the mock. |
||
| the evolution: | ||
|  | ||
|
|
||
| Category views link to single resource views which show an unbounded list | ||
| of resources of single type (e.g., Replica Sets) and a short summary/ | ||
| call to action block. | ||
|  | ||
|
|
||
| Details of an individual resource instance are shown on a views which displays | ||
| its properites and all related objects (e.g., Services that target a Pod). | ||
|  | ||
|
|
||
| ## Future work | ||
| * Make it possible to add/remove columns from resource lists. This is to | ||
| accommodate different use cases and needs that different users have. This | ||
| can be based on individual user's preference or their profiles. The profiles | ||
| may be, e.g., "Debugging", "Release" or "Resource Management". | ||
| * Pivot labels into columns. For example, for every replica set in a list | ||
| have a column named `env` which displays the value of this label | ||
| (e.g., `dev`, `prod`, `test`). The pivot is user configurable. | ||
| * Design application menu categories. Tracked in | ||
| https://github.com/kubernetes/kubernetes/issues/22687 | ||
| * Design individual resource lists and detail pages (for, e.g., Pods, Services, | ||
| Replica Sets, etc.) | ||
| * Advanced resource list filtering that supports label and field matching | ||
| * Better handling large number of resources: customized pagination and | ||
| section collapsing. | ||
|
|
||
| ## Concrete pages | ||
| This section shows how templates proposed in the "View templates" section | ||
| can be applied to real examples. | ||
|
|
||
| "Apps" category: | ||
|  | ||
|
There was a problem hiding this comment. It's kind of weird that controllers have endpoints. The unstructured Pods column is problematic IMO There was a problem hiding this comment. I'd eliminate endpoints, but we should think about where we could provide links to the app, that would hit external IPs/ports of the service, or would use the apiserver proxy. There was a problem hiding this comment.
Yeah, endpoints are problematic, but, in reality, very useful. Perhaps this needs better title/wording/documentation. Perhaps this can be moved to the unstructured part of the card. But this is a problem with the specific page, not the proposed new UX language here. I assume non blocker. There was a problem hiding this comment.
What's the problem? Should it be structured and split into a few columns? There was a problem hiding this comment. Yes, exactly, pods should be structured and split into a few columns, to facilitate sorting. |
||
|
|
||
| Replication Controller list under "Apps" category: | ||
|  | ||
|
|
||
| Pod details overview: | ||
|  | ||
|
|
||
| Pod details events: | ||
|  | ||
|
|
||
| Pod details logs: | ||
|  | ||
|
|
||
| Pod details SSH tab: | ||
|
There was a problem hiding this comment. we use term.js for the in-browser terminal, we actually use this fork which is set up for Bower https://github.com/vahe/term.js it works pretty well, main complaint is the copy/paste behavior is a little weird across different browsers |
||
|  | ||
|
|
||
| Replication Controller details overview: | ||
|  | ||
|
|
||
| Replication Controller details events: | ||
|  | ||
|
|
||
| ## Credits | ||
| [Source code](mockups/23-03-2016-scale-and-navigation/dashboard-scale-and-navigation.bmpr) | ||
| of the mockups. | ||
|
|
||
| Proposed by [@bryk](https://github.com/bryk), | ||
| [@cheld](https://github.com/cheld), | ||
| [@digitalfishpond](https://github.com/digitalfishpond), | ||
| [@floreks](https://github.com/floreks), | ||
| [@maciaszczykm](https://github.com/maciaszczykm), | ||
| [@olekzabl](https://github.com/olekzabl), | ||
| [@zreigz](https://github.com/zreigz) during 23-03-2016 design sprint day | ||
| ([report](sprints/scale_ux_20160323.md)). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cards are suitable for <= 6 IMO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to keep multiple audiences and scenarios in mind. I outlined some operational scenarios on #21.
Personally, I think most people running workloads in production won't mutate them with the UI:
http://martinfowler.com/bliki/InfrastructureAsCode.html
However, one scenario I didn't cover is demos. The current functionality is aimed at that use case, IMO (as was kube-ui), and there's more we could do there, such as visualizations of cluster and app topology.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Abstracting from the actual number, I think we agree that cards dont scale.
Yes, I generally agree. That's why we're focusing on displaying data for now. However, edit functionality in the UI is still very useful for one-off operations that you dot automate (e.g., kill zombie pod, change service IP address, etc).