Page MenuHomePhabricator

Show large screen banner and then top screen banner without losing an impression
Closed, ResolvedPublic2 Estimate Story Points

Description

Currently, we have to do something sneaky when loading a campaign that goes from fullscreen to top banner. We're unable to show anything on the first impression in the current system.

For this task, we would write a campaign mixin that records having seen a fullscreen banner in a campaign-related KV store, and if this value has already been set for a reader, we display the top-screen banner instead.

Details

Related Gerrit Patches:
mediawiki/extensions/CentralNotice : masterLarge banner limit mixin

Event Timeline

atgo created this task.Feb 26 2015, 7:57 PM
atgo raised the priority of this task from to Medium.
atgo updated the task description. (Show Details)
atgo added subscribers: atgo, Aklapper, AndyRussG.
awight updated the task description. (Show Details)Sep 15 2015, 5:23 PM
awight set Security to None.
awight edited a custom field.
Ejegg added a subscriber: Ejegg.Oct 16 2015, 9:20 PM

Any ideas on a UI for this? Seems we want each bucket to have a banner sequence defined by a series of (banner, numViews) entries. We'd have to make mixin parameter input a lot more flexible, maybe registering client-side callbacks.

  • render
    • called initially and on mixin activation or deactivation, with active status and any saved params
    • responsible for showing or hiding mixin controls, in this case altering the bucket banner assignment controls
  • save
    • called when user saves campaign and mixin is active
    • responsible for gathering and serializing input from rendered controls
Ejegg added a comment.Oct 19 2015, 7:17 PM

Per IRC, decided that MVP is just to duplicate current behavior, where big banners are in buckets A and B, and viewers are moved to buckets C and D after an initial impression.

TBD: should we suppress big banners across campaigns as current code does? Should we use cookies to stay compatible with existing scripts?

Ejegg claimed this task.Oct 19 2015, 8:08 PM
Ejegg moved this task from Backlog to Doing on the Fundraising Sprint Vengaboys board.

Change 247460 had a related patch set uploaded (by Ejegg):
WIP Large banner limit mixin

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

Questions for @Pcoombe and @MeganHernandez_WMF:

Andrew pointed out that there are two versions of the bucket swap script, one that always puts viewers from A into C (https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/ChangeBucket-AtoC-BtoD.js), and one that randoms assigns A/B users to either C or D (https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/ChangeBucket.js).

Is the random one still used? I see that it hasn't been included in banners since last December. If that functionality comes in handy, I'll make randomizing the switch an option in the mixin.

The current script uses the same cookie for all campaigns - do you want the option to change the cookie name per campaign as with the impression diet mixin?

Also, it would be great if we could switch from cookies to local storage when available. The mixin can keep checking the old cookie for backwards-compatibility, but you'd have to update the on-wiki code to look in both places if some banners continue to use it. Any objection to that?

@Ejegg

Questions for @Pcoombe and @MeganHernandez_WMF:
Andrew pointed out that there are two versions of the bucket swap script, one that always puts viewers from A into C (https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/ChangeBucket-AtoC-BtoD.js), and one that randoms assigns A/B users to either C or D (https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/ChangeBucket.js).
Is the random one still used? I see that it hasn't been included in banners since last December. If that functionality comes in handy, I'll make randomizing the switch an option in the mixin.

Both of these are still used in current banners, you just have to look quite a long way down WhatLinksHere for them. A switch for random/deterministic would be great.

The current script uses the same cookie for all campaigns - do you want the option to change the cookie name per campaign as with the impression diet mixin?

I'm not sure we'll be using different names per campaign. However there may come a point where we do want to change cookie names to start afresh (e.g. at the end of the year). So it would probably be safest to have an option for cookie name.

There's also the possibility that other non-fundraising groups will want to use the mixin.

Also, it would be great if we could switch from cookies to local storage when available. The mixin can keep checking the old cookie for backwards-compatibility, but you'd have to update the on-wiki code to look in both places if some banners continue to use it. Any objection to that?

Agreed that moving to local storage would be nice, but I'm not sure how complicated the changes are going to be? If it's risky/complicated, we might want to wait until after December.

Thanks @Pcoombe. Latest version of the patch has options for randomizing bucket transition and changing cookie name, with the cookie name defaulting to the same as in the on-wiki script. It doesn't move to local storage. I don't think the localstorage changes will be too risky or complicated, but it's an easy piece to leave for another patch.

Change 247460 merged by jenkins-bot:
Large banner limit mixin

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

Ejegg closed this task as Resolved.Nov 24 2015, 7:16 PM