The map is a great way to locate hosts. Unfortunately, in some areas (cities often) you need to search a bit to find appropriate or active hosts. A filtered map or faceted search would help a lot. In fact, this would be my number one feature request for WS.
So, I played around with the Warmshowers API and came up with a map where the markers are colorized based on the number of positive feedback for a host.
Live demo: http://geertdedeckere.be/warmshowers/
- It may not be a good idea to only use feedback score as a way to differentiate hosts on the map. This may result in hosting requests being focused solely on those members. Not fair towards new members? Also, other factors, like responsiveness on messages or last login date, could be used to calculate some kind of host activity score.
- Ultimately, it would be cool to add more and customizable filters. Ideas: only show hosts that can hosts at least X persons, or hosts that may offer a bed, etc.
- There is a lot of room for code optimization. I just wanted to get the idea to “work”, a quick and dirty prototype.
- It is very slow, I know. One reason for this is that in order to calculate the feedback score for a host a separate request needs to be sent to the API for each host. Note that I cache the result, so reloads on locations that were loaded before are faster.
- Hosts on exactly the same latitude/longitude are simply printed on top of each other. The host with the highest feedback is shown on top, though. This happens from time to time, mostly in cities. On the original WS map a number is shown linked to a small popup with a list of the hosts. — Update: fixed now.
Looks great, as you can see from the feature poll taken last year this is something many other members are equally interested in, including myself - https://www.warmshowers.org/feature_poll
I'd love to talk to you some more about this, particularly if you're interested in taking this a bit further. Message me directly.
All the best,
I applaud your initiative and agree that the map search in city areas is problematic. I, like yourself, am of the opinion that this is the most needed feature on WS, I have written a number of times about this on the forums over the years so I hope you don't mind me making a few observations:
The geographic granularity of host data is one of the best features for WS guests but when searching for hosts in cities I think it is of lesser importance. That's where I think the list search could come into its own as something distinct and complementary. Unfortunately at the moment results are ordered by distance from an arbitrary city centre, thus it does little more than serve as a poor replica of the map search and is effectively redundant.
Secondly, I don't think feedback is the most crucial data point through which to filter hosts (though I agree, eventually it would be great if one could filter across a wide range of variables) - a high feedback count could indicate someone who has only used WS as a guest, and, as you mentioned it would tend to give lesser prominence to newer, often more enthusiastic, members.
What I think would be useful is if there was, at a bare minimum, a default filter on list searches so that guests may find active hosts and at the very least get a response (I have previously suggested a fairly permissive filter of last login < 1month and response rate > 50% - also automatically including anyone with < 2 requests) - this filtered group would then be prioritised and randomly ordered before the remainder of the hosts were listed in order of last login date. This would provide an incentive for hosts to log in and respond to requests and would also give new hosts a chance at appearing at the top of the list. The same filter could probably be extended to be an optional feature on the map (I have heard as the number of potential hosts have increased this has had repercussions in terms of increased data crunching on the map view on mobile phones - the filter could take a lot of that data out of the equation) - eventually features could expand eg: the ability for the user to create and save custom filters and switch between them from a drop down menu etc.
Finally for all this to work well we really need to require new members to intervene in order to set their status as available to host as opposed to the current state of affairs where members need to intervene to set themselves as unavailable (this is creating far too many false positives in host searches).
Thanks again for your work and I'd be interested to hear any thoughts you have regarding my suggestions.
Thank you for your suggestions, as always very wise. Currently we have a number of good suggestions in the issue queues, the feature poll and in the forum here and they generally focus on similar threads of thought. Two of these being to improve the measure by which we take responsiveness and to add an improved filtered/faceted search all round (including the aforementioned responsiveness measure). And for me it is crucial that none of these affect the ability for new users to get themselves found.
I'd love to say we'll get to these next week, but alas there are a great many other burning issues right now and what I'd love even more is for a handful of wonderful developers to step forward and help take on the work :)
All the best,
That's entirely understood Andrew, the efforts of all developers are greatly appreciated. Certainly I'd love to offer my services but unfortunately my abilities don't extend much beyond a bit of bash scripting :(
Thanks for your feedback, Paul. I agree on many points. I’m justing throwing all user feedback together now (host/guest). This could be calculated separately and the color coding on the map could only use host feedback then. On the other hand, if you're using Warm Showers mostly as a guest, highlighting that user as a host on the map anyway doesn’t hurt. Hosting is part of the deal.
I’m not taking responsiveness to messages in account at all now. It could be done but requires another API request per host, making things even slower. Suggestion for the API: make all requests for host data (e.g.
/services/rest/hosts/by_location) respond with more info. It would be practical if feedback and message stats would all be included in a single response instead of having to make separate calls for user info.
So, I played around a bit more with the map and added a few improvements. Members on exactly the same location are now “spiderified” using the OverlappingMarkerSpiderfier library. You can see it on the screenshot too.
Also, new members (registered within the last 4 months) are now shown in green. Hosts without any feedback after two years are now displayed in gray. All in all, this makes for a far more usable map, even though there's quite some room for improvement.
Yes, hosting is part of the deal, I know WS tries to push the reciprocity angle, but after nearly 10 years on numerous hospex sites I know its the exception and I don't let it bother me too much. Certainly if I found a 'host' with 20 references all as a guest, I wouldn't be all that optimistic, perhaps they've just returned from a long trip inspired to give back by hosting, but yeah I wouldn't really be backing my luck.
Anyway, great work, that is really making the map far more usable in densely populated areas. I still think a filtered list search along the lines I described would be more effective in removing the chaff we now find in so many large cities now on WS and promoting responding hosts but anyway I'm just stoked someone has stepped up to do something about the problem - congrats.
I love your design and it is exactly what I would love to see implemented.
A couple of comments/ideas:
Once the "scoring algorithm" is agreed upon, this could then be implemented server side so no additional round trips required. The final "score" like 1-9 could then be displayed in the marker.
Hosting feedback and responsiveness generate the score, multiplied/adjusted by the hosts' optional, self determined "Burn-out" value, so a host could opt for their "max" score (1-9) to be reduced (for a while) so they don't get all of the request, just because they are the best and always the first choice.
It's not easy to find a good formula, but from a technical point of view it would be practical to have such a number for each WS member to colorize the markers on the map. I'm not a math hero, but let's just have a look at all the numbers available to calculate some kind of “WS activity score”:
- Number of positive/neutral/negative host feedback
- Number of positive/neutral/negative guest feedback
- Older feedback to be valued less in the equation
- Number of messages replied to during the past year
- Last login date on warmshowers.org
- Whether a phone number is present in the profile (?)
Your self-determined burn-out value is an interesting idea, Michael. Something like that should prevent the same hosts to be contacted always. The main goal of the calculation should be to filter out non-active hosts or abandoned accounts.
I disagree that the results of any hypothetical algorithm should be exposed to members due to the very same consequences you are trying to mitigate by adding further complexity to the system. Also this will result in hosting being explicitly gamified, something I wouldn't like to see happen to WS. If anything this gives itself more naturally to the list search where it could be implemented by giving priority to a randomised subset of members at the top of each search before listing the remaining members that fall beneath whatever the filter threshold is set at. I think if applied to the map it should be optional (and off by default) and simply filter out all members falling below the threshold.
But, alas, this is pie in the sky stuff. We still have nothing to show despite this issue being discussed and on the agenda for the last 4-5 years. Given the size of the WS community I don't think such complex solutions are necessary at this stage. I think a first step involving simple filters on response rate and last login as described above would be sufficient to sort the wheat from the chaff whilst still giving active hosts an equal chance of receiving requests in any given area.
should NOT be an issue. If a decent algorithm can be agreed upon, that would be relatively easy to program and implement.
I never liked the list search, due to all the issues you stated about it. Hence the map is most important to me.
However, the score could be used for both, map and list.
I agree, the user should have a choice if to use the filter options or not.
Necessity: All this is useful not only particularly in Metro areas, but also to give the user an idea about the likelihood of a reply of any host.
Randomization in list: Still an option within a score (e.g. 20 people with "perfect" score)
One additional, not previously discussed, positive outcome: If a high(er) score for my profile is important to me, then this could motivate the members to increase their "participation" (= pay attention to ALL the factors that go into the score).
What I like the very most about the gray markers: All the "inactive" (however that will be defined) members that WS does not filter out, are clearly visible and will no longer waste anyone's time. That alone is wonderful.
Perhaps I didn't explain myself well enough. You are adding further layers of complexity (hosts having a multiplier setting) to mitigate against the inevitable outcome of exposing host scores on the map. We can't even get members to set their current hosting status correctly, members in general aren't going to invest in understanding and manipulating abstract numbers like this - far easier to keep this under the hood (or use simpler transparent measures based on response rate etc) and filter based on a threshold.
A functioning list search is vital for any populated area - it's far easier to find active hosts from hundreds in a small area when you can filter and sort them on a list, location in this scenario tends to be of lesser importance. Unfortunately we have a list search that tends to promote members who have no interest in hosting, I don't see that as a reason to abandon it but a reason to make it work.
Well that was a previously discussed outcome (see comment regarding gamification) I just don't see it as a positive. Scores, stars, badges etc tend to promote a fairly ugly culture of vanity and class in hospex communities (cf. Couchsurfing) but not even CS has stooped as low as to boil hosts' worth down to a number (at least last time I checked). Incentivising hosts through smart filtering has been discussed numerous times here (eg: https://www.warmshowers.org/node/43124) - the same effect could be produced with transparent filters that members will understand as I discussed above without the deleterious effects on the community.
I'm not against an algorithm per se but getting the balance right over various variables (last login, percentage positive references, response rate etc) will require as much art as science and the end product will be a number the formulation of which the average user will not understand. At this stage with only 80,000 members and not a single filtering or sorting feature of any use implemented I think it would be simpler and more intuitive to expose filtering on clear, intelligible variables such as last login and response rate. As a long term goal at some later point in the site's evolution I think it's worth keeping in mind, but gamifying the system by exposing host scores to the community is not something I'm ever going to get on board with.
Good points, Paul. Again, the main goal is to filter out inactive hosts. The whole scoring algorithm may focus too much on the active hosts and it might create a race to the top with its own set of new problems (gamification as you said).
You can keep things very simple. Just filtering out (or greying out) members who didn’t login for over a year and have a response rate of less than 50% would make the host list or map a lot more usable already. Taking it a small step further you could go for a stoplight system, if you wanted to have some kind of status in between "active" and "abandoned":
- Green: active member, last login < 6 months and response rate > 80%
- Orange: possibly inactive
- Red: abandoned account, last login > 1 year and reponse rate < 50%
On a map other colors would be used obviously (red attracts too much attention): green, light green and grey, for example.
Live demo: http://geertdedeckere.be/warmshowers/map2/
Note that in this demo, I’m only incorporating last login time to divide the members in the three groups as described above. I can’t retrieve the message response rate via the API. This information doesn't seem to be included in the user info. Well, on the upside, only using last login time makes loading the map significantly faster. No caching needed.
Looks like most members did login during the last year. In big cities the concentration of grey markers is higher, though.
That's quite intuitive and, yes, much faster. I think you could easily pull that first category in to 1 month and possibly also the intermediary category a little to match.
There was a proposal to expose the request & reply counts to the API as user fields - I'm not sure where they're at with it:
Made a small update to the map, as per your suggestion. In order to be marked as active you need to have logged in during the last 31 days. Members with login dates more than six months ago are now displayed in grey. Also, new members (signup < 1 month) get a small "×" on the marker label instead of a dot.
As for the responsiveness stats, as read in that issue on Github, it's still being worked on to make it available through the API.
As Registrar, I review up to 200 new members daily. I try and delete the obvious incomplete profiles, and I can tell several who sign up as hosts will not be current (I may send out welcome letters and get no response)
Along with the Board, we have designed a new profile that will require more information and fields to complete. I am hoping that with more effort and more details, we will have a richer, yet smaller, community. We will also have other metrics in which to add to searches later on. Although this is a priority, there is a higher priority of attaining a new E.D.; someone with the tech experience to make these profile changes happen.