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.
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| Large banner limit mixin | Ejegg | mediawiki/extensions/CentralNotice | master | +135 -2 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T112923 [EPIC] Banner history post launch | |||
| Resolved | Ejegg | T90919 Show large screen banner and then top screen banner without losing an impression | |||
| Resolved | awight | T112017 Write banner diet campaign mixin |
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.
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?
Change 247460 had a related patch set uploaded (by Ejegg):
WIP Large banner limit mixin
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?
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.