Can only see a couple pod rows when there are a lot of labels about console HOT 16 CLOSED

This change looks good to me @spadgett. I also created this issue in PatternFly to try and get the "expand all" behavior added to PF tables in the future. For example:

from console.

@spadgett I thought based on the previous requests regarding labels, we may want to keep these columns and keep the Edit Labels action available too. I know we talked about doing that and went back and forth on it a bit. Wondering if we can keep labels as a column on all summary pages for consistency, but when there are more then 3 maybe having them fade out and only showing the rest on detail views, or use a show more/ show less link so they don't take up so much vertical space.

from console.

How about showing all the label in a tooltip, when use hovers over the column ? That case the columns can stay fairly small, we can edit them and user can see them upon hovering.
Although Im not sure how that would play out for mobile devices

from console.

@spadgett is this another item we could get feedback on at DevCon? both around use cases & possible alternatives

I'm curious as to what the use case is here ... are they looking at the labels of a specific resource and possibly navigating to it? Or do they want to see all labels of all resources at the same time to compare?

Assuming the former, I think there are a number of design alternatives, in addition to what @jhadvig mentioned

• include an icon when labels exist, clicking on the icon could provide an infotip showing the labels ( thus these could still be clicked )
• include a column showing the number of labels, clicking on the icon could provide an infotip showing the labels ( thus these could still be clicked )

from console.

Another option is to make them visible within a expanded row state. We currently do that on the Nodes list view, although it's either all rows expanded or all collapsed.

In column format the label text is usually truncated so much that they are unreadable. And being able to sort by label doesn't seem to be of much value.

from console.

I had a design a long time ago that moved all labels into an expanded row state, with them flowing across the full row since they tend to be both long and numerous in practice. Food for thought.

from console.

@robszumski @spadgett @openshift/team-ux-review Brainstorming on a few more ideas that would collapse some of the longer label rows but still maintain the column format. Thoughts on any of these below?

from console.

I like the "3 more..." most but as the trend to programmatically generate these increases, I lean towards removing them all together and only show on the detail page + the search page, where you can actually do a label query.

from console.

Like like options 4 and 3. One other thing is if we had a way to not show "advanced" items by default, like there is the compact and expanded forms. If we had the concept of "primary" or inversely "extra" labels, we could treat them with the right priority.

from console.

If we had a compact view, I'd suggest that the tag column just show the number of labels with an associated infotip (similar to option 4). Then we could have an expanded view which showed all the labels.

from console.

I personally would prefer to just drop the column. I'm not convinced labels is one of the top 5 things we could show here, and space is precious in these tables.

from console.

@spadgett @sspeiche @robszumski Thanks for the input thus far! Final question in my mind is do you think it's important to allow users to filter by label on the resource summary pages (Deployments, Pods, Stateful Sets, etc.)?

My thought is either, (1) we need to allow filter by label, so we should show labels to some extent (maybe with the "more" link) or (2) we do not need to allow filter by label, so we drop the column on all detail pages.

Maybe there is a (3) where SOME specific summary pages require filtering by label, in which case we show the column just for those resource types. Thoughts?

from console.

@beanh66 filter by labels in this context is useful not doubt, though I'd need to better understand what is lost. App labels would be a primary label to filter on.

@spadgett I'd be interested your ranked list of things you'd see users needing before labels are shown.

I'm in favor of keeping things slim for now and gradually add things one we are down to a single code base.

from console.

I have a WIP PR #1536 that adds memory and CPU usage to the pod list. Thoughts? To me, this is way more useful than labels.

Incidentally, working on this helped me catch a real memory link prior to 4.1. Having the memory usage just there in the list makes it easy to notice problems you'd otherwise have to go looking for.

If we still need labels, could we add compact/expand option like for nodes?

from console.

Closing since the pods list no longer shows labels.

/close

from console.

@spadgett: Closing this issue.

from console.