Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add optional filter for map and search results #288

Open
sgelb opened this issue Aug 26, 2018 · 12 comments
Open

Add optional filter for map and search results #288

sgelb opened this issue Aug 26, 2018 · 12 comments

Comments

@sgelb
Copy link
Collaborator

sgelb commented Aug 26, 2018

As an user, I'd want to be able to filter the users shown on the map and in the search results.

I would not create a huge list of filters, but start with availibility, number of maximum guests, preferred notice and languages spoken. These values are essential to decide if a user is a potential host. And they are already set in User.

What do you think?

In regard to the search results, this relates to #235.

@PattaFeuFeu
Copy link
Collaborator

Absolutely!

@jeanfrancoisbeaulieu
Copy link
Contributor

I had been pushing for this on the website for years now before it was out-sourced.
I think availability is on by default (or it might have changed).
In dense area, I've always wanted to filter last online , has comments and member since.

@saemy
Copy link
Collaborator

saemy commented Aug 27, 2018

Yes, great idea. And maybe in the future we also get support from the REST API for this (to avoid the need to fetch all the user and then filter them locally).

Currently, the inactive users are not shown on the map (maybe we should add them, but grey them out? or add an option for this.) and in seach results they appear greyed out and are sorted after the available ones.

@jeanfrancoisbeaulieu
Copy link
Contributor

Showing unavailable users could be an option for sure, although I think it should be disabled by default. Some region are already too dense with users, and it's very case-specific, users in general should not write other users who have explicitly said they are unavailable. A warning should be present in the message form for example.
( Inactive and unavailable users are different here. I wonder if the annual clean up/deletion of inactive users still happens )

@sgelb
Copy link
Collaborator Author

sgelb commented Aug 27, 2018

After a filter mechanism is implemented, adding a filter is not that big of a problem. Especially every field already in User, see here.

@klzig
Copy link

klzig commented Aug 27, 2018

This filters concept was in my initial WinPhone design, never implemented because the filtering should be done server-side, which would require API and server changes, and these were out of my control (or at least beyond my bandwidth).

Very useful IMO. But let’s push to get this implemented server-side 😊

@sgelb
Copy link
Collaborator Author

sgelb commented Aug 27, 2018

We are already talking about two different kinds of filtering, both with their own use case.

Prefilter
A prefilter on the server enables to filter out results the user has no interest at all., e.g. to never show unavailable users. I'd like to persist this option in the preferences so it applies to all searches. As a side effect, a prefiltered response could reduce bandwidth and improve speed.

Postfilter
This enables the user to filter on the downloaded results on the fly, e.g. to temporarily hide users which are members for less than x months. It's more about reducing the number of results by adding additional restrictions than about filtering totally unwanted results. I'd put this option in the menu for easy reach.

I think both would be great. What's your opinion?

@saemy
Copy link
Collaborator

saemy commented Aug 28, 2018

I do not understand the difference. I prefer if all the settings for search results can be made in the app. And I think all filtering should happen on the server. There is no point of downloading user information just for dropping it on the phone. Search requests are handled by the server anyways, so why not sending the filter parameters along the query and let the server do the work?
The rest is just a matter of how we design the UI (i.e. whether one can specify permanent search filters, ...)

@sgelb
Copy link
Collaborator Author

sgelb commented Aug 28, 2018

Okay, I try to make myself clearer.

First of all, all filter options should be set in the app and should be the user's choice. But I think there is a point for additional filtering on the phone.

A use case: we travel in a group of three and we can give only two days notice. These are hard conditions. Hosts that don't match them are no potential hosts for us at all, ever. So I'd want to be able to permantly filter on these conditions and this filtering should happen on the server. The result only contains potential hosts.

Now we are in this large city and even with our hard conditions, we still got a list of hundreds of potential hosts. We know that all the results match our hard conditions, but there are still too many. Luckily, our group has some soft conditions, e.g. we prefer users which were active in the last month or speak a specific language or with a garden to pitch our tent. So we start to play with these conditions, toggle them on and off and so on. In this situation, new search requests to the server would just return a subset of data we already have on the device, cost bandwidth and would be slower. But if we had set these conditions initally, for most areas we would get no results at all.

@klzig
Copy link

klzig commented Aug 28, 2018

I like both the prefilter and postfilter use cases. But I think prefilter should be prioritized much higher, for the following reasons:

  1. It eliminates the bandwidth and mobile-side processing of information that will never be of interest to the user
  2. It benefits all of the mobile apps by providing a unified filtering API
  3. It benefits the web app by providing server-side filtering (unless the web app already has this, I haven't looked recently. If it does, the task just got easier...)
  4. It is the easiest (and IMO most useful) form of filtering to implement in the mobile UI
  5. A single implementation of the filtering code vs a unique implementation for each client

@sgelb
Copy link
Collaborator Author

sgelb commented Aug 28, 2018

@klzig I'd also set priority on server side filtering, exactly for your reasons 1-3. But that needs an API change, which is kind of out of our hands.

I think that neither case is hard to implement.

@klzig
Copy link

klzig commented Aug 28, 2018

@sgelb The current off-limits nature of the API is a real problem IMO. It's hard for me to justify investing much time in WS development if the API is closed and not obviously supported. I guess I should admit that my #1 reason for favoring the prefilter option is that it forces the issue on the API.

dproctor pushed a commit to dproctor/wsandroid that referenced this issue Mar 7, 2019
dproctor pushed a commit to dproctor/wsandroid that referenced this issue Mar 7, 2019
saemy added a commit that referenced this issue Mar 27, 2019
saemy added a commit that referenced this issue Mar 27, 2019
Co-authored-by: Devon Proctor <Devon Proctor>
Updates: #288
Closes: #320
saemy added a commit that referenced this issue Mar 27, 2019
saemy added a commit that referenced this issue Mar 27, 2019
saemy added a commit that referenced this issue Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants