Wikimedia Apps/Team/Android/Places

Background

Places, also known as Nearby, was a feature in the Android app several years ago. We have removed the Nearby feature from the Wikipedia app for a number of overlapping reasons, including extremely low feature usage, ongoing maintenance issues that were out of the Android team's control, and community concern about the location permissions that Nearby required.

Also, from a legal standpoint, we weren't able to integrate with the Google Maps SDK (i.e. use a Google Maps view in our app, with a custom layer on top), which means we had to use the MapBox SDK with OpenStreetMap which, at the time, was not providing the best possible user experience. It was glitchy, slow, and bloated. Merely including the MapBox SDK caused our app to triple in size. This is an important consideration for users for whom the cost of data is not negligible. These concerns made it infeasible to continue to support the feature at the time it was removed.

However, we have had very persistent requests to reinstate the feature. As a result, the team did a technical investigation to evaluate other open source map alternatives. We shared those alternatives with interested members of the community and decided to proceed with using MapLibre. Use of Map Libre eliminated technical and legal concerns. The organization's 2023-2024 Annual Plan enabled our team to prioritize this work with the caveat that reinstating the feature results in better usage metrics than the past.

We took into consideration feedback of past usage metrics not being an accurate reflection of community sentiment and established the following success indicators:

Validation

  • KR: 1.1 10% increase in article page interaction as a result of internal app referral (Broken down by Article Previews and clicks through to article)
  • KR 1.2: 30% of users try the feature more than 1 day
  • KR: 1.3: 3000 people save, share or watch an article as a result of feature
  • KR 1.4 10% of users click through to article view from places

Guardrails

  • KR 1.1: At least 70% of representative users that provide feedback about feature report satisfaction

Curiosities

  • Do people who engage with Nearby have higher pageviews than those that do not
  • What % of people open the feature as are result of the tooltip?
  • How does engagement with Android Nearby compare to iOS?

How to Follow Along

We have created T347201 as our Phabricator Epic to track this work. We invite you to collaborate with us there or on our Talk Page.

We will provide periodic updates on this page as we make progress. If you are interested in participating in our moderated design feedback sessions, please let us know on our talk page, and we will follow up with you.

Product Requirements

Must Haves

  • Provide a Map View and List view when someone launches the Nearby feature
  • Allow users to view articles on a map from article view and launch Nearby

Within Map View

  • When a user clicks on a map marker, allow the users to read, save and share an article, as main actions
  • In the overflow menu of a map marker, and allow users to save to watchlist
  • Provide a search that allows users to search articles prioritizing articles near them
  • Before a user types they should see recently searched articles
  • Get a user's permission before going to their location
  • Map should honor theming (dark modes, etc.)

Within List view

  • Let users see how far away an article map marker is away from them

Nice to Haves

  • If a user wants to get directions take them to their map app
  • Support multiple languages in the search
  • Provide an edit opportunity for stubs

User Stories

  • As a Wikipedia Android app user traveling to a new city, I want to know what articles are nearby, so that I can learn more about my surroundings.
  • As a Wikipedia Android app editor, I would like to see the language coverage of articles near me in Urdu, so that I can expand stubs about places I care about.

Future Ideas for Feature

The team has discussed possible future iterations of the Places feature with other teams and community members. Below are some of ideas for future versions of the feature:

  • 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.
  • Add Locations: Enable adding locations to articles in the app.

We welcome feedback on our Talk page about these ideas.

Updates

October 2024

  • We added a launcher shortcut to allow quicker access to the "Places" feature T375367

August 2024

  • We made a number of improvements to Places after its initial release, in response to user feedback.
    • Changed the cluster icons to make them slightly larger and different than normal markers. T371067
    • Added a Wikipedia logo placeholder onto the map for articles that do not have images. T370094
    • Added a card in the Explore feed for places, to help more users discover the feature. T370100, T370107
    • Updated the Map’s logic so that it always opens at the right zoom level to show a marker near you. T368792
    • Removed a confusing tooltip for the language Selector in search when accessing it in Places feature. T368785
    • If you choose a language in Places feature, it will now be remembered if you proceed to Search next. T368790
  • 8Removed the initial introductory tooltip and survey from Places re-release. T368990
    • Removed the "Watch" option in Places feature when the user is logged out. T369078
    • Fixed an issue that was causing some article’s images not to appear on the map. T368784

July 2024 - Results from Usability testing

  • Design completed usability testing with the Places feature and provided recommendations for improvement based on the findings.
  • How did users do navigating the feature? In summary:
    • 5/10 had no issues finding the 'Places' feature under 'More'
    • 5/10 had no issues using the map and the feature (there isn't just one way of doing it)
    • 5/10 had no issues using the search
    • 4/10 knew how to update the app’s location permission settings on their device (1/10 did not follow the task’s instructions)
    • 4/10 found the timing of the survey appropriate (evaluated by observing or actively outspoken, 1/10 did not see the survey prompt, likely due to pre-opening the app)
    • 3/10 were confused by the 'Watch' option in the overflow menu
    • 2/10 had issues identifying what the green dots are (articles without images)
    • 2/10 suggested adding a map preview on the article page
  • Recommendations:
    • Investigate why some articles that have images don’t display a circular thumbnail on the map
 
    • Explore alternative placeholders for articles without a location. We are currently using the green dots, some participants had issues understanding them.
    • Don’t display the language tooltip in the 'Places' search screen
 
    • Remove namespaces search from the 'Places' search screen as it’s unnecessary in this context.
 
    • Ensure that the language is saved/stored/remembered once users perform a switch.
    • Explore designs on how users could explore articles from multiple language Wikis simultaneously on the map. It could be a ‘nice to have’ for the future and be captured in T352757.
    • Explore having a map preview on the article page, e.g. like a widget or map preview within Mobile HTML. The option within ‘More’ was hard to find for participants.
    • Build logic to adjust the map zoom level to show nearby locations when first launching the app. Some users were confused that there were no locations around them.
    • No action is needed regarding allowing direct taps underneath locations (T356246); users had no issues navigating the map and locations.
    • Remove the 'Watch' option for folks who are not logged in. The 'Watch' option in the overflow menu is unclear to participants. It’s a feature primarily for editors. We observed in past tests that newcomers did not know what 'watching' an article meant. 'Watch' is associated with viewing for users unfamiliar with the Wikipedia Watchlist.
    • Consider not showing the 'View this article’s location' tooltip on the article page when users access it directly from the 'Places' map.
 
  • We also completed an in-depth check of Places with disabled location settings and no connectivity. T360030

May 2024

  • We have results from the 30-day analysis. Overall, we met 1 out of our 4 key results.
    • KR: 1.1 10% increase in article page interaction as a result of internal app referral (Broken down by Article Previews and clicks through to article)
      • Actual: Places users did not have a higher rate of internal article interactions. Places users had 6% less frequent Internal article interactions than non-places users. Of users exposed to Places, we saw pageviews came from internal referrals (including Places) 80.5% of the time, whereas for those not exposed internal referrals accounted for 41.6%. Internal referrals for all pageviews increased by .6%.
    • KR 1.2: 30% of folks try the feature more than 1 day
      • Actual: Only 6.1% of unique users returned to try the feature another day. 5% is bare minimum industry standard but true stickiness is 30% in 30 days. Our qual responses may give a window into why.
    • KR: 1.3: 3000 people save, share or watch an article as a result of feature
      • Actual: 1531 users shared/saved/watched an article (51% of goal). Save and share had the highest uniques. 6114 unique users clicked read as a result of the feature
    • KR 1.4 10% of users click through to article view from places
      • 12.4% of users clicked through to an article from places
    • Guardrail: At least 70% of representative users that provide feedback about feature report satisfaction via the feedback tool
      • Actual: 67.5% of users reported satisfaction with the feature while 90% reported feeling neutral or satisfied. 8.8% of Places users provided feedback, .5% of feedback was text. Common text Requests include:
        • [Bug] Complaints about having to share their location to use the feature
        • Map isn’t loading or map markers aren’t showing
        • Radius is too Small
        • Can’t find their item on the map
        • Improve zooming for non-touch screen devices
        • Don’t understand how to use feature
    • Curiosity: Do people who engage with Nearby have higher pageviews than those that do not?
      • The average monthly pageviews per user for those that used places was 73.6, compared to an average of 26.2 for non-places users.
    • Curiosity: What % of people open the feature as a result of the tooltip?
      • 1.6% of those who saw the Tooltip entered Places We saw very low engagement with the tooltip drawing attention to the feature. The tooltip did not click through to the feature, which most likely contributed to this.
    • How does engagement compare to iOS?
      • iOS Places users open Places more frequently per unique than Android Places users. This makes sense given that the iOS app has Places prominently featured in the toolbar, and Android must be opened from the “More”, or article entry point.

Lessons learned:

  • The importance of usability testing even if we plan to iterate: we trusted our gut, and did not do usability testing early on. After a survey indicated that users were confused, we completed usability testing and used results to identify enhancements.
  • Places is not the stickiest feature when it comes to repeat use or driving increases in DAU or MAU
  • Places showed positive indicators for engagement with reading list, sharing and reading
  • Places is a good feature for promoting downloads of the app

April 2024

  • We finished analysis of our usability testing for Places, and we will start turning recommendations into tasks to improve the feature.

March 2024

  • A few team members attended the South Asian Open Call and shared the Places feature with the South Asian volunteer community.
  • We are accumulating data for Places via our survey, and analyzing results from usability testing in English and Hindi.
  • We ensured that users can view an article’s location on the map even if location permissions are not enabled.T358426

February 2024

  • The Places feature is officially available! As we accumulate information via our survey and data, we are going to complete usability testing to see if there are improvements that can be made to onboarding to the feature. T347201
  • We fine-tuned elements of Place’s user interface T353562
  • Added the “View on map” option into the article toolbar T351394

January 2024

Our engineers have been developing the feature this month and shared a demo of their progress. The places feature will be released to all audiences in February.

December 2023

The feature continues to be in active development. We estimate a mid-February release of the feature. Our metrics for success are:

Validation

  • KR: 1.1 10% increase in article page interaction as a result of internal app referral (Broken down by Article Previews and clicks through to article)
  • KR 1.2: 30% of users try the feature more than 1 day
  • KR: 1.3: 3000 people save, share or watch an article as a result of feature
  • KR 1.4 10% of users click through to article view from places

Guardrails

  • KR 1.1: At least 70% of representative users that provide feedback about feature report satisfaction

Curiosities (nice to have)

  • Do people who engage with Places have higher page views than those that do not
  • What % of people open the feature as a result of the tooltip?
  • How does engagement with Android Nearby compare to iOS?

November 2023

These are the designs that are currently in development, and planned to be released in early 2024. We are excited to bring Places back to the Android app and can’t wait for you to use it. As usual, any feedback for it is highly appreciated. Thank you!

 
Places can be found in the main navigation under the 'More' menu.
 
'View on map' can be used to show the location on the map.
 
Disabled state for 'View on map' when there is no location attached to the article.
 
The new 'View on map' item can be customized via 'Customize toolbar' functionality.
 
The language filter lets you choose which language Wikis are shown on the map.
 
The list view features the articles in the selected area of the map.
 
Long-pressing an item reveals the overflow menu in the list view.
 
Search experience with recent searches.
 
Search results page features the distances.
 
Empty state when there are no results.
 
Multilingual search results if more than one app language is set.

October 2023

The team has officially begun work on bringing Places back to the Android app. Our designer conducted an comparative review of how the iOS feature work to start early iterations of designs for how the Android version of the feature could work.

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:

Google Maps

➕ 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.

Discussion

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)[reply]

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)[reply]
@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)[reply]
Voting

Mapbox

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.

Discussion
Voting

MapLibre

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.

Discussion
  • 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)[reply]
Voting