Dashboard: Dashboard design that lets us navigate different objects

Created on 11 Apr 2019  路  25Comments  路  Source: tektoncd/dashboard

The current dashboard is simple and that's ok for now but will not let us do the full range of navigation that experience says will be valuable for this sort of tool. This issue is to track some ideas on what me might do with the dashboard UI

design-help-wanted

Most helpful comment

tekton-ui-first-pass

This is just a slight cleanup of the work @skaegi and @pkruithofjr did yesterday but I wanted to post it here just so I'm not losing artifacts. I'm still looking at the second screen with the expanding trees though. It seems like there is a design opportunity there.

All 25 comments

One idea is to have the dashboard take on more of a look and feel similar to the Kube dashboard -- https://github.com/kubernetes/dashboard

So something like this... (note I am not a professional visual designer but I sure know some ;) that I hope will help us out...

image

image

Considering using line drawings without color to avoid any confusion. We also need to be more specific about what is being proposed. For example, the left navigation pane from K8s?

This was the digital equivalent of me cutting and pasting paper on a poster board. nothing more nothing less. With that said from now on my poster boards will be light grey ;).

The left navigation pane is directly from the Kube dashboard. For Tekton I'm thinking of something similar but instead of "Cluster" the Headings might be:


Tekton

  • Pipeline
  • PipelineRun
  • PipelineResource
  • Task

- TaskRun

Namespace


Extension Category 1 [from Service metadata] Knative Eventing

  • Extension topic 1
  • Extension topic 2

Extension Category 2 [from Service metadata] Native worker agent

  • Extension topic 1
  • Extension topic 2

etc...

Is this what you were thinking? I was struggling a bit with what you meant by Extension Category 1 and Extension Category 2.
tekton <a href="home@3x">home@3x</a>

Thanks @pkruithofjr that captures it nicely.

Should we break this issue into separate issues? Info Architecture, Pipeline Design, and Dashboard Design?

Yes absolutely we should definitely break off into separate issues... and please feel to take a crack at it. I don't want to go too far on dashboard architecture without running code but that is the area I'm probably most interested in. Any help to break down the problem appreciated.

This issue is primarily concerned with finding a top-level layout that will work for us. There should be separate issues covering the top banner, breadcrumbs, navigation menu, and main content pane.

Graphical rendering of pipelines and pipeline runs are huge topics all by themselves that will cover a bunch of issues.

@skaegi I was looking at the dashboard and I am wondering why are you creating REST and points? Kubernetes already has an API server and tekton does everything as CRDs, wouldn't it be easier and more portable to develop the UI against kubernetes API server and tekton CRDs?

tekton-ui-first-pass

This is just a slight cleanup of the work @skaegi and @pkruithofjr did yesterday but I wanted to post it here just so I'm not losing artifacts. I'm still looking at the second screen with the expanding trees though. It seems like there is a design opportunity there.

@skaegi @pkruithofjr We're going to track the design work here:
https://github.ibm.com/dev-ex/design-work/issues/200

This issue is primarily concerned with finding a top-level layout that will work for us. There should be separate issues covering the top banner, breadcrumbs, navigation menu, and main content pane.

Graphical rendering of pipelines and pipeline runs are huge topics all by themselves that will cover a bunch of issues.

It's up to Alan and Alexandra how they want to divide their work up into issues but I have UX and visual design issues there to start.
Typically, for visual design, we do not need separate issues for each UI component. Alexandra will submit HTML/CSS blueprints of the UI to your team.

I don't mind the epic there but all issues should be here plz to make things as transparent as possible and let anyone come in and contribute.

@gorkem that's a good question -- open an issue on that.
A couple of things...

  1. When we first started talking about a UI for Tekton the notion of object persistence independent of cluster lifecycle was something we were thinking about. In a pure dashboard maybe it's overkill.
  2. The API used by the UI might be tailored to include more, less, or computed information based on the resource. We probably should talk to the Kube dashboard folks to see what their experience was.

Just some ideas I've been putting together ..... just images for now, probably wider than just how to navigate... haven't covered all menu options

Dibbles_Ideas.pdf

@AlanGreene @kimholmes keen to discuss and be involved especially regarding extension - where I have more ideas

Wow this is fantastic. Thanks @dibbles! Not sure about the "funky drag and drop UI" but I love how the cat plays a central role in the design. Thanks for posting it.

Updated user flows for discussion

tekton-flow.pdf

Is the idea is to show ClusterTasks under the Tasks in these designs?

Wireframes that I showed in today's meeting:
https://ibm.invisionapp.com/share/3GNZ28C986U

latest Invision link-> https://ibm.invisionapp.com/d/main#/console/15348721/319165802/preview
to see the updated troubleshooting click on Tekton logo twice, it will bring you to this screen:
1

to take you back to old version click the header

Updated Invision Link:
https://ibm.invisionapp.com/share/3NNZ5IO9WRH

Please let me know if any links are broken or if you have any comments/feedback would be greatly appreciated!

Wireframe Diagram Design Demo
Diagram Design.zip

@skaegi I'm having a look through issues looking for ones we can close out/reprioritise etc, thoughts on closing this out and capturing new designs (like those posted above) as part of new issues that are more specific?

This was a really early days issue that we've done a great job on - we don't want this to be open forever though 馃樃

@AlanGreene @skaegi I think it's fine to close it but we do need to track this effort somewhere. I see it as having to pieces, the design spec and the dev issue. So, it could be divided into two new issues.

Was this page helpful?
0 / 5 - 0 ratings