UX: clean up search/filter

[rkaufman13]

We ought to decide how we want search/filter to look. Right now there are 8 things people can click on on projects, scattered around various parts of the page, and it's starting to look messy. It would be great to clean this up.

Options (we can do one or more of these):
-Hide most features under an "advanced search" tab
-Tweak the visual appearance of the filters/etc so they line up a little nicer
-Change to global search vs search on columns
-I would really like to use EITHER taxonomy or topic, I think having both issues and topics is confusing to the user. Since taxonomy is not fully ready yet, one possible solution is to make issues/taxonomy an "experimental feature" and allow folks to enable it with a setting saved to localstorage?

[giosce]

visual appearance by lining up could be the first (easy) thing to do, and reduce the white space between the header and title.
I'm not sure on EITHER taxonomy or topic, this Taxonomy works encompassing topics, I think it's ok to show that, at least until we feel the Taxonomy is more complete and correct.
I'd prioritize to remove a lot of tags from topics, not sure if making another selector for technologies and what to do about "location".

[rkaufman13]

Here's a figma with a proposed layout:
https://www.figma.com/file/ZDM4bySe7ufjP1toDHGzzr/projects-index-search-ui?node-id=0%3A1

[k3KAW8Pnf7mkmdSMPHz27]

Agreed that this is starting to become quite problematic,

-Hide most features under an "advanced search" tab

An alternative is to push them to the left on large screens. Layouts/designs like https://80000hours.org/job-board/ are quite common and imo functional.

-Change to global search vs search on columns

I'd suggest this in its own PR. It will be easier to test that no links are broken that way.

-I would really like to use EITHER taxonomy or topic, I think having both issues and topics is confusing to the user. Since taxonomy is not fully ready yet, one possible solution is to make issues/taxonomy an "experimental feature" and allow folks to enable it with a setting saved to localstorage?

Perhaps there is a way of making it less confusing to users? I could see a separator as an option, maybe with text saying something about "from the civic tech taxonomy project ..."?

To be frank, the reason I want both to be in is that I don't believe in having tags that cannot be selected, and from my point of view there is a purpose in "collaborating" with other projects.
If I'd make a guess, making it enablable as an "experimental feature" is equivalent to temporarily remove it, no one will enable it.

[rkaufman13]

Personally, I'm okay with a feature being temporarily removed/made experimental while it's still being developed, as the taxonomy is still actively being developed. Once we get a larger percentage of tags categorized in the taxonomy I'd consider it to be less experimental. That said, the figma layout I drew up last night does incorporate both issues and tags in a way that I think might solve all the problems at once?

…

On Mon, Nov 1, 2021 at 6:12 AM Jonatan Asketorp ***@***.***> wrote: Agreed that this is starting to become quite problematic, -Hide most features under an "advanced search" tab An alternative is to push them to the left on large screens. Layouts/designs like https://80000hours.org/job-board/ are quite common and imo functional. -Change to global search vs search on columns I'd suggest this in its own PR. It will be easier to test that no links are broken that way. -I would really like to use EITHER taxonomy or topic, I think having both issues and topics is confusing to the user. Since taxonomy is not fully ready yet, one possible solution is to make issues/taxonomy an "experimental feature" and allow folks to enable it with a setting saved to localstorage? Perhaps there is a way of making it less confusing to users? I could see a separator as an option, maybe with text saying something about "from the civic tech taxonomy project ..."? To be frank, the reason I want both to be in is that I don't believe in having tags that cannot be selected, and from my point of view there is a purpose in "collaborating" with other projects. If I'd make a guess, making it enablable as an "experimental feature" is equivalent to temporarily remove it, no one will enable it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEBHUR7267PBUHUTHV2X6CTUJZRY7ANCNFSM5GHYGTKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[giosce]

I agree on the goal of this. Some questions on the figma design:
a) The basic search will search by?
b) It could be ok to not have the time-period in basic search because now we have sort by "last push" (by default but maybe it will not always be active between interactions?).
c) You would show 2 level of Taxonomy Issues? Second level will have the current "topics" as categorized so far in Taxonomy, right? What to do with uncategorized topics?
d) I think we want to keep also the Priority Areas dropdown and thinking of space, I'd like to add "has website" and maybe a dropdown of technologies (and/or skills).

I have concern with point "c", somewhere we need to have all the topics retrieved from the crawler.
Two more thoughts on this filtering:
Remove some topics (the ones categorized in Taxonomy and those that are brigade names, events, technologies)
Remove the Taxonomy topics and substitute them with the Taxonomy item in the same huge multiselect (maybe in bold or other font)

[rkaufman13]

a) Global search, I think
b) I think so, although I'm not sure what you mean about being active between interactions
c) The two multiselects are meant to signify taxonomy issues on the left, topics (including uncategorized topics) on the right. Selecting one or more issues on the left would automatically select the appropriate topics on the right, but users could add or remove individual topics as needed. Does that make more sense/address your concerns?
d) I agree it would be great to have technologies/skills as another two multiselects. My understanding is that even though those categories are in the taxonomy they might not yet be used to categorize projects and/or aren't exposed in the data we get from the crawler, so it seems premature to add those, but I would love to have them as filters going forward.

Not sure what you mean about removing topics or substituting them with taxonomy items, but maybe my explanation of c) helps clarify?

[k3KAW8Pnf7mkmdSMPHz27]

1. (a) With global search, I am currently assuming it means case-insensitive text search in all columns.
2. (b) I don't think we store sort states -> upon revisits it will be sorted by "last_push" again (and even if we do store the state, can't the user change it if they want?)
3. (c) Some thoughts on "issues" multi-select (the right one)
   1. How do you search in the list? It is possible with the default behavior of a multi-select or can it be added in a simple fashion?
   2. Can we sort so that the selected issues are always on top? Or is there a better way of displaying which issues are selected?
   3. (Note to me) Clear all button
4. (d) Is there a longer text somewhere about what the Taxonomy is? I think there is something here I don't understand. My current understanding is that the Taxonomy has a tree structure, where the children of the root are (right now) are issues, priority-action-areas, skills, statuses, technologies and every "leaf" of the tree is either a project tag (as provided by the crawler) or Null (when there aren't any associated tags yet). Is this understandable and correct? I.e., none of the "branches" exists in the data provided by the crawler, but the "leaves" do.

A short(er) summary of my thoughts. The figma design keeps growing on me every time I look at it 😛
The multi-select is an improvement and if it isn't too much work to implement it, I'd say go ahead (and don't feel forced to use downshift).

I'd propose considering/discussing a tree-view (I know @giosce found some tree library he liked but I can't find the link right now, so something like react checkbox) for the taxonomy in a follow-up issue. Does that make sense?