-
Notifications
You must be signed in to change notification settings - Fork 22
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
Comments
Absolutely! |
I had been pushing for this on the website for years now before it was out-sourced. |
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. |
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. |
After a filter mechanism is implemented, adding a filter is not that big of a problem. Especially every field already in |
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 😊 |
We are already talking about two different kinds of filtering, both with their own use case. Prefilter Postfilter I think both would be great. What's your opinion? |
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? |
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. |
I like both the prefilter and postfilter use cases. But I think prefilter should be prioritized much higher, for the following reasons:
|
@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. |
@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. |
Co-authored-by: Devon Proctor <[email protected]> Updates: #288 Closes: #320
Co-authored-by: Devon Proctor <[email protected]> Updates: #288 Closes: #320
Co-authored-by: Devon Proctor <[email protected]> Updates: #288 Closes: #320
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.
The text was updated successfully, but these errors were encountered: