Agenda Search & Filter

[n8ebel]

provide users with a means to search and/or filter for specific topics, speakers, etc.

• The search should work also offline
• The search should be a full-text search on the agenda

[AniketSK]

In my understanding, this implies we need:

UI:

1. A search icon for the AgendaFragment, possibly at the top right, that expands into a textfield when tapped and allows you to type.
2. As you type, the items in the active day fragment below it drop off if they don't match.
3. A number appears next to the name of the day fragments, to tell you how many matches each day has.

Local Backend:

1. Data is already available offline since firebase disk persistence is enabled (line 21 of FirebaseHelper). So search will work offline out of the box.
2. I'd like to refactor the way data is being retrieved in AgendaDayFragment to abstract it a bit. Suggestions on architecture? Maybe MVVM + Dagger. Then a fulltext search with rx on the agenda items to filter the data.
3. Applying the changes with a bit of diffutil to the recyclerview that's holding the data.

I'd assign it to myself but it isn't letting me, perhaps someone could do it for me?

[amanjeetsingh150]

I want to add something here if it is possible we have to think that on what basis the filter will allow users to search. We have to think different criteria for example: if it possible to tag the data on categories we can allow searching on tagged phrases like UI/UX related talks, architecture based talks, search on basis of session name and speaker name.

I can help in designing this filter function of this feature.

[AniketSK]

Hey @amanjeetsingh150 , glad to have more eyes on the issue! I like the idea of also showing the tags. I think from a product perspective, the tags should be suggested to the submitter when they're writing out the talk proposal. Then they can edit or add to that list, which subsequently ends up as data for us directly associated with the talk. We could try this tagging app side, perhaps even adding to an index to the full text search? Your idea of tags would also be helpful to just display all the time in the UI of the list of talks itself. Do you think tags should be highlighted separately somehow while we're doing a fulltext search on the agenda?

[amanjeetsingh150]

We can discuss over more different criteria which can be used while applying filtered search. Maybe a discussion can bring more ideas.

[ademirqueiroga]

I was thinking in having a filter icon (maybe to the side of the search box) that when you click you can select the tags that you want to filter. IMO, thinking about UX, filtering with the tags are a really good and fast way to achieve what the user want.

[kenyee]

"So search will work offline out of the box." Not sure if you followed the Droidcon slack post I put up last week, but Firebase RTDB doesn't have search built-in...we have to implement it ourselves... If they enter tags with the talk proposals, it'll certainly help, but we also need a discussion of our backend...I'll bring this up in the slack channel.

[AniketSK]

@ademirqueiroga sure, I only mentioned fulltext because that's what the original issue referenced. Perhaps a pure tags based system might work better. What about names? Do they become tags? @kenyee I didn't mean we'd use their search, yes we'd build out our own version, just taking in data that's available offline.

[AdamMc331]

I'd be happy to help on this. :) Can't self assign yet, someone will need to send me an invite.

[AdamMc331]

I forked this and starting tinkering with Search Dialog.

So far I've gotten filtering successful, but what I haven't yet sorted out is:

1) I can't remove the filter and go back to the original list 2) Once I filter, there's no visual indication in the search dialog of what was searched last, and I think that would be really helpful.

If anyone's worked with Search Dialog and has some insight on those two things, I'd appreciate it. Here's a sample:

[AdamMc331]

As a tangent, this screen doesn't have an empty state, we might wanna make a separate issue to note that.

[shalomhalbert]

What is our process for breaking this down into small tasks?

[AdamMc331]

I was hoping for the above to mostly be a proof of concept with the built in dialog - hope it didn't come across as hijacking this ticket haha. The issues I called out above, as well as an inability to see search history, seem kinda tricky. As far as breaking it down, I think we can call out some acceptance criteria:

• Implement some search view that accepts text
• Filter the list based on that text
• Allow the user to clear out their current search
• Allow the user to select from their search history too (seems like a bonus)

Is there anything missing? How do we spread this across each of the people interested?

[n8ebel]

As a followup to Saturday's meeting...

1. Local search for titles, names, keywords seems like a pretty viable approach that doesn't require any backend changes

2. We could also leverage the Track, Room, and Section entities of the SlidesUp api to provide some filtering capabilities for things like "Kotlin talks on Day 2"

3. Local search, and filtering seem like pretty separate paths of development as long as we can come up with some clean design for integrating both of them

4. Looking at the demo above, and thinking of some of these issues, I'm wondering if it might be a good idea to have a specific search/filter screen. My thinking being that this could make it easier to integrate into the app and easier to display any pre-existing filters or past search results. I'm taking inspiration from the Android Summit app here where tapping on the FAB opened a filter screen

5. Definitely agree with @AdamMc331 that we should add an empty state as part of this search/filter

[kenyee]

For "We could also leverage the Track, Room, and Section entities of the SlidesUp api to provide some filtering capabilities for things like "Kotlin talks on Day 2""

We can't leverage much of their API...remember that our DB is Firebase sync'd w/ clients. And the local queries are super crude (on the lines of "for this single index key, look for this"). Adam is probably just iterating the sessions tables and running regexes or string searches on the titles or body content :-) Also, it looks like we're going to keep using SlidesUp. There was no API last year, so the process was "get export from them, run script to munge it so it fits our app screens, then import into our own firebase DB". Now that they have an API, I can see if this can be automated, but this brings up a host of other issues. E.g., do we use the same SlidesUp site? Or a new one? If the same one, how is the data partitioned between last year and this year? Is there an API to detect changes? How often to we poll for changes? Do we need any more schema changes to support the features we want to add?

[n8ebel]

@kenyee i do think ideally we would keep using SlidesUp

looking at the docs for the api, they claim that you can use Firebase to interact with the data directly, so I'm curious if we need to maintain the scripted export process and if we need a separate Firebase instance. Actually, thinking a bit more about this, if the data store is just a Firebase instance I wonder if there is anything stopping us from adding things to the data model if it suited our needs. @GiorgioNatili we have a SlidesUp account already set up don't we? I'd be interested in playing with the new api and seeing how flexibly we can interact with it.

As for how we can differentiate between 2018 & 2019, it looks like if we define separate top-level Conference objects in the DB we could separate the years. something like confs/list/droidconbos19 and confs/list/droidconbos18

[kenyee]

I think we need our own instance because they won't let us muck w/ the permission rules in their instance :-)

We probably need some sort of import into our firebase instance just because our schema for the app is different, unless we rework the app to read their schema (which is ugly because Firebase). But then we still need to maintain our own login info on our instance...

[AdamMc331]

Regarding Ken's earlier comment about how I did the filter, I was just utilizing the filter capabilities that come with the RV lib we're using (the FlexibleAdapter).

Here's the filter method:

override fun filter(constraint: String?): Boolean {
        return if (constraint == null) {
            true
        } else {
            (itemData.talkTitle.contains(constraint, ignoreCase = true)
                    || itemData.talkDescription.contains(constraint, ignoreCase = true)
                    || itemData.speakerNames.any { it.contains(constraint, ignoreCase = true) })
        }
    }

The search query was set via livedata that I listened for in the AgendaDayFragment:

private fun listenForSearchQueries() {
        (activity as? MainActivity)?.searchQuery?.observe(
            viewLifecycleOwner,
            androidx.lifecycle.Observer {
                headerAdapter?.setFilter(it)
                headerAdapter?.filterItems()
            })
    }

The reason I didn't submit for a PR tho is I ran into other issues with the search dialog. It allows me to search for something, but I can't clear my search to go back to the original list, unless I'm overlooking something. Has anyone used it before/has rolled their own search view?

[n8ebel]

@AdamMc331 @sagar-viradiya @amanjeetsingh150 @shalbert94

How are things going on this ticket? Do we need to assign an "owner" for this? Are there any blockers currently to implementation?

[sagar-viradiya]

@n8ebel I am focusing on twitter integration. If folks here would need any help let me know.

[AdamMc331]

@n8ebel I never got past figuring out how to maintain search history with Android's Search Dialog. :( Was hoping someone had experience with this idea. Otherwise I'll take a look at some search view libraries and see if I can find one that works well for this.

[AdamMc331]

I'm a little closer in that I can reference the state, but I wanna verify some behavior: The search should apply to both fragments, right? In this gif below it only applies to the one. I'm pretty sure the answer is yes but I just want to validate that.