Staking Pools: Filter UI could be simpler

[patrickgparity]

Current UI in Discussion URL: Here (click All pools tab)

Problem:

• There are redundant steps and interactions in the filtering UI components; this slows users down
• The filter options are hidden behind a modal; reducing discovery
• You have to return to the model to enable/disable filters; making it time consuming
• Having to select what to include and select what to exclude creates cognitve overload (In this case; two things that look the same function differently)
• The heading "Active Pools" conflicts with the results shown and filters active (i.e if you have active not selected, this text still says "Active Pools".

Solution:

• Remove Modal
• Switch to a toggle component UI, with an active state for "include in results" and a deactivated state for "excluded".
• The UI component styling should resemble the search bar and other filter options for users to associate them as related functionality that impacts results displayed. (Colour, size, border radius, etc)
• Change "Active Pools" heading to "Pools"
• It's important to group the toggle-pills together to prevent a visual mess in future if additional filter options are added.

Updated with proposed changes:

• This UI indicates that "Active" Pools are displayed, but that "Locked" and "Destroying" are excluded.

[polkadotcurry]

@patrickgparity This "group toggle-pills together" component feels like single selection tab to me: Where I can only view Active OR Locked OR Destroy.

This still satisfies core case of "defaulting to active only on landing" and I do not think I mind the isolated views for Locked OR Destroy. Is this the intent for interaction?

[rossbulat]

I would have saved you a lot of time here if I was consulted on this. I strongly disagree on the assumptions that the filters are cognitive overload - they are fine as they are and people will know how to use them.

I also think "include active validators" is a lot more intuitive than "exclude inactive validators". The reason I am excluding all others is because I want to include only the active ones.

Yes, they can be further abstracted / simplified, and this is known, but I did not not jump into a second abstraction so soon after this base one since it is an entirely refreshed system at play, and designing a second abstraction over this base takes time and involves entirely new components that may not be generic across all lists. Further abstractions require the concept of inclusions and exclusions; the logic in place now lays the groundwork for more intelligent filters that can combine them.

The filter context & logic in place now was intentionally designed to be the base layer and generic across all lists that need filtering. the overlays offer an instant way to summon filters that could be infinitely expanded without interfering with the main interface. This is good UX that works across all form factors, and will be fine until I have time to iterate the filter system.

[polkadotcurry]

@rossbulat The "Filters" itself are fine. I would agree that there is room to improve UX. I am not clear on priority or challenges.

From my view, we could use to set two types of workflows:

(1) Bugs / Typos / Etc... - Just drop into Github - I think we are good here. (2) Proposals / Recommendations on UX - We could use the fastest, most efficient path for vetting ideas and proposals in/out so we can spend time on working on what needs to be done. There's a few ways I can see that working for a remote team.

My understanding from our chat was that proposal discussions (like this) should happen in Github so I pointed @patrickgparity here for that review. If we can save time using another workflow, method, venue - let's do that.

Need to switch gears and pull data for rest of the day. We can connect at the next convenience.