Refactor default search

[joshreisner]

Search default should be words in any order, case insensitive, all matching.

Earlier discussion in #77

sober living and living sober should return the same results, right now they do not

searches should exclude meetings without all terms present

Secondary objectives:

• quotes enforce the order of search terms ("living sober" should match only those meetings with those words in that order)
• OR keyword

[FlipperPA]

Hmmm, are we sure about this? My thoughts circle back to locations, like 123 Main Street, West Chester versus 123 West High Street, Chester. @leggomyinfo had requested the current behavior to search by phrase as the default, in issue #77.

[joshreisner]

@leggomyinfo perhaps you can clarify, but my understanding of #77 is that you were requesting AND logic. So with the two meetings above, searching West Chester would match both meetings, because both meetings have both West and Chester. But crucially it would not match any meetings that only had one West or Chester.

Searching "West Chester" would only match the first result.

[leggomyinfo]

@joshreisner nailed it here with what I was asking for. Comparing what he wrote here to my request in #77, I'm realizing my request could have been clearer.

[joshreisner]

@leggomyinfo i think i've got it, hopefully. it's already live on aasfmarin.org/meetings. let me know if you see any issues

@FlipperPA i temporarily set it to show sepia's meetings on react.meetingguide.org so that you can test it out. i tested it with your cases and it seems good. you should be able to use OR and quotes. lmk what you think!

(FWIW, i noticed center city west and gayborhood don't return results on aasepia.org, so those examples should prob be updated)

[leggomyinfo]

@joshreisner It's working! Great stuff.

One counter-intuitive aspect: It searches fields that are not present on the page, such as meeting note. I wonder if it makes sense to limit the search only to information displayed on that page.

[FlipperPA]

@joshreisner Thanks! This looks great. I just wanted to make sure we covered Fred's use case. Good catch on the Gayborhood, I'm wondering why it isn't showing anymore!

[joshreisner]

Great!

@leggomyinfo some groups have requested to search by meeting details (in particular ZIP codes, districts, and GSO numbers). Happy to consider specific cases though. Here are the fields we're using.

Going to close this but if either of you can think of improvements lmk.

[leggomyinfo]

I recommend reversing the default approach: exclude anything that doesn't appear on the results page from the search string unless there's a compelling reason not to (e.g., enough people want to search by district). For example, I would remove meeting.group_notes, meeting.location_notes, and meeting.notes.

If there is a field that regular people* are trying to use for search purposes which is not on the results page, that begs the question: why is it not displayed in the results page? For example, let's assume zip code is something regular people are using to search — in that case, it might make sense to append the zip to the street address in the pill.

*Regular people = those who are using TSML to find meetings, rather than as a way for trusted servants to search their meeting data or power users who don't realize that accommodating their idiosyncrasies makes the tool less usable for most people

For the record, I don't have any direct evidence that including meetings in search results with no discernible connection to the search terms is creating problems for anyone (other than my own confusion until I realized what was happening). My understanding is that it's a best practice for search interfaces. I've asked my partner to see if she has any research on it; she was the product manager for a redesign of a search interface for an enormous database/library services co.

One last thought: I do think down the line some advanced search interface would make sense, like Gmail's. That could include multiple search boxes which correspond to fields which are not displayed in the search results (e.g., District: [....]; ZIP: [...]; etc).

[FlipperPA]

Unfortunately, some groups rely on search bringing up those fields. We've been encouraging web servants to use the notes field fairly extensively to avoid adding more Meeting Types.

I don't think it has been explicitly stated as such, but it sounds like we have been trying to adhere to the 80/20 rule: only put items in the interface that will be used by the 80% of users. We ask the same question when we consider putting features into the core of the Django web framework. But that doesn't mean we don't also consider the functionality the 20% need: just not in the core product. For this reason, I think leaving the notes fields in search - or, at least, making it a configuration item - is the way to go. However, displaying them on the meeting list is not feasible due to screen real estate, and the unpredictable character length of the notes field (many meetings have no notes, some have full paragraphs!).

For some of the issues we've closed suggesting to use the notes field, have a looksie: https://github.com/code4recovery/spec/issues/22, https://github.com/code4recovery/spec/issues/23, https://github.com/code4recovery/spec/issues/24, https://github.com/code4recovery/spec/issues/25, and https://github.com/code4recovery/spec/issues/27.

It is a bit of a UX conundrum, either way.

We've been using this search for about two years here in Philadelphia, and I can't recall having any complaints in the behavior; rather than 20% enjoy being able to search multiple towns within the same area, for example. But I also don't have any evidence that we'd get complaints if we were to change it, either. 😃

[leggomyinfo]

To clarify: I'm only suggesting additional information appear on the results page (core product) IF the 80% organically reference it when searching. It may be that there isn't any such information missing. If there is, however, it would make sense to revisit the search results design to consider how to incorporate it (perhaps in a future iteration if not right away). The only possibility which comes to my mind is zip code, which could be appended to the address pill. Unfortunately, as far as I know, there's no way to reliably tell at the moment what, if anything, is missing (e.g., no analytics around search terms, no recorded user sessions).

Caveat before I continue: I have not been the one putting in the legwork on this project, and hugely appreciative of the time you have dedicated to it. I am also less familiar with the technical challenges and the requests. That's all to say, take the following with that asterisk, if you will.

Looking over those tickets, it makes sense to me that you pushed back against incorporating those proposed designations into meeting types. Those requests seem to fall within what I characterized above as a "way for trusted servants to search their meeting data," for which something like Airtable is better suited. In my view, that's not a use case which should be supported, particularly to the detriment of the core user experience.

Having search results that have no discernible relationship to the search terms is to the detriment of the core user experience and functionality. There's a reason why search experiences often highlight where search terms appear within search results (e.g., color signaling, positioning, typographic contrast). This is especially true in experiences where the user needs to decide which results to click into. It should be optimized for quick scanning and it's utility is practically defined by how easily the user can discern how the results relate to their intended search. I would be very surprised if there was anything exceptional about finding a meeting such that these best practices wouldn't apply to TSML.

Instead of creating a configuration to let Intergroups opt out of a best practice which is fundamental to TSML's core functionality, the solve seems to be to make advanced search possible. This could take the form of expanding a window to surface additional fields (a la Gmail's advanced search) and/or the ability to write in search operators (e.g., meeting_note: living sober). I'm guessing the latter would be much easier to implement and probably more than satisfactory (maybe even superior to the status quo) for the trusted servant/power user. In the meantime, I would prioritize core functionality/best practice over the concession to trusted servants/power users ("just put your wish list in the meeting notes since it will be searchable").

Assuming we don't all agree on the above, are there any fields which we agree should be immediately removed from search? Perhaps meeting.regions?

One last thought specific to meeting types: I've long lobbed under-informed feedback at Josh that Code For Recovery should consider getting out of the business of regulating meeting types. I think Intergroups should have the ability to define their own meeting types. In concert, I would write up a guide about why they should resist their instinct to go crazy, as some assuredly will regardless. (The guide is something I would be happy to contribute to.) The only thing which gave me pause is the way that Meeting Guide draws from TSML instances, but since Meeting Guide development is probably cryogenically frozen within GSO, it's probably less of an issue now. Ideally Intergroups could also map their meeting types to Meeting Guide types.

Alright, let me know what I'm overlooking. I'm sure there's quite a bit!

[joshreisner]

I understand and appreciate the philosophy of only searching what's visible, but my imagination is feeble and I need to see examples of searches that go awry with too many indexes. Do you know of any offhand? Has this been reported to SF Central Office?

no analytics around search terms

We can do something about that. I see that SF already has Google Analytics installed, so I've created a ticket to see if we can push meeting finder search terms in there.

I bet regions is commonly-searched. A new user might not immediately discover the "Anywhere" dropdown and just type "Nob Hill" straight into the search box. (The topmost of the regions is visible on the list page.) I could see the rationale of not indexing parent regions, but it doesn't seem implausible that someone might type "Marin" in there.

Types is part of a separate conversation that gets at how much autonomy should there really be and to what degree should these products be customizable. But I don't want to get into in in this thread for fear of losing focus on search.

[leggomyinfo]

You've called my bluff 😉: I am not aware of any reports to SF Central Office regarding search, at least beyond the firehose of complaints related to the previous search logic. I just pinged the team to see if anything's come in since. I'm not sure if you're implying it, but I do think the existence of verifiable complaints is generally a good litmus test for whether something warrants attention. I'm drawing on my ample supply of overconfidence as a poor substitute.

My suspicion is that the extra results make things more confusing by having more results to sort through, especially when it's not clear why they are there. Unlike the last issue, however, it is probably not preventing users from finding the meeting altogether. My guess is it just breeds some mild confusion and slows them down. Given what folks expect from AA in terms of technology, I doubt anyone would bring this to our attention.

Here's my hypothesis about the effect including meeting.regions might be having. It's premised on an assumption that when people type a geographic term, like "Marin," into the search field, they are usually looking for one of the 21 meetings with the word "Marin" in the name. Those 21 meetings will appear amidst hundreds of other results. To the extent folks are using the search field as a geographic filter, I think we're better off learning them into using the actual filter rather than duplicating that in the search field.

I think seeing what we can learn from Google Analytics is a phenomenal idea! I'm already tired of my own suppositions.

[leggomyinfo]

I just updated the Meeting Finder FAQ to reflect the changes. Any feedback is welcome.

---

Here's a screenshot of the section which was replaced:

---

Beating dead horse: I think a good aspiration is to work towards a meeting finder which requires no FAQ.

One thing which I noticed is that if you type "ca" every single meeting appears in the results because the state abbreviation is within formatted_address. In the short-term, can we remove that? Most Intergroups don't cross state lines and, for those that do, I doubt people are trying to search by state abbreviation.