@gonyeahialam @ifried I have a few questions:

• Could we make the "filter events" button open a smaller window directly below the button itself instead? See for instance the "saved filters" and "X changes, Y days" filters here. This seems a bit easier to do and more in line with other filters I could find (Growth's mentor dashboard has a similar one)
• I'm not sure if the search button should be directly after the search bar and whether its label should read "Search", given that you would also use that button to apply filters
• Should the form (search + filters) have a legend? That would look like the second picture, with a border around the rectangle and the legend being displayed at the top left. Aside from consistency with other pages, tt would also be helpful for grouping the search field, the filters, and the "submit" button, that would otherwise have no common container.

Change 793853 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Implement filtering for "Your events" table

https://gerrit.wikimedia.org/r/793853

Change 793865 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] [WIP] Implement JavaScript widget for filtering the list of events

https://gerrit.wikimedia.org/r/793865

@Daimona, in response:

1. I think it's fine if the filter behavior opens a small window below the 'filter events 'button because: 1) It follows existing wiki behavior and we want to strive for UI/UX consistency as much as possible, 2) It still is easy for the user to apply the filters, 3) It may actually be preferable because it doesn't create confusion between search + filter, and 4) It will save engineering time and effort (which is a big concern for V0).
2. I suppose this second question depends on whether or not we change where the 'filter' function appears. I think it makes sense for them to be separate processes in separate sections, so in that case, we could probably keep the 'search' menu as is and change the filter behavior to be as described in #1.
3. Yes, legends can be useful in the future, but I don't know if it is necessary for V0. I think 'search' is self-explanatory enough, so that just leaves filters.

What do you think, @gonyeahialam?

In T308611#7945587, @ifried wrote:

2. I suppose this second question depends on whether or not we change where the 'filter' function appears. I think it makes sense for them to be separate processes in separate sections, so in that case, we could probably keep the 'search' menu as is and change the filter behavior to be as described in #1.

I'm not sure if it depends on the location of the "filter" button. In the screenshots above, it seems to me that the "Search" button is already used for filters, too.

Also, this is a demo of what I've got so far: https://patchdemo.wmflabs.org/wikis/e841a3d656/wiki/Special:MyEvents (user: Alice, pass: patchdemo1).

Hey @Daimona, I checked out the demo link; thanks! I see that search is working. I'm not really clear on how to use the filter though. Any tips? Thanks in advance.

In T308611#7951266, @ifried wrote:

Hey @Daimona, I checked out the demo link; thanks! I see that search is working. I'm not really clear on how to use the filter though. Any tips? Thanks in advance.

The current behaviour is that you click on "Filter events" to open the options, select whichever you want, and then submit the form using the same button that you use for searching.

In the demo, the filter and search have the same button. As described in T307588 they should be separate functions. The search is to find a specific event using a keyword as the only parameter, the dropdown is to change the list of events shown to closed, open, or all events. cc @ifried

@Daimona What challenges are you having with implementing the search and the dropdown separately?

The simplest design for this was the previous design(shown below), if this is something we can do, it will be the best solution in terms of usability.

Could we make the "filter events" button open a smaller window directly below the button itself instead? See for instance the "saved filters" and "X changes, Y days" filters here. This seems a bit easier to do and more in line with other filters I could find (Growth's mentor dashboard has a similar one)

Yes, we could do this @Daimona. What happens when there are more filter options?

In T308611#7957495, @gonyeahialam wrote:

In the demo, the filter and search have the same button. As described in T307588 they should be separate functions. The search is to find a specific event using a keyword as the only parameter, the dropdown is to change the list of events shown to closed, open, or all events. cc @ifried

@Daimona What challenges are you having with implementing the search and the dropdown separately?

Aren't they using the same button in the screenshots above? I think it should be possible to have two separate buttons, I would just need to know how the filter button would look like.

The simplest design for this was the previous design(shown below), if this is something we can do, it will be the best solution in terms of usability.

We would also need a separate button for this one. Also, I think this is not very scalable, especially if we want to add more fields. Currently, we also have the dropdown for how many events to show on each page, and not just the one for event status.

In T308611#7957617, @gonyeahialam wrote:

Could we make the "filter events" button open a smaller window directly below the button itself instead? See for instance the "saved filters" and "X changes, Y days" filters here. This seems a bit easier to do and more in line with other filters I could find (Growth's mentor dashboard has a similar one)

Yes, we could do this @Daimona. What happens when there are more filter options?

It would be like you see in the demo. It could have its own button, or use the one on the main form.

@Daimona, what are the questions we would need answered to get this ticket unblocked? Thanks in advance.

In T308611#7963783, @ifried wrote:

@Daimona, what are the questions we would need answered to get this ticket unblocked? Thanks in advance.

Whether there should be separate buttons for searching and the other filters (which I think might have been answered at the design workshop), and how to make search and filters work together (in the interface; in the code, they're already usable together, and it's actually harder to separate them).

Thank you, @Daimona!

It is my preference that search and other filters are separate, so that the organizer has more options available to them. I also think it is a less confusing user experience. I am neutral in how they work together.

We would need feedback from design to unblock this ticket, so pinging @gonyeahialam & @CKMIE89. It's high priority to get this ticket unblocked. Thanks!

@ifried @Daimona We can explore how the two can work together in V1 or V2

This is a good case where ideally we would need to have a good idea of the design options to design prototypes that reflects our questions.
At this point I think an educated guess by senior designers could help, if we have a version we can test. If we do, happy to put 2 YUX designers on it, and they can discuss with Gregory on the pros and cons of each.

Just to clarify: from a technical standpoint, having search and filters work together is not harder than separating them; in fact, it's more like the opposite. That's because searching is just "filtering by event name", after all. I'm not sure what the design-related concerns are with having search and filters work together; perhaps it could be better if we change the label of the filters button to "Additional filters" or something like that?

My naïve guess is that search + filters together could become even more useful if we add more filters (e.g., online/in-person/hybrid, show/hide past events, only events in X country etc.). The "events per page" filter already seems a good candidate for use together with search, e.g., if you have many "Wiki loves X" events.

Having a "search" and a 'filter" option is quite common. I quite like your suggestion @Daimona

I agree that search and filter should be separate options for the user, and they should be able to combine both actions simultaneously. This allows users more flexibility to find what they need, especially for power users who may have a very large number of events over time. In that case, @Daimona, I'm happy to hear that it would not take much more technical work compared to the other option and this is the solution I would advocate for.

@Daimona @ifried As an interim solution (pending future improvements after V0/V1), we can have the basic search at the left as it is currently

I am talking with @Daimona now about this topic. He has already implemented search and filters as separate functions that can be used simultaneously, and it is available on patchdemo for anyone who wants to test (see first screenshot below). Because it is already implemented, and it fulfills the main criteria for what we expect from the user experience, I consider this work sufficient for V0. Additionally, this conforms with existing user flows and potential expectations on the wikis, as there are many other pages that function in a similar way by allowing search + various filters to be applied simultaneously (see screenshot examples below). However, I have also talked with @gonyeahialam about the fact that this change did not include design input, and we especially want for V1 and later to have all user experiences go through design feedback and usability testing cycles. For this reason, we'll revisit the UI for V1 and we may make changes based on feedback from design and design research. Thank you!

Current behavior on patchdemo:

Example of other search/filter views in wikis:

Example of other search/filter views in wikis:

Example of other search/filter views in wikis:

Great! Is there a link for us to test on patchdemo?

In T308611#7971265, @CKMIE89 wrote:

Great! Is there a link for us to test on patchdemo?

Sorry, I've just seen this comment... You can test it here (user:Alice, pass:patchdemo1), but note that it's not final (e.g., the buttons should be changed).

Change 793853 merged by Cmelo:

[mediawiki/extensions/CampaignEvents@master] Implement filtering for "Your events" table

https://gerrit.wikimedia.org/r/793853

In T308611#7979505, @Daimona wrote:

In T308611#7971265, @CKMIE89 wrote:

Great! Is there a link for us to test on patchdemo?

Sorry, I've just seen this comment... You can test it here (user:Alice, pass:patchdemo1), but note that it's not final (e.g., the buttons should be changed).

👍🏽👍🏽👍🏽👍🏽 thanks

In T308611#7970959, @ifried wrote:

I am talking with @Daimona now about this topic. He has already implemented search and filters as separate functions that can be used simultaneously, and it is available on patchdemo for anyone who wants to test (see first screenshot below). Because it is already implemented, and it fulfills the main criteria for what we expect from the user experience, I consider this work sufficient for V0. Additionally, this conforms with existing user flows and potential expectations on the wikis, as there are many other pages that function in a similar way by allowing search + various filters to be applied simultaneously (see screenshot examples below). However, I have also talked with @gonyeahialam about the fact that this change did not include design input, and we especially want for V1 and later to have all user experiences go through design feedback and usability testing cycles. For this reason, we'll revisit the UI for V1 and we may make changes based on feedback from design and design research. Thank you!

@ifried Sorry for the delay, I've just read this comment carefully. Does this mean that the current behaviour on patchdemo is already good for V0? If so, this task can be moved to "in review".

Also, following up to a conversation with @CKMIE89, the search function is currently case-sensitive. Unfortunately, I don't think this is easy to change because of a limitation in the database abstraction layer that we use.

@Daimona: Yes, what we have on patchdemo is sufficient for V0 and can be moved to 'in review.' Further improvements can be tackled in separate tickets for V1. Thanks!

Change 793865 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Implement JavaScript widget for filtering the list of events

https://gerrit.wikimedia.org/r/793865

I'm noting here explicitly that there are a couple differences between the wireframes and the actual implementation:

• The search button is different and on its own line, because it also applies filters (not just the search)
• There's no button specific to the filtering options because we said that search and filters would work together.

Given Ilana's comment at T308611#7970959, it is my impression that the interface will be tweaked again later on, and that what's on patchdemo is already sufficient, so I assume that those two differences would be acceptable.

In T308611#7989956, @Daimona wrote:

Also, following up to a conversation with @CKMIE89, the search function is currently case-sensitive. Unfortunately, I don't think this is easy to change because of a limitation in the database abstraction layer that we use.

This is probably a problem for usability. Can we add a message somewhere to note that the search is case sensitive? This would be a minimal workaround until we can get a search that works with less constraints. @gonyeahialam this would mean adding a note near the search button.

In T308611#7999602, @CKMIE89 wrote:

In T308611#7989956, @Daimona wrote:

Also, following up to a conversation with @CKMIE89, the search function is currently case-sensitive. Unfortunately, I don't think this is easy to change because of a limitation in the database abstraction layer that we use.

This is probably a problem for usability. Can we add a message somewhere to note that the search is case sensitive? This would be a minimal workaround until we can get a search that works with less constraints. @gonyeahialam this would mean adding a note near the search button.

Yes, we can add an inline help (example) for that. Unfortunately there's no easy way for us to fix this; I've filed T310558 about it. Even if that's fixed, I should note that searching by substring (as opposed to e.g. searching by prefix) could have performance implications, because the search happens in pure MySQL and not something like ElasticSearch or MySQL's fulltext search utilities.

I think the inline would be great. 👍

In T308611#8000855, @Daimona wrote:

In T308611#7999602, @CKMIE89 wrote:

In T308611#7989956, @Daimona wrote:

Also, following up to a conversation with @CKMIE89, the search function is currently case-sensitive. Unfortunately, I don't think this is easy to change because of a limitation in the database abstraction layer that we use.

This is probably a problem for usability. Can we add a message somewhere to note that the search is case sensitive? This would be a minimal workaround until we can get a search that works with less constraints. @gonyeahialam this would mean adding a note near the search button.

Yes, we can add an inline help (example) for that. Unfortunately there's no easy way for us to fix this; I've filed T310558 about it. Even if that's fixed, I should note that searching by substring (as opposed to e.g. searching by prefix) could have performance implications, because the search happens in pure MySQL and not something like ElasticSearch or MySQL's fulltext search utilities.

@Daimona is the inline help example to show that the search is case sensitive something we would be able to add in by v0 release?

In T308611#8052140, @vaughnwalters wrote:

In T308611#8000855, @Daimona wrote:

In T308611#7999602, @CKMIE89 wrote:

In T308611#7989956, @Daimona wrote:

Also, following up to a conversation with @CKMIE89, the search function is currently case-sensitive. Unfortunately, I don't think this is easy to change because of a limitation in the database abstraction layer that we use.

This is probably a problem for usability. Can we add a message somewhere to note that the search is case sensitive? This would be a minimal workaround until we can get a search that works with less constraints. @gonyeahialam this would mean adding a note near the search button.

Yes, we can add an inline help (example) for that. Unfortunately there's no easy way for us to fix this; I've filed T310558 about it. Even if that's fixed, I should note that searching by substring (as opposed to e.g. searching by prefix) could have performance implications, because the search happens in pure MySQL and not something like ElasticSearch or MySQL's fulltext search utilities.

@Daimona is the inline help example to show that the search is case sensitive something we would be able to add in by v0 release?

I created T312229 for fixing that, I'd rather try and see if there's something we can do, before adding that kind of temporary warning.

@ifried a couple of things from this comment thread to point out, and things from this ticket that still need to be addressed:

per your note in T308611#7970959, this is one of the tickets that will need to be revisited for UI design feedback in V1

also T312229 is for the issue of search not currently being case insensitive, when it should be