Android had Nearby (formally called Places) in the app several years ago. It was removed due to performance challenges (details of its removal can be found here).
After increasing requests to add it back to the app, the team researched technical tradeoffs for alternative maps. Our research led us to determine it would be possible to resurrect the feature with improvements if we use MapLibre. The team was able to prioritize resurrecting this feature as a result of the Foundation's Annual Plan .
Enhancing Places Feature Integration and User Experience.
Exploring Innovative Ideas from the Wikimedia Design Team:
- Branding: It makes sense to keep it unified as Places (not nearby) since the feature allows searching anywhere and not just places nearby. Renaming the Android feature when bringing it back will also help users understand it’s (literal) greater scope of use. Else a different feature name, “Maps” “ for both apps?
- Connecting maps + lists: Given a list (e.g. Unesco World Heritage monuments”), visualize their items on a map. Highlight in the map those items that are part of one of your lists (a related idea that Google Maps does is to allow people to set an emoji for their lists of places so that they are highlighted in the general map). Also, it makes it easier to add map items to a list.
- Connecting maps + (micro) contributions: E.g. places without a picture. Articles you edited recently (or in your lists) lacking geographic position that can be added. The Commons app has the feature to add an image to a place without a picture and could be used as inspiration. Micro contributions and template support within articles that can increase editor awareness.
- Expand filtering: Explore indications and filtering for Saved, Watched, Open in tab, Search history on the map. Add filter what you see on the map, e.g. see articles in X collection.
- Add Places to main Wikipedia search: Could we add places search to the main Wikipedia search and e.g. provide an option to filter directly from there? The current design for namespaces filtering (User: Portal: Help:) at the bottom of the search could be leveraged.
- Color palette: Curious about the color palette used for your Mapbox or the rationale for those – given that Google Maps recently changed their colors (more in line with Apple) +1AA.
- Notifications: Use notifications to show the user some special places they are nearby. Not all, so it doesn't flood with notifications, but a few important ones. Maybe as a "travel mode" that you turn on when you go visit a new place, so it's like a tour guide telling you about the history of the places you are near.
- Cultural routes: What about making a cultural route that people can use, almost like Google Maps, to connect a few places (with articles) and give the user a route to follow? See this as a very "touristy" feature.
- Leverage AR/VR: Regarding future possibilities, as some big maps players are already leveraging AR/VR technology, would it be possible to plug-in this data in their existing system rather than building our own?
- Explore feed: How could Places be integrated into the existing Explore feed card stack? What brings added value?
- Space: It would be neat to see articles in space/solar system.
February 2023- Gathering Feedback on Approach
Our investigation has led us to three possible approaches to bringing back the Nearby/Places feature. We would like to understand the sentiment of the approaches below by people that will prospectively use the feature on Android. Please share discussion points and questions in the discussion section of each approach, and vote for your preferred approach. Discussion and voting is open through the end of March. We will share the outcome of this consultation period in our next steps by the end of April.
Tradeoffs of each approach
Below you will find the tradeoffs of Google Maps, Mapbox and MapLibre:
➕ Very easy to integrate.
➕ Minimal maintenance and modest increase in total APK size.
➖ Won't work on devices without Google services.
➖ Not open-source, so won't be allowed in F-Droid builds.
➖ Not free to use. Here is Google's pricing structure for Maps.
➖ Will still be missing most of the other functionality of a standard "maps" app.
I am unclear what we would need to pay for? This seems like a case for WMF PR team, they should get Google to wave the fees, under the threat of bad press (rich Google makes poor Wikipedia pay for stuff). --Piotrus (talk) 11:55, 28 February 2023 (UTC)
- Hi @Piotrus, WMF’s approach toward partnerships is to identify areas where our missions align with other organizations’ and propose collaborative ways of working together. You can read more about how this has been done with Google in particular here. For example, Google has provided API credits for several initiatives we’ve partnered on in the past.
- Additionally, while agreements to waive fees are a convenient way to secure resources for a project, it’s important to understand that such an approach can also leave the project vulnerable to risks. For example, if Google were to no longer be able to support this financially in the future (which could be the case for a variety of legitimate reasons) WMF would need to be immediately prepared to fund the project or find an alternative approach. NPerry (WMF) (talk) 15:32, 3 March 2023 (UTC)
- @NPerry (WMF) Fair enough. I was just thinking about the oh-so-useful in but short lived Google Map Wikipedia extension. I realize this is not directly related but... is anyone talking to Google (talked in the past) about bringing this back? In case you have no clue what I mean: https://techcrunch.com/2008/05/13/google-maps-adds-more-wikipedia-entries-and-geo-coded-photos/ / http://blogoscoped.com/archive/2008-02-25-n74.html https://techcrunch.com/2008/05/13/google-maps-adds-more-wikipedia-entries-and-geo-coded-photos/ / https://www.seroundtable.com/wikipedia-layer-gone-google-maps-17342.html / https://news.ycombinator.com/item?id=6343882 Piotrus (talk) 15:39, 3 March 2023 (UTC)
Mapbox is the best-known SDK (outside of Google) for integrating maps into web and native platforms, and this is what we were using previously to hook into our own OpenStreetMap tileserver.
(To clarify a bit: Mapbox is a company that offers components and SDKs for rendering maps on web and native platforms, and they also have their own tile servers, but you can also just take their SDK and point it to your own tile server, which is what we were doing.)
However, there have been some recent changes to Mapbox's licensing model:
➖ We can no longer use the Mapbox library without creating an account with them and using an API key (even if we use our own tile servers).
➖ When we attempted to create/access an account (just for the purpose of trying their latest library), we were greeted with this:
➖ According to recent discussions, it sounds like Mapbox now charges fees for every map-load, even if using your own tile server. For these reasons, we can conclude that Mapbox might no longer be the right fit for our needs.
There is now a community-maintained fork of the Mapbox SDK that will remain open-source, there is some work that needs to be done on sprites and fonts through June before Android would be able to start development on bringing the feature back into the app. Nevertheless this is probably closer to what we're looking for. The rough pros and cons of using this SDK will be:
➕ Since we have vector tiles, zooming and rotating is now fluid and responsive. Also, since these are vector tiles, we can apply arbitrary styling to them, including things like "dark mode" and other themes in our maps, or highlighting particular overlays with different styles. Here's an example with some random colors:
➕ Integrating will be relatively easy. It's a simple matter of resurrecting our old code and bringing it up to date with current best practices. The interface with the MapLibre SDK hasn't changed significantly from when we were using Mapbox earlier.
➖ Will increase APK size from 14MB to 25 MB. Note, however, that this will still keep us on the low, low end of the app bloat spectrum.
➖ Will be missing most of the functionality that's expected in a "maps" app. For any interaction other than "view the Wiki article for this marker", we would need to bounce the user out to their default external Maps app should they want to use GPS for example.
- Great you're bringing the Nearby feature back! It was very useful and worked well until you/WMF removed it without giving any reason (thanks for giving some now).
- As for which map to use, I support a fully free map even when its quality is lower than alternatives (you don't need a perfect map if you just mainly use to navigate around new places to discover). I don't know if there's other software for OpenStreetMap that could be used. I oppose using any non-free software for the map like Google Maps.
- I don't think the picture you put there looks good, maybe that's because of the colors but I think MapLibre can look nicer than the image suggests. I haven't checked if there's really no good way around fees with Mapbox.
- Lastly as a small note: please enable filtering which articles are shown on the map via article categories and the WikiProject assessments on their talk pages (e.g. to uncheck "show transport infrastructure articles"). --Prototyperspective (talk) 16:21, 6 June 2023 (UTC)