Page MenuHomePhabricator

EPIC: Restore Wikipedia Zero alert handling for 5.0
Closed, ResolvedPublic

Assigned To
Authored By
Mhurd
Oct 1 2015, 10:02 PM
Referenced Files
F3286722: iPhone 6 2x Copy 2.png
Jan 27 2016, 7:42 PM
F3286718: iPhone 6 2x Copy.png
Jan 27 2016, 7:42 PM
F3286719: iPhone 6 2x.png
Jan 27 2016, 7:42 PM
F2651667: 1.png
Oct 1 2015, 10:02 PM
F2651671: 4.png
Oct 1 2015, 10:02 PM
F2651668: 2.png
Oct 1 2015, 10:02 PM
F2651669: 3.png
Oct 1 2015, 10:02 PM
F2651670: 5.png
Oct 1 2015, 10:02 PM

Description

A couple of Wikipedia Zero bits have broken slightly since 4.x

Important so people know if they're going to be charged when trying to open any external ( hence non-zero-rate "free") links from the app.

Minimum functionality (from 4.x series)

1 - first link click after going from non-zero to zero rated:

1.png (801×487 px, 175 KB)

2 - subsequent link clicks while still zero rated:

2.png (801×487 px, 143 KB)

3 - same as 2:

3.png (801×487 px, 204 KB)

4 - first link click going from zero-rated to non-zero rated:

4.png (801×487 px, 246 KB)

5 - a few seconds after 4:

5.png (801×487 px, 245 KB)

Things in 5.0 which don't seem to be working properly at the moment:

  • popup alert sometimes shows more than once in a row
  • bottom indication that they are browsing zero-rated (the pink bottom bar in screenshots) not showing

Note: the pink / w green text is only used when testing. Carriers specify these colors iirc.


Proposed design

  1. When wikipedia zero is ON we will tint the status bar to blue.
  2. Every sesssion of app we will do an animation on top to show the words wikipedia zero in a subtle way for few seconds
  3. When leaving wikipedia zero we will show an UI alert with relevant language
  4. We dont need to show an UI alert when wikipedia zero is enabled. the tinted status bar and words will do the trick

Video of animation when wikipedia zero is enabled
https://youtu.be/7CIzpszJw74

Mocks

iPhone 6 2x Copy.png (1×750 px, 490 KB)

iPhone 6 2x.png (1×750 px, 487 KB)

When leaving

iPhone 6 2x Copy 2.png (1×750 px, 393 KB)

Event Timeline

Mhurd raised the priority of this task from to Needs Triage.
Mhurd updated the task description. (Show Details)
Mhurd moved this task to Needs Triage on the Wikipedia-iOS-App-Backlog board.
Mhurd subscribed.
Mhurd set Security to None.
Mhurd renamed this task from Restore Wikipedia Zero alert handling to Restore Wikipedia Zero alert handling for 5.0.Oct 1 2015, 10:35 PM
JMinor triaged this task as Medium priority.Oct 2 2015, 3:36 AM

We should also consider alternative placements and UI of the bar.

I wish we could just use the status bar, but thats a no-no. Although we could change the tint depending on Zero status.

I wish we could just use the status bar, but thats a no-no. Although we could change the tint depending on Zero status.

There are ways... https://github.com/jaydee3/JDStatusBarNotification

That's the framework I used to implement EventLogging visualization for the Lyon hackathon

We can also change the global tint color for all navigation bars, but there are also external links to consider.

Nirzar raised the priority of this task from Medium to High.Jan 22 2016, 12:22 AM
MBinder_WMF renamed this task from Restore Wikipedia Zero alert handling for 5.0 to EPIC: Restore Wikipedia Zero alert handling for 5.0.Feb 3 2016, 9:45 PM

For devs, just in case you end up in networking headers, keep in mind we don't need MCCMNC header information (T126471), so feel free to remove it as a "boyscout" change

Lest there be confusion, that scout task T126471: Remove MCCMNC header information is for the once-per-cellular-session X-MCCMNC request header enrichment performed at the client, which in turn results in a server side API (api.php) post-processing hook doing sampling on that header and logging it to event logging. In other words, it's generally independent of the client side header detection and state machine.

Presently the iOS app uses mdot subdomains, for which Varnish and the origin server do response header enrichment when the user is on a known zero-rated network, so you should be able to use the same header detection approach as before so long as you're using mdot for the general case.

However, if you plan to start using desktop subdomains, which is what the Android app is fast approaching both for RESTbase and api.php, you'll want to emulate their detection approach, which is being built. @Mholloway should be able to step you through what that entails with a code review of the Android flavored Java, as he and @Niedzielski are in the midst of this sort of stuff on Android.

For the record, I wouldn't suggest switching to destkop subdomains in the middle of the march to v5 of the app. Not that you were considering that (unless you already did that!).

For the record, I wouldn't suggest switching to destkop subdomains in the middle of the march to v5 of the app. Not that you were considering that (unless you already did that!).

FWIW, the app already falls back to desktop, based on certain error conditions.

Anyway, seems like there's more at play here... will sync with you when this is being worked on.

JMinor lowered the priority of this task from High to Medium.Feb 16 2016, 11:08 PM