Page MenuHomePhabricator

Ambox not visible in the Android app
Closed, ResolvedPublicBUG REPORT

Description

Steps to reproduce

  1. Open https://hu.wikipedia.org/wiki/MMS in the Android app.
  2. Look for the ambox about the lack of sources.

Actual result

  1. It’s nowhere.

Expected result

  1. It’s more or less prominently there. Not necessarily looking exactly the same as on desktop, since that would probably be too large compared to the small smartphone screens, but displayed in a way that can be noticed.

Software version

  • Wikipedia Android app 2.7.50420-r-2022-09-12
  • Android 12

Other information

Amboxes have a critical role: they allow readers to determine the reliability of the content. If the article contains no references, its statements (especially hard-to-believe ones) should be questioned by the reader.

Product Requirements

  • Entry point to Ambox should be in the About this Article Section as we see in iOS with the same copy
  • When a user clicks the entry point it should reuse the components of Android edit notices
  • While this can be implemented without designs, it must go through design review to proceed

Test Notes

You can use the Polar Bear article on English to see how it work. Please test it in all themes.

Event Timeline

JTannerWMF moved this task from Needs Triage to Up Next on the Wikipedia-Android-App-Backlog board.
JTannerWMF subscribed.

Thanks for recording this, we will think about the best way to implement this

LGoto triaged this task as Low priority.Oct 17 2022, 4:07 PM

Could you please prioritize work on this? As I wrote, amboxes have a critical role, impacting all users, not just editors. See also WP:THEYCANTHEARYOU.

Hello, I agree with the above comment of Tacsipacsi. Some of these boxes like Template:POV are very important for the user to be aware if an article respects the fundamental principle of Wikipedia WP:5P2 or not. Some of these boxes even can only be deleted with the consensus by voting from contributors. So this ticket should be at high priority.

Just want to acknowledge we are looking into the best implementation of this

Where is the link supposed to appear? I tested it on https://hu.wikipedia.org/wiki/MMS because https://en.wikipedia.org/wiki/Polar_bear doesn’t have any amboxes, but I couldn’t find the link even though I was specifically looking for it – which is far from being good, as the goal is that readers become aware of the amboxes without specifically looking for them. The app says it’s version 2.7.50443-alpha-2023-05-19, and my phone is set to Hungarian (which shouldn’t matter, but who knows).

@Dbrant could you post a screenshot here? The apk is expired and a screenshot enough for me to review.

This basically enables the Content Service to expose the "page issues" menu item for us, which is seen at the bottom of the article:

Screenshot_20230608_100929.png (2×1 px, 172 KB)

When tapped, we display the page issues in a popup dialog, similar to edit notices:

Screenshot_20230608_100918.png (2×1 px, 250 KB)

apk: https://github.com/wikimedia/apps-android-wikipedia/actions/runs/5212008678

So this is why I haven’t found it! All other platforms I know expose page issues at the top of the page. Since the main purpose of amboxes is to communicate information to users who don’t specifically look for it before they start reading the article (so that while reading the article, they already know how much they can trust it), hiding it at the bottom of the page fails to serve its purpose.

Hey @Tacsipacsi ! I'm the Product Manager for the apps that prioritized this task. I agreed it was important to use what Content Service provided us to show page issues (amboxes). When it came to placement, feature availability was prioritized over discovery (something that would require significant design thinking because it requires a holistic look at the architecture and user flow of the app). I drew inspiration from the iOS app where page issues already existed in the about this article section and had the engineers place it there since the iOS architecture is closer to that of Android.

This coming Fiscal Year (which starts in July), I am prioritizing a holistic review of our app's architecture to address the discovery challenges that exist. When the app was created it was intended to only support reading and serve as a limited feature reading app. This was a decision that has predated me. The Product Manager immediately before me started adding editing features such as suggested edits. When I left the Web teams (Growth, Editing and Web) and joined apps we started adding features that Wikipedians are accustomed to like Watchlist, Edit Notices and Article Talk pages. A lesson that I learned quickly was the importance of balancing what cross platform users expect with what long time app users expect. For example, when making notifications more prominent at all times for all people as requested by cross platform users we did not think about the architecture holistically, and a (few) reader(s) understandably pointed out that they will never edit and find the bell icon a distraction from their most used feature, tabs, something that doesn't exist on Web. For that reason we've tried to prioritize more customization of the experience by allowing people to place things like talk pages and edit history in their toolbar especially if editing features are more important to them than say the Share function. Majority of apps users engage with customizing their experience.

I say all of this to say, I can not in good faith simply place page issues in the exact same place it is on Web, especially because the format differs wiki to wiki and page issue to page issue. I've learned showing a condensed version and then linking it to another screen to be accommodate variation as well as users with small screens isn't a preferred solution by cross platform users based on the reaction of our implementation of talk page banners. Getting the architecture right is a top priority and something we are planning to do during this fiscal year. However, it is something that requires time and testing across multiple audiences. I am copying @ARamadan-WMF so she can ensure you are engaged in those conversations for this coming fiscal year, particularly for Android.

Hey @Tacsipacsi ,
I will follow up with you when we start working on this part during the next fiscal year, till then, you can be updated on our Wikipedia App newsletter from here.