Page MenuHomePhabricator

Spike: how to implement banner sequence feature
Closed, ResolvedPublic1 Estimated Story Points


This is an investigation task for the request below.

From @MeganHernandez_WMF
Banner history/central notice -- sequence test (We talked about this last year but not sure if it is in phabricator. We can currently show a large banner on the 1st impression and then small banners on later impressions. We’d like to test more variations (one ex. Large banner on imp 1, medium banner on imp 2, small banner on imp 3.) We talked about mixins or adding more buckets for this. It would be good to find the simplest way to test this since we don’t know all the options we’ll want to try yet & how it will perform. Maybe adding 2 more buckets for a first test would be the easiest way to help us get an idea?)

Related Objects

Event Timeline

DStrine renamed this task from Configuring a banner sequence test to Spike: Configuring a banner sequence test.May 17 2016, 8:18 PM
DStrine updated the task description. (Show Details)
DStrine moved this task from Triage to Sprint C Feb 15 - March 1 on the Fundraising-Backlog board.

It crossed my mind that we might be able to produce sample code for doing a sequence test, then hand off to the banner team to play with. However, they might not have enough time to make this a worthwhile approach.

Still, it seems like the rules for conditionals and banners to display should be editable by the banner team, maybe a hook supplied by the banner? Gah.

Initial consensus in today's tech priorities meeting was that we should avoid anything involving buckets even for the trial implementation.

AndyRussG renamed this task from Spike: Configuring a banner sequence test to Spike: how to implement banner sequence feature.Jun 14 2016, 7:50 PM
AndyRussG set the point value for this task to 1.

Here's what I have so far:

  • This should be implemented as a mixin (previously discussed as a likely option).
  • Some tweaks will be necessary to the banner choosing code to allow mixins control over banner choice. Maybe we should create a new hook for this mixin.
  • More tweaks will also probably be needed to the mixin parameter system, including the UI... Unless we could make do with a fixed number of steps in the sequence. I guess this might be OK for an initial MVP, but it seems less than ideal!
  • Finally, the output of Special:BannerAllocation should also be tweaked to show multiple banners for each bucket.

I have the feeling that the changes needed to CN to support the fallback feature are more basic and logically go first. However, before coding on either, it might be helpful to have a mock-up of how Special:BannerAllocation might look once both fallback and banner sequence features are implemented.


That sounds good--I'm curious what the sequences will look like. We're talking about testing two sequences against each other, I understand. So the admin will have to configure two lists of banner names? There will be validation or autocomplete help to make sure the banner names are correct?

Here are the notes we have for an MVP. I don't know if we should leave this task open until we finalize details of a more usable version...

This is fine to resolve. Thanks for working through this!