search

containers / podman-desktop

Podman Desktop - A graphical tool for developing on containers and Kubernetes
https://podman-desktop.io
Apache License 2.0
4.36k stars 277 forks source link

Inconsistent table styling #7794

Closed ekidneyrh closed 4 days ago

ekidneyrh commented 2 weeks ago

Is your enhancement related to a problem? Please describe

This was brought up during the UX call 20/06/2024. There are a number of inconsistencies between the different pages.

Describe the solution you'd like

Establish one visual style of all the tables to follow - perhaps small deviations if necessary.

Tickets opened from this ticket:

deboer-tim commented 2 weeks ago

Just to reiterate what I was hoping for here is confirmation that:

ekidneyrh commented 2 weeks ago

Main/Name column is table-highlight colour, rest are normal table text colour.

Yes that is corrent. This is to make the name stand out from the rest of the info.

Only one column should be a 'label'.

Yes it's the Enviroment column that is a label. I'd like to get a library at some stage of all the available labels.

Styling of main/name column - currently containers page is different from others, should second line always be purple+highlight text? Or purple+regular text?

Image

Do you think we would benefit from getting rid of the ID and such from underneath the name? These details for the item can be viewed on the details page, where they will be properly labelled. I agree that there's too much going on there.

If it's necessary to keep the ID there, I would have just that under the name and

Would be nice if we can confirm what 'group' rows should look like too, e.g. in Containers page we show pods and compose groups as "My compose group (compose)" or "Mypod (pod)", and in images we now show manifests as "My manifest (manifest)", I don't know if this is really ideal or we now think different icon is enough. (in which case we should probably have compose icon)

I'll have to look into this, as I'm unsure why we do it now? It seems a bit confusing but I'll get back to you when I look at it more.

ekidneyrh commented 2 weeks ago

Had a look at the tables on the different pages and the main differences I noted were:

Image

An alternative to sorting this way can be the use of the Status sorting button. We will either implement it across all the tables or get rid of it. I vote in favour of keeping them. I think it’s a clean way to organise the objects and the groupings are clear.

Do we know if users find those tabs useful and use them?

Space all out evenly and have in the same order and variables in the same slot.

| STATUS | NAME | ENVIRONMENT | [VARIABLE] | AGE | ACTIONS

The variables would be:

We need to reduce the visual clutter when there are more than 2 buttons. Having five call-to-action buttons that all look the same can be confusing.

Image

When there’s more that 1 button other than PRUNE, I propose to have them behind one + ADD button. This will reduce the distractions in the upper right corner and have everything organised.

Image

There could be a more suitable word than ADD so let me know what you think.

The introduction of primary and secondary action buttons here would be beneficial. The PRUNE changed to a secondary and the ADD remaining as the primary.

Image

[Secondary is gray-200]

Something I would like to see is the search bar / input field being half the width it is at the moment. I find it’s distractingly long

Current:

Image

Proposed:

Image

Another nit would be the line that divides the tabs from the lower part of the page. It’s currently going through the whole page:

Image

Would there be a way to adjust that so it lines up with the header, input field line, and the rows at the start, and lines up with the action buttons and end of the rows at the end as such:

Image

I don't have the labels set up on Penpot yet, so that's lacking from the screenshot below, but here’s what each table should look like on each of the pages:

Image

I'm going to look into the 'group' rows as mentioned by Tim above. I'll comment here with more updates soon.

ekidneyrh commented 2 weeks ago

Looked into the groups some more today. Seems a bit clunky given there's a separate pod page, but I understand why it’s there. And I know there’s no separate page for manifests and the likes.

We need to have it more differentiated from the rest of the info in the table, as it just looks like the other rows. I dont think the merging of them is enough.

I’d suggest having the ‘Group’ row a different colour. This would be slight, just enough so that the user know it’s something different. Here’s an idea of what that would look like:

Screenshot from 2024-06-27 12-48-36

Again, this is so there’s more visual clues on the page that indicates that the ‘Group’ row is acting as the header for the group items.

I added a kebab menu to the group row, maybe we could have an option to ungroup here? And any other relevant functionalities.

ekidneyrh commented 2 weeks ago

I've added colour values for light mode here: https://github.com/containers/podman-desktop/issues/6929#issuecomment-2195487148 and updated the wiki https://github.com/containers/podman-desktop/wiki/Design-System-Theming#nav-page

deboer-tim commented 1 week ago

Wow, there is a lot here :), and feedback for things 'outside' of the table that I wasn't looking for. Responses inline, I think we need to break this up to track items individually.

Had a look at the tables on the different pages and the main differences I noted were:

  • Tabs on top of page:

An alternative to sorting this way can be the use of the Status sorting button. We will either implement it across all the tables or get rid of it. I vote in favour of keeping them. I think it’s a clean way to organise the objects and the groupings are clear.

Do we know if users find those tabs useful and use them?

I think the feedback so far has been positive/useful. We already had sorting but users wanted a filtered list.

  • Spacing of headers

Space all out evenly

Not 100% sure what you mean here. We haven't been very consistent on column width weighting, in part because there are different columns and (e.g.) image names tend to be very long compared to volume names. If you have specific recommendations please open up an issue, or any of us can tell you what weights are currently used in any table. Also keep in mind that we also have 5 (and counting) Kubernetes tables with different columns.

and have in the same order and variables in the same slot.

| STATUS | NAME | ENVIRONMENT | [VARIABLE] | AGE | ACTIONS

The variables would be:

  • Containers page -> IMAGES
  • Pods page -> CONTAINERS
  • Images page -> SIZE
  • Volumes page -> SIZE

Is the main recommendation here that Age should always be the second-last column (which would need to be fixed for Images and Volumes at least)? Easy to swap them, but we should track via new issue.

  • Number of buttons

We need to reduce the visual clutter when there are more than 2 buttons. Having five call-to-action buttons that all look the same can be confusing.

When there’s more that 1 button other than PRUNE, I propose to have them behind one + ADD button. This will reduce the distractions in the upper right corner and have everything organised.

There could be a more suitable word than ADD so let me know what you think.

+1 to reducing the number of buttons and having a pattern to reduce the clutter, but in this case I'd say Build and Pull are the most critical/used daily. None of the others really fit into a category (and won't in general), so maybe we could have a general rule something like "no more than 2 standalone actions and the rest go in an 'other' dropdown"?

  • Action buttons

The introduction of primary and secondary action buttons here would be beneficial. The PRUNE changed to a secondary and the ADD remaining as the primary.

[Secondary is gray-200]

Beside the previous comment (I don't think prune is important enough to show compared to other actions), to me this is a little odd because primary actions would take two clicks but we'd show a secondary action. In general I agree we should make more use of secondary though.

  • Additional:

Something I would like to see is the search bar / input field being half the width it is at the moment. I find it’s distractingly long

+1, just open a new issue, easy to fix.

Another nit would be the line that divides the tabs from the lower part of the page. It’s currently going through the whole page:

Would there be a way to adjust that so it lines up with the header, input field line, and the rows at the start, and lines up with the action buttons and end of the rows at the end as such:

+1. I agree that makes it more obvious it is a filter on the table, and implementation should not be hard. Also needs a new issue though.

deboer-tim commented 1 week ago

Looked into the groups some more today. Seems a bit clunky given there's a separate pod page, but I understand why it’s there. And I know there’s no separate page for manifests and the likes.

We need to have it more differentiated from the rest of the info in the table, as it just looks like the other rows. I dont think the merging of them is enough.

I’d suggest having the ‘Group’ row a different colour. This would be slight, just enough so that the user know it’s something different. Here’s an idea of what that would look like: [...] Again, this is so there’s more visual clues on the page that indicates that the ‘Group’ row is acting as the header for the group items.

Good idea to visually style the grouping row differently. My only concern here is that this is the Containers page, so maybe we should make the pod row stand out less than the containers? Currently for me it draws the eye away from the containers.

This begs the question if we're always going to use groups as a way to show the 'parent relationship' and never 'child details', but so far that's the case (i.e. we show parent pods in the containers page but not child containers in the pods page) and if we ever did the opposite it would be easy enough to swap row colors.

I added a kebab menu to the group row, maybe we could have an option to ungroup here? And any other relevant functionalities.

Now that everything is using the table component we could support ungrouping, but it is not there today. If you ungroup I assume the pods would disappear since they are not the focus at that point? It's not clear to me how you would be able to 'regroup' at that point. Either way, I think we should track this via separate issue as it is a standalone design and would need to be prioritized.

Side note: the above is more 'showing a relationship' between pods and containers, but we also have an initial design somewhere for the ability to group (e.g.) the Pods page by environment, e.g. a toggle to remove the environment column and visually separate the pods under Podman, Kind, or other provider. I don't know if we should start using different terms, but I think the other design will be useful and don't want to create competing mechanisms.

ekidneyrh commented 1 week ago

Thanks a lot for the feedback, Tim! I'm going to open those tickets now, and I'll add them to the description too, once they are open :) I'll elaborate more where necessary on the tickets so it's clear what I'm looking to have done.

This will prob take some time, but I'll try to get them all logged today.

ekidneyrh commented 5 days ago

I did some digging and found these mockups

Global Pod List_ Engine_Namespace Headers 1 Global Pod List_ Engine_Namespace Headers 2 Global Pod List_ Engine_Namespace Headers 3 (few pods, 2 envs only)

IS this what you were reffering too? I couldn't find any with a toggle

deboer-tim commented 5 days ago

Yup, that's the design I was thinking of, and independently I made a little prototype (now lost in my git history). In the prototype I thought we needed a way to toggle between the current view and this one so I had added an ugly toggle at the top right.

Added a related comment to #7947, I guess my point is that I think we'll need some other controls for tables if we allow things like grouping/ungrouping (especially if there are two forms: parent/child vs something like environment), and we'll need a place to put them. Does not need to be in this issue though!

ekidneyrh commented 4 days ago

Okay. I think then that it could be split into two issues. One look for adding controls on the table pages for filtering / sorting, and another for showing the grouping / ungrouping of items.

I think focusing on the filtering controls first and then look at the latter with the base of the mock-ups above.

ekidneyrh commented 4 days ago

I added the tickets that have been opened from this ticket in the description. Closing as I think we have covered everything for the time being.