Design: Finder-style multiple AND and OR filters

[jdanish]

We have multiple contexts in which it'd be nice to use AND and OR during filtering. This would only apply to string types. Long-term we talked about more complex / interesting UI. Short term, just being able to type "friend & foe" or "friend | foe" would be great (or something similar).

[benloh]

@jdanish Maybe we use && and || so that ampersands are not inadvertently treated as ands?

I suppose we could add a UI to add "and" and "or", but that gets more complicated, e.g.:

1. Option to add "+" parameter

   label [ contains ] [ friend ] [ + ]

2. Show "and" or "or" menu

   label [ contains ] [ "friend" ] [ + ]
     [ and ] [ ________ ] [ + ] [ x ]

3. Select a value and enter a string

   label [ contains ] [ "friend" ] [ + ]
     [ or ] [ "foe" ] [ + ] [ x ]

4. Add a third

   label [ contains ] [ "friend" ] [ + ]
     [ or ] [ "foe" ] [ + ] [ x ]
     [ or ] [ "frenemy" ] [ + ] [ x ]

We could also keep it simple. That somewhat simplifies things so you don't have to handle groupings.

[Updated mockup to include trash]

[jdanish]

Long-term I was thinking the + button (and it’d need a trash too I presume).

Short-term, the && or || would be great along with some additional help-text on-screen to note that that will work (I can draft)/

If the other re-architecting will impact the long-term solution I’d say to go for the quick and dirty for now and shift later?

I’d have to ask the team but I wonder if having both options long-long-term would be nice because experts will want to type and novices will prefer the + etc? Just throwing it out there.

[benloh]

Ah that makes sense. I'll go with the text option for now to preserve budget.

[jdanish]

Sounds good. I imagine the long-term version would also include an architecture discussion with @dsriseah so that we can make sure we have a nice modular and extensible approach :)

Thanks!

[benloh]

Moving design discussion to next iteration. Implementation will be in next PR.