Story: As a logged-in Rep, if I visit the events page the search box should be pre-populated with the country from my profile. Example: https://reps.mozilla.org/events/#/period/future/search/united%20states/ As a logged-out user or a logged-in user who is not a Rep, the behavior should remain unchanged -- all events should show up and the search box should be empty.
Whiteboard: [kb=1077112] → [kb=1077112] [q3 events]
The specifications described in that bug are solid and we can continue with the implementation. There are some concerns though regarding the UX and the code quality after choosing that architecture. * The search field under /events does a generic search over various fields (display name, local name, email, country, region etc). As a result, by using the user profile's country we might end up with different events than expected (unlikely, but still). * By adding a default country to the first page under /events a new user who is not familiar with the autocompletion might think that there are no events at all if it occurs to have no events in a particular region. Regarding the code quality, a cleaner approach might be to have a similar UI to /people country filtering. That means adding a new drop down menu with countries under the advanced options toolbar. This will also provide a country specific url to refine the events list, eg. reps.m.o/events/#/period/future/country/<COUNTRY>/. The UX overhead to the last approach is the required number of steps to learn about any nearby events which I think was the initial goal. :williamr What is your input to the thoughts above?
(In reply to John Giannelos [:nemo] from comment #1) > * The search field under /events does a generic search over various fields > (display name, local name, email, country, region etc). As a result, by > using the user profile's country we might end up with different events than > expected (unlikely, but still). I agree this is unlikely. Thanks for mentioning it. > * By adding a default country to the first page under /events a new user who > is not familiar with the autocompletion might think that there are no events > at all if it occurs to have no events in a particular region. Good point, and we do want new users to understand the search functionality. > Regarding the code quality, a cleaner approach might be to have a similar UI > to /people country filtering. That means adding a new drop down menu with > countries under the advanced options toolbar. This will also provide a > country specific url to refine the events list, eg. > reps.m.o/events/#/period/future/country/<COUNTRY>/. I like this idea since it is cleaner with search filtering (instead of searching across several fields) and it provides a country specific url. Since country level filtering is important in general and is desired for this bug, I suggest we add a country filter to the right of the search bar. This means the country filter would be visible at all times instead of being located under the advanced options toolbar. I think this approach addresses the two concerns above.
I would like to raise a point of consistency here with changes that were proposed in the UX NYC session. If we are going ahead with "events near you" functionality on /events/ page we need to come up with a more holistic approach to what we are trying to do in this bug. I propose we implement for both auth and non-auth users the ability to get "events near me" functionality if they opt-in while visiting /events/ (can be done with a map slide or notifier). That way we can deliver the functionality needed in this proposal (close to it) with a lees intrusive and more predictable way.
We discussed in our weekly meeting and agree that the original implementation suggested in the comment 0 isn't ideal. We decided on the following implementation of "Events Near Me": When a user loads the events listing page... * Attempt to access browser geolocation * If user allows geolocation access... ** Zoom the map to an appropriate level, which will be hard-coded, not dynamic. It should show a few countries in Europe, for example. On Mapbox this might be 5; I'm having a hard time finding Cloudmade's API docs to determine what the equivalent would be in Cloudmade. ** Focus the map on the user's location. * If user doesn't allow geolocation access... ** keep current behavior http://api.tiles.mapbox.com/v3/examples.map-uci7ul8p/pin-m-monument%28-77.04,38.89%29/-77.04,38.89,5/400x300.png
Summary: On event listing page, pre-fill search query with user's country → On event listing page, use browser geolocation to focus the map
Nemo just posted a pull request. A couple of UX comments: - Nothing happens if we can't find user's location. I guess we should display an error message or something so (s)he doesn't wait for something that's not going to happen. - When a user comes with a search term in the url, the locate popup should not come up, because (s)he can end up with a zoomed map that does not show the expected events. I'd only show the 'locate me' popup if there is no url and period is `current and future`. - I like the LocateContol leaflet plugin (https://github.com/domoritz/leaflet-locatecontrol) which adds a 'locate me' button on the map, so user can trigger the event on demand and not only when the page loads. Thoughts?
Thanks Giorgos for the comments, I agree with your points above. Any thoughts Pierros and William?
(In reply to John Giannelos [:nemo] from comment #6) > Thanks Giorgos for the comments, I agree with your points above. > Any thoughts Pierros and William? I also agree on all three points in comment 5. For the error message, I suggest this text: "Sorry, we could not determine your location." This message could disappear after 10 seconds or so.
Agreed on the UX as we discussed and +1 on the plugin
I tested a bit the functionality described above, as John coded it and I have some second thoughts about _automatic_ geolocation. Here is the flow 1. User visits /events 2. He gets automatically directed to /events/#/period/future/ and also gets a geolocation popup 3. If he clicks he gets located, if he doesn't nothing changes. The problem: If the user reloads the page (remember he's now on /events/#/period/future/) or sends out the link to a friend, he doesn't get the popup again. Instead he has to explicitly request /events/ again to get the popup. This feels a bit broken UX imho. Also while testing it I realised that it feels a bit broken to have automatic geolocation in the first place. Here is another scenario to justify that. -. User has in a previous visit, always allowed reps.m.o to get access to his location 1. User visits /events/ 2. Since geolocation and event loading are async events, user may first get the map of events and then see the map changing without prior notice. What I suggest: I don't have any automatic geolocation. We instead keep the 'locate me' button in the map and the user decides on demand. Thoughts?
Hi, regarding geolocation on load, I have 2 comments: * I have updated the PR and geolocation popup shows in both /events/ and /events/#/period/future/ * I also agree that automatic geolocation is kind of confusing from the user's perspective. Any thoughts on that?
I think the async issue described in comment 9 is not a big deal. Async focusing of the map is a standard pattern on the web; I think most folks who use maps have experienced the map refocusing after page load. So I think we should try an automatic map zoom/center, at least in dev, to see how it really feels. I agree 100% with the change :nemo made in comment 10. I think _any_ pageload in /events/ should trigger the geolocation handshake. In other words, https://reps.mozilla.org/events/* should make the geolocation popup appear, or should use geolocation to refocus the map.
Commit pushed to master at https://github.com/mozilla/remo https://github.com/mozilla/remo/commit/0276d860968c125313f48b063904afd361762617 [Fix bug 904880] Use geolocation to zoom /events map to user location
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Verified that is working on stage.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.