Page MenuHomePhabricator

AMC Outreach - Modal
Closed, ResolvedPublic5 Estimated Story Points

Description

User Story

As an advanced editor, I would like to know when advanced mobile contributions are available

Design

person lands on pagedrawer appears after short delay, taps "Enable"advanced mode enabled, toast displays

Link to svg: https://upload.wikimedia.org/wikipedia/commons/0/07/Advanced_mobile_features_graphic.svg

Acceptance Criteria

  • Note: Public name for AMC was changed in T225747. Although above mocks still refer to "Advanced contributions mode", the actual copy should instead read as "Advanced mode"
  • Display the modal for all logged in editors with >100 edits on the mobile website who are not in AMC mode
  • The 100 edit threshold should be configurable. It should be possible to show to editors with 0 edits.
  • The modal must be displayed only once
  • Selecting "try it out" should turn on AMC automatically (without requiring the user to go to the settings page
  • To support T226069 make sure that drawers render above overlays in the display stack (higher z-index) (Per https://phabricator.wikimedia.org/T226068#5385909 the drawer should go under the overlay)

Developer notes

Things we'll need:

  1. The drawer (can use existing CtaDrawer code)
drawer = new d( { content: 'text goes here', progressiveButton: { label: 'Enable', progressive: true, events: { 'click': () => alert(5) } }, actionAnchor: { label: 'No thanks' } } ); drawer.$el.appendTo( document.body ); drawer.show()

2) Code to take care of the enabling - the click event above will need to make an API request to Special:Preferences to set

Something like:
```/w/api.php?action=options&format=json&optionname=amc&optionvalue=1

(note you'll need a token and the correct optionname)

QA steps (ready now)

This is now on the beta cluster and enables all logged in users with >= 0 edits to see the drawer (the # of edits is configurable and was set to 0 to make testing easier).

This is a bit of a pain to test multiple times because the drawer should only show once per browser/device combo. A way to get around this is to use a new incognito mode window in chrome (iOS Safari has their own version of that at https://support.apple.com/en-us/HT203036) every time you want to see the drawer:

  1. If you have enabled AMC at https://en.m.wikipedia.beta.wmflabs.org, turn it off
  2. Close all previous incognito windows, launch a new incognito window, and login to https://en.m.wikipedia.beta.wmflabs.org
  3. You should see the drawer

When user is logged in with AMC turned off and user declines

  • Follow steps 1 - 3 and assert that you see the drawer.
  • Assert that the drawer remains visible when attempting to scroll.
  • Dismiss the drawer by tapping the "No thanks" link or by tapping the black part of the overlay.
  • After dismissing the drawer, refresh the page. You should not see the drawer again if you are using the same browser on the same device (unless you launch a new incognito window).

When user is logged in with AMC turned off and user accepts

  • Follow steps 1 - 3 and assert that you see the drawer.
  • Enable AMC by tapping the "Enable advanced mode" button. Assert that the page refreshes with AMC mode turned on. You should remain on the page that you enabled AMC from (you should NOT see the settings page).
  • After enabling, refresh the page. You should not see the drawer again.
  • Make sure you can disable AMC mode by going to the mobile settings page and toggling AMC mode off. Assert that you do not see the drawer again after turning AMC mode off.
  • Refresh the page and assert that you do not see the drawer again.

When user is anon

When user is logged in with AMC turned on

  • Follow steps 1 - 3, assert that you see the drawer, and enable amc. Now log out.
  • Log back in to https://en.m.wikipedia.beta.wmflabs.org
  • Make sure when you log back in that AMC remains on and you do not see the drawer

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
ovasileva set the point value for this task to 5.Jul 2 2019, 4:28 PM
ovasileva moved this task from Needs Prioritization to Upcoming on the Readers-Web-Backlog board.
Jdlrobson updated the task description. (Show Details)Jul 2 2019, 4:32 PM
Jdlrobson updated the task description. (Show Details)Jul 17 2019, 4:47 PM
Jdlrobson updated the task description. (Show Details)

@alexhollender the task description shows a tablet icon on the drawer; where can I find this icon?

@alexhollender the task description shows a tablet icon on the drawer; where can I find this icon?

sorry for not including that, just added it to the description (https://upload.wikimedia.org/wikipedia/commons/0/07/Advanced_mobile_features_graphic.svg)

Change 525688 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/extensions/MobileFrontend@master] WIP: Add Amc Outreach Drawer on page load

https://gerrit.wikimedia.org/r/525688

nray added a comment.Jul 29 2019, 6:35 PM

@alexhollender @ovasileva I'm thinking we need to make it so that if the user has AMC enabled and then turns it off in their settings, they will also not be eligible to see the outreach modal (even if they haven't seen the outreach modal before). Otherwise, when this feature lands, if people who currently have AMC enabled try to disable it in their settings, they would see the modal appear as soon as they turn off AMC and that would probably be pretty irritating.

Does that make sense?

@nray yes, the intention sounds right. What would the criteria be? If they ever had AMC mode on (but now have it off), and/or if they have it on at the time we release it, and then switch it off? I think either way would work. The only downside I can think of (if it was the former) is that we might miss some folks from the test wikis who tried in early on and then switched it off, though that doesn't seem like too big of a deal.

Maybe the acceptance criteria should be:

Display the modal for all logged in editors with >100 edits on the mobile website who are not, and never have been, in AMC mode

nray added a comment.EditedJul 29 2019, 7:23 PM

@alexhollender I was thinking for simplicity it would work like this: After the Outreach feature is released and turned on, if the user turns off AMC from their settings page, they would not be eligible to to see the Outreach modal ever again.

The users who turned off AMC before the Outreach feature is released is a much trickier problem and I'm not even sure we have enough data on that to do anything about it even if we wanted to. For those users (and assuming they still have AMC turned off when logged in), they would still be eligible to see the Outreach drawer.

Change 526236 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/extensions/MobileFrontend@master] 📝 Correct comment on FeaturesManager isFeatureAvailableForCurrentUser method

https://gerrit.wikimedia.org/r/526236

@alexhollender I was thinking for simplicity it would work like this: After the Outreach feature is released and turned on, if the user turns off AMC from their settings page, they would not be eligible to to see the Outreach modal ever again.

Sounds good

Change 526236 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] 📝 Correct comment on FeaturesManager isFeatureAvailableForCurrentUser method

https://gerrit.wikimedia.org/r/526236

Quiddity removed a subscriber: Quiddity.Jul 30 2019, 2:02 AM
nray added subscribers: jcrespo, phuedx.EditedJul 30 2019, 6:37 PM

@jcrespo (cc: @phuedx) To implement this feature and given that there is a requirement that the drawer can only be shown once to the user regardless of the device/browser (I will be questioning this requirement in a later post), I think we need to make use of the user_properties table and add a record to that table when the drawer is shown. That record would then serve as a flag to not show the drawer again. However, I'm wondering if the number of records this will add to the database is an acceptable number. It would basically work like this:

  1. For every user that is logged in, does not have the Advanced Mobile Contributions feature enabled (most users), and is on the mobile version of the wikipedia (e.g. https://en.m.wikipedia.org/), a drawer would appear when the page loads that would fire an ajax request to the mediawiki api options endpoint to set an option (e.g. mf_amc_outreach_eligible_on_load = 0). Because this value would be the non-default value for this option (the default is to show the drawer), it would add a new record to the user_properties table.
  1. On subsequent page loads, we would check this option to see if we should show the drawer again. If the record for the user was in the user_properties table, we would not show the drawer again.

Bottom line: We could be adding up to n records to the user_properties table where n is the number of logged in users visiting the mobile website who don't have AMC enabled.

Question: Is adding this number of records to the user_properties table okay?

nray added a subscriber: MNeisler.EditedJul 30 2019, 8:10 PM

7/30 Update and crossroads

As this task has lingered, I want to provide an update on what's happening:

I have a patch ready that would sufficiently meet the AC including "The modal must be displayed only once". However, after discussing this patch today with @phuedx, there is an open question/concern (see my comment to jcrespo above) as to whether the number of records this patch would need to add to the database is an acceptable amount. Additionally, I think to support T226069 there could be up to 4x as many records as the patch I have for this ticket unless some tweaking was done to the code I wrote.

I was also discussing this with the dev team today, and I'd like to nail down whether or not we can make that particular AC point, "The modal must be displayed only once", less stringent as it would save a great deal of time, complexity, and energy. My understanding of this AC point from the discussions we've had during grooming, etc is that the drawer should only show once to the user regardless of the device/browser they are using. That is, if they are logged into one device without AMC enabled, they will be eligible to see the drawer, and if they've already seen the drawer and then log into another device without AMC enabled, they should not see the drawer.

Given that understanding is correct, in order to support this AC point, we have to add records to the database to flag whether or not the user has seen the drawer and a great deal of complexity is introduced.

The alternative

There is another option involving the use of localStorage (the betaOptinPanel uses this) that is not as robust as using the database, but it would substantially limit the complexity involved. The flag would be tied to the particular browser/device they are using. In other words, if the user is logged into the mobile site on a particular device using a particular browser and dismissed the outreach drawer (with AMC still disabled), it would still be possible for them to see the drawer if any of the following things happened:

  1. They use another browser on the same device
  2. They use another device

However, they would not see the drawer again if they used the same browser on the same device. They would also not see the drawer in either scenario if AMC was active.

The other downside of this approach is without some additional work to the logout page, another user using the same device and the same browser would also not see the drawer even if they were logged in with AMC turned off and had never seen the drawer before. If that's a blocker, then I think we could get around that by adding a small amount of JS in the logout page (though I'm not sure of the effort involved with that).

Assuming that most of our mobile users only use the mobile site with one device/browser (@MNeisler do we have any data on this?) I don't see any of the listed downsides as a huge problem especially if we are already content with potentially showing a user the drawer multiple times in T226069.

Bottom line: In order to fully satisfy the AC point "The modal must be displayed only once" a great deal of complexity is involved.

Question: Can we relax this AC point a bit with the previously mentioned "alternative" solution?

@ovasileva @alexhollender thoughts?

Thanks for the through notes, @nray.

I'd love for us to strike a balance between practicality, making a foundation to show drawers like this again in the future, and knowing that this outreach drawer is temporary and to be deleted(!). @nray, @ovasileva, @alexhollender, is it possible for us to start with the localStorage approach and pursue more permanent solutions only as needed?

nray added a comment.Jul 31 2019, 12:08 AM

I've moved this into code review. In my latest patch I implemented the feature using local storage (it was mostly code removal) and pretty easy so I figured it was worth doing even if we end up preferring to use the database.

@nray thanks for the clear explanation of our options. I think it would be fine if (just to clarify I'm understanding correctly):

  • people see the drawer once per device/browser combo, rather than once total
  • people don't see the drawer at all if another user on the same device/browser combo has already seen it

I think this raises the question of the AC on T226069 — perhaps it should not be "Toast/modal must only display once per action". I will leave a comment there.

nray added a comment.EditedJul 31 2019, 5:51 PM

people see the drawer once per device/browser combo, rather than once total
people don't see the drawer at all if another user on the same device/browser combo has already seen it

@alexhollender Yes, your understanding is correct.

I think this raises the question of the AC on T226069 — perhaps it should not be "Toast/modal must only display once per action". I will leave a comment there.

Regarding the AC on TT26069, the localStorage solution would still enable us to show the drawer once per action (clicking the history link, talk link, desktop link, etc) but it would follow the same constraints as the load action that this ticket tackles - it would show once per action for the browser/device combo they used. If the user went on a different device/browser they could see the drawer again for all actions done on that device/browser.

nray added a comment.EditedJul 31 2019, 6:52 PM

@alexhollender I have three questions for you that are specific to this ticket:

  1. The default behavior of our drawers is to be dismissed when the user scrolls. You can see this behavior when you view an article on the mobile site anonymously (https://en.m.wikipedia.org/wiki/Tree), click the watchstar icon, and then start to scroll. The problem with this is that because this outreach modal can appear shortly after the page has loaded, the user could already be in the act of scrolling and inadvertently trigger its dismissal before even having a chance to view it. We can easily make the drawer prevent scrolling which is what the reference drawer does (when you click on a reference). I'm wondering if we should we make it act like the reference drawer and prevent scrolling?
  1. Should this drawer be able to appear on any page on the mobile site including the Main_Page (https://en.m.wikipedia.org/wiki/Main_Page)?
  1. There is an AC point on this ticket to "make sure that drawers render above overlays in the display stack (higher z-index)". However, I noticed that we currently have a CSS rule that specifically prohibits this saying "When overlays are opened drawers do not look good" [1]. maybe @Jdlrobson can elaborate on that comment since it appears he wrote it. Therefore, I'm just double checking that we are sure we would want the drawer to appear above any overlay opened. (e.g. if the user visited https://en.m.wikipedia.org/wiki/Tree#/languages)

[1] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/87426/9/less/common/drawer.less

nray added a subscriber: Jdlrobson.Jul 31 2019, 6:54 PM
nray added a comment.Jul 31 2019, 11:29 PM

@alexhollender sorry for the repeated pings, another question came up

  1. When should the drawer be considered to be ineligible to be viewed again? Is it as soon as it appears on the page (in which case the user would NOT see it again if they reloaded the page without clicking anything/scrolling once the drawer appeared) or should the user have to manually dismiss the drawer by clicking "No thanks" button or black part of overlay (in which case the user would see the drawer again if they reloaded the page without clicking anything/scrolling once the drawer appeared)?

@nray thanks for the clarifying questions

  1. The default behavior of our drawers is to be dismissed when the user scrolls. You can see this behavior when you view an article on the mobile site anonymously (https://en.m.wikipedia.org/wiki/Tree), click the watchstar icon, and then start to scroll. The problem with this is that because this outreach modal can appear shortly after the page has loaded, the user could already be in the act of scrolling and inadvertently trigger its dismissal before even having a chance to view it. We can easily make the drawer prevent scrolling which is what the reference drawer does (when you click on a reference). I'm wondering if we should we make it act like the reference drawer and prevent scrolling?

Good catch. Scrolling the page should not dismiss the drawer. I'm fine with allowing scrolling while the drawer is open (which for me is what happens with the reference drawer — I can scroll, but the drawer remains open), or preventing scrolling. Whichever is easier.

  1. Should this drawer be able to appear on any page on the mobile site including the Main_Page (https://en.m.wikipedia.org/wiki/Main_Page)?

Yes, although perhaps there's a caveat here related to question 3

  1. There is an AC point on this ticket to "make sure that drawers render above overlays in the display stack (higher z-index)". However, I noticed that we currently have a CSS rule that specifically prohibits this saying "When overlays are opened drawers do not look good" [1]. maybe @Jdlrobson can elaborate on that comment since it appears he wrote it. Therefore, I'm just double checking that we are sure we would want the drawer to appear above any overlay opened. (e.g. if the user visited https://en.m.wikipedia.org/wiki/Tree#/languages)

If we don't allow the drawer to appear over modals what would happen in the case where someone follows a link directly to a modal view (e.g. https://en.m.wikipedia.org/wiki/Spain#/talk) would/could it appear (or be waiting for them) when the close the modal?

  1. When should the drawer be considered to be ineligible to be viewed again? Is it as soon as it appears on the page (in which case the user would NOT see it again if they reloaded the page without clicking anything/scrolling once the drawer appeared) or should the user have to manually dismiss the drawer by clicking "No thanks" button or black part of overlay (in which case the user would see the drawer again if they reloaded the page without clicking anything/scrolling once the drawer appeared)?

Only after they've explicitly dismissed it.

nray added a comment.EditedAug 1 2019, 6:42 PM

@alexhollender Thanks for clarifying!

If we don't allow the drawer to appear over modals what would happen in the case where someone follows a link directly to a modal view (e.g. https://en.m.wikipedia.org/wiki/Spain#/talk) would/could it appear (or be waiting for them) when the close the modal?

Without changing anything, that's the behavior that would happen. The drawer with the black overlay would be visible after they closed the modal. I'm not saying that's the optimal behavior (I honestly don't know the best way to handle a drawer and a modal), but it is the current behavior we have now.

@alexhollender @nray that's easily fixed by https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/527195 Allow drawers on top of overlays. I don't think it's actually possible for a human to open an overlay on top of a drawer as clicking anything outside the drawer closes the drawer.

If we don't allow the drawer to appear over modals what would happen in the case where someone follows a link directly to a modal view (e.g. https://en.m.wikipedia.org/wiki/Spain#/talk) would/could it appear (or be waiting for them) when the close the modal?

Without changing anything, that's the behavior that would happen. The drawer with the black overlay would be visible after they closed the modal. I'm not saying that's the optimal behavior (I honestly don't know the best way to handle a drawer and a modal), but it is the current behavior we have now.

Cool I think that's what we should do...drawer waiting under the modal. I don't think opening the drawer on top of a modal will be a good experience.

Change 527606 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/extensions/MobileFrontend@master] Add children, additionalClassNames, onBeforeHide props to Drawer.js

https://gerrit.wikimedia.org/r/527606

Jdlrobson lowered the priority of this task from High to Medium.Aug 2 2019, 9:33 PM
ovasileva added a comment.EditedAug 5 2019, 3:51 PM

Just wanted to leave a note that I've read through the comments and support the changes in the acceptance criteria - @nray, @alexhollender

This comment was removed by ovasileva.

Change 527606 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Add children, className, onBeforeHide props to Drawer.js

https://gerrit.wikimedia.org/r/527606

Change 528289 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/extensions/MobileFrontend@master] Make SpecialMobileOptions.php support returnto redirects

https://gerrit.wikimedia.org/r/528289

nray updated the task description. (Show Details)Aug 6 2019, 5:23 PM
nray added a comment.EditedAug 7 2019, 11:40 PM

@alexhollender As mentioned in slack this is now up for design review at readers-web-staging.wmflabs.org, but it's a bit of a pain to test multiple times because it should only show once per browser. A way to get around this is to use a new incognito mode window in chrome (looks like ios safari might have their own version of that at https://support.apple.com/en-us/HT203036) every time you want to see the drawer. If that’s too much of a pain or doesn’t work, I can add more code to make it easier. To see the drawer now:

  1. If you have enabled AMC at readers-web-staging.wmflabs.org, turn it off
  2. Close all previous incognito windows, launch a new incognito window, and login to the mobile site
  3. You should see the drawer

Repeat steps 1-3 if you want to see the drawer again.

Please note: I used mostly default drawer styles for this so you'll notice some deviations from the mock in padding, button width, etc. I would like to know if we should leave as is, add styles specifically to this drawer to make it look like the mock or add the same styles to to our other drawers to all make them look more uniform.

Change 529121 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/extensions/MobileFrontend@master] Add Amc Outreach Drawer Feature

https://gerrit.wikimedia.org/r/529121

Change 529121 abandoned by Nray:
Add Amc Outreach Drawer Feature

Reason:
blah wrong change id

https://gerrit.wikimedia.org/r/529121

@nray sorry for the delayed review here. The drawer looks great (checked desktop & mobile). I think the styling is good. A few questions:

  1. Should the button say "Enable advanced mode"? I think it could be good to reinforce what you're doing by clicking the button.
currentupdatedupdated (imagining a longer string in some languages)
  1. It might be good to add a toast message for cases where people tap "No thanks" (or otherwise dismiss the drawer) saying: You can enable Advanced mode at any time in your Settings, just so they know how to get back to it if they want to. I feel like sometimes I don't like enabling things in "smart" ways, but would rather go into settings and do it manually.
  1. Now that I'm seeing/feeling it live something about the message seems slightly too short/direct to me. Even something as simple as:

Introducing Advanced Mode
Advanced mode makes it easier to access Talk pages, History pages, Recent changes, and other editor tools on mobile.

@ovasileva @nray thoughts on the above? Apologies for not thinking of this stuff earlier.

nray added a comment.EditedAug 9 2019, 6:32 PM

@alexhollender

Should the button say "Enable advanced mode"? I think it could be good to reinforce what you're doing by clicking the button.

Makes sense and is easy change

It might be good to add a toast message for cases where people tap "No thanks" (or otherwise dismiss the drawer) saying: You can enable Advanced mode at any time in your Settings, just so they know how to get back to it if they want to. I feel like sometimes I don't like enabling things in "smart" ways, but would rather go into settings and do it manually.

Unfortunately, our drawers are not really setup well rn to show a toast right after a drawer disappears. This is doable, but it's going to involve some refactoring of our drawers.

Now that I'm seeing/feeling it live something about the message seems slightly too short/direct to me. Even something as simple as:

Makes sense and is easy change. There is a discrepancy between the picture and the comment though. Should the intro say "Introducing Advanced Mode" or "Introducing Advanced mode"?

nray added a comment.Aug 9 2019, 7:24 PM

@alexhollender

All of your requested changes are now up on http://readers-web-staging.wmflabs.org.

The toast after the dismissal was actually easier than I thought it would be.

Note I'm still not sure what the capitalization of Advanced mode vs Advanced Mode should be?

@nray looks great. Adding updated screenshots below just as confirmation.

drawertoast after tapping No thanks

For the capitalization, I think it's fine as is.

@ovasileva @nray thoughts on the above? Apologies for not thinking of this stuff earlier.

Looks good!

Change 528289 merged by Jdlrobson:
[mediawiki/extensions/MobileFrontend@master] 🐛 Fix SpecialMobileOptions.php support of returnto redirects/single form submissions

https://gerrit.wikimedia.org/r/528289

Change 525688 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Add Amc Outreach Drawer Feature

https://gerrit.wikimedia.org/r/525688

nray updated the task description. (Show Details)Aug 12 2019, 11:47 PM
nray added a comment.EditedAug 13 2019, 12:50 AM

@ovasileva this has now been merged, but it is featured flagged and is turned off by default so we'll have to swat deploy to turn it on. The deploy should be pretty easy we only need to set the following config flags:

$wgMFAmcOutreach = true;
$wgMFAmcOutreachMinEditCount = 100; // the default

Please note that $wgMFAmcOutreachMinEditCount corresponds to the minimum number of edits a user should make before they are eligible to see the drawer (e.g. if set to 100, only people that have 100 or more edits will be eligible).

As you are aware from previous discussion on this ticket, because we are using the localstorage route due to increased complexity and questions surrounding the database solution, the drawer has a possibility of showing more than once if a logged in user without AMC enabled:

  1. Uses another browser on the same device
  2. Uses another device

A user could also see the drawer more than once if that user logs into their account using Incognito mode (with AMC turned off) since localstorage in incognito mode is transient. It could also happen if a user manually clears their browser's localstorage themselves (probably relatively unlikely).

All of the rest of the AC should be fulfilled.

Change 531303 had a related patch set uploaded (by Nray; owner: Nray):
[operations/mediawiki-config@master] Add config to turn AMC Outreach on for Beta servers

https://gerrit.wikimedia.org/r/531303

nray updated the task description. (Show Details)Aug 20 2019, 10:52 PM

Change 531303 merged by jenkins-bot:
[operations/mediawiki-config@master] Add config to turn AMC Outreach on for Beta servers

https://gerrit.wikimedia.org/r/531303

nray updated the task description. (Show Details)Aug 20 2019, 11:09 PM
nray removed nray as the assignee of this task.Aug 20 2019, 11:15 PM
nray updated the task description. (Show Details)
nray added a subscriber: nray.
nray added a comment.Aug 20 2019, 11:18 PM

@ovasileva This is now ready to QA on the beta cluster at https://en.m.wikipedia.beta.wmflabs.org

nray updated the task description. (Show Details)Aug 20 2019, 11:50 PM
nray updated the task description. (Show Details)Aug 21 2019, 2:20 AM

Looks good, moving to signoff. Details below:

When user is logged in with AMC turned off and user declines

Follow steps 1 - 3 and assert that you see the drawer.

  • Assert that the drawer remains visible when attempting to scroll.
  • Dismiss the drawer by tapping the "No thanks" link or by tapping the black part of the overlay.
  • After dismissing the drawer, refresh the page. You should not see the drawer again if you are using the same browser on the same device (unless you launch a new incognito window).
When user is logged in with AMC turned off and user accepts

Follow steps 1 - 3 and assert that you see the drawer.

  • Enable AMC by tapping the "Enable advanced mode" button. Assert that the page refreshes with AMC mode turned on. You should remain on the page that you enabled AMC from (you should NOT see the settings page).
  • After enabling, refresh the page. You should not see the drawer again.
  • Make sure you can disable AMC mode by going to the mobile settings page and toggling AMC mode off. Assert that you do not see the drawer again after turning AMC mode off.
  • Refresh the page and assert that you do not see the drawer again.
When user is anon

Close all previous incognito windows and launch a new incognito window at https://en.m.wikipedia.beta.wmflabs.org

  • Assert that you do not see the drawer (anon users should not see the drawer)
When user is logged in with AMC turned on

Follow steps 1 - 3, assert that you see the drawer, and enable amc. Now log out.

ovasileva updated the task description. (Show Details)Aug 26 2019, 2:56 PM
ovasileva reassigned this task from ovasileva to Jdrewniak.Aug 27 2019, 5:06 PM
Jdrewniak closed this task as Resolved.Sep 5 2019, 5:09 PM