[Question]: Proper way to display filtered counts

[gogonzo]

What is your question?

During refactor of the filter panel we lost little of confidence of how should we display filtered counts. Currently it looks like this:

Above counts present following information:

1. variable categorical has 3 levels
2. counts of the levels in variable after excluding other filters are: 30, 115, 245
3. each bar size is relative to their proportion in a data so one can conclude that first category is a small fraction of the whole vector.
4. counts of the levels in the variable with filters applied are: 5, 17, 22

However, there are some voices undermining current view as it's too complex etc.

There are some propositions, for example to exclude bars from the choices labels and display them somewhere else, for example like this one below. Solution is not complete yet, but showing that maybe we should place the counts somewhere else.

Looking for more ideas @insightsengineering/nest-core-dev

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[chlebowa]

My suggestion was more like this:

the color of the bar reflecting selection state.

There are a number of problems with this: labels can be too long to fit in the bars, the bars themselves can become quite thin if other filters are applied, etc, but perhaps it can be refined?

[BLAZEWIM]

I really like the initial design, and I would really only changed the colors to light-green / light-red.
It also saves a little more space. I would not round the corners on the bars to be 101% by the book.
If the bars makes things too complicated, we could actually remove them, not move them away from the labels. It might be actually a little bit more confusing to have them somewhere else.

[pawelru]

I am not going to lie - it took me a while to understand it fully. The most confusing part is XX / YY notation so I would focus on this part mostly. I feel that I could be a good benchmark as I haven't participated in all of the discussion. Once I understand it then I honestly cannot came up with a better suggestion.

Some few random ideas. Feel free to disregard, agree, cherry-pick or mix and match the ones you like:

• I do believe that counts are level attribute / belongs to a level therefore I think it needs to be put next to the level label (as opposed to a bar below all options choices)
• Going further with this idea - can it be a HTML element (i.e. bootstrap progress bar) as opposed to ggplot graph in the background? This might give you some greater styling flexibility (e.g. mouse hovering), allow JS events, be in line with the overall app theme and so on...
• Yet another control in GUI to decide which counts (and plot) to display. I don't know yet on which level should it be (overall filter setting vs change single value/bar on mouse hover). This needs to be very minimal not to "overcrowd" GUI.
• How about label the values -> put everything right, smaller font and add label, e.g. "Overall: XX \n Filtered: YY"

[lcd2yyz]

I still strongly prefer the initial design, with two-tone progress bars along with the counts shown on the same line with at value-level. There is a bit of duplication of information, however both formats of presentation (counts and colored bar) show info from two slightly different perspective, and together they provide the complete picture of the available data

• Two-tone color progress bar - as @gogonzo already mentioned, the length of bar gives a quick one-glace summarizing visual of the proportions of each level in the data.
• Counts in label - accurate tabulation of the the selected/filtered vs available-to-be-selected/unfiltered data points in the dataset, in case users want the exact number

I would like to understand the reasons for considering alternative display formats - were there specific technical challenges/limitations/restrictions we cannot overcome with the initial design? Because I do not think any concern were brought up on this particular feature during the design phase.

Lastly, I do not feel the newly proposed multi-color one-bar graphic will suit our user needs

• Can/should the app user assume the colored segments of the bars are in the same order as the labels? This is quite a big assumption to make
• It may still be legible with just 3 levels, but what if there are 5 or more levels within a variable? There will be more difficulties matching the sequential order of the level labels with the sequential order of counts in the horizontal bar.
• I'm not sure how will the two-tone idea (selected vs unfiltered counts within each level) be displayed in the new layout?

I will defer to @pawelru comments on the technical suggestions. If needed, I think there can be few other tweaks to ease the technical implementation. For example, instead of adding the counts to choice label directly, perhaps the counts can be "drawn" as part of the horizontal bar graphics, but still shown on the same line as the label. Nonetheless, we should continue with the original design.

[lcd2yyz]

I really like the initial design, and I would really only changed the colors to light-green / light-red.

We should try to avoid green-red color combo in consideration for color-blindness. Dark vs light contrast would be more suitable.

[gogonzo]

@BLAZEWIM

I would not round the corners on the bars to be 101% by the book

good point

@pawelru

Going further with this idea - can it be a HTML element (i.e. bootstrap progress bar) as opposed to ggplot graph in the background? This might give you some greater styling flexibility (e.g. mouse hovering), allow JS events, be in line with the overall app theme and so on...

At this moment on the feature branch we have labels as html elements. Precisely this. Labels are independent of the shiny input ;)

Yet another control in GUI to decide which counts (and plot) to display. I don't know yet on which level should it be (overall filter setting vs change single value/bar on mouse hover). This needs to be very minimal not to "overcrowd" GUI.

Our plan is to disable "filtered counts" through api (set by developer on init) #188

How about label the values -> put everything right, smaller font and add label, e.g. "Overall: XX \n Filtered: YY"
Some labels can be very long unfortunatelly and additional text could cause some spacing problems

@lcd2yyz

I would like to understand the reasons for considering alternative display formats - were there specific technical challenges/limitations/restrictions we cannot overcome with the initial design? Because I do not think any concern were brought up on this particular feature during the design phase.

No technical challenges anymore, this issue is created as people were confused (including Paweł now) when I put PR for the first time. I'm trying to dig into the reason and propose something or convince others that initial design is a right one.

[nikolas-burkoff]

I also think it's confusing after #205 which is an improvement as it shows (xx/yy) where yy is number unfiltered and xx is number filtered by other filters excluding the current one you get:

and then:

This is nicer as the labels do not depend on whether the boxes are checked - which is consistent with the old way of doing things (i.e. if you deselected M it did not replace (500) with (0) in the label).

However some users may? think "the checkbox isn't working" -> I think we need some explanation i.e. above the checkboxes have some text saying what the labels mean.

[nikolas-burkoff]

[lcd2yyz]

There were no questions or concerns voiced during our user group demo session, so let's simply stick with what we have implemented already.