Page MenuHomePhabricator Making banners work and responsive
Closed, ResolvedPublic13 Estimated Story Points


In January, we have released a new design of The previous website design was made in around 2007 and was still adhering to HTML 4.01 and not responsiveness was not given - the page applied no scaling at all on mobile devices, for example. The banners for were built with this in mind and are not responsive at all. The new design requires banners to be fully responsive for all resolutions (320x640 and up).

With this in mind, a new reference banner for needs to be created which is an updated version of the previous "red banner" design used on

Designs must be supplied for mobile, tablet and desktop. For more infos, read the discussion below.

Event Timeline

Current CTRL-Banner that needs to be working:


  • new data metrics should be introduced: Banner-size-Issue und Viewport-Tracking
  • respective data must be collected
  • Definition of Cluster
  • Design of "banners" aka each cluster must be done
  • A/B-Test vs current Ctrl

If that does not work or if the workload is too much, we need to trial and error.

Tobi_WMDE_SW set the point value for this task to 13.Sep 30 2019, 10:39 AM

@gabriel-wmde What we actually need are the viewport sizes of the banner impressions. And the viewport sizes of intances of banner-size-issues (which are not implemented yet, of course). From both data we can understand how big a banner can get in certain viewport areas and how many impressions (aka users) are in certain viewport size areas. This then is the base of a definition of clusters for a responsive banner. At least we used that approach on

Hey @Tobias_Schumann_WMDE-ext,

as you write yourself, right now there is no data on "banner size issues" since that is not a thing on up until now. However, Matomo has pretty extensive records about all visitors to for this year.

Since we have full control over the website and the banners, there is simply no need for "banner size issues". We can already determine what the maximum height for a banner is that we are comfortable with for every resolution group (desktop, tablet, phone) and we can also determine important resolutions for this purpose. I would assume the aim should definitely be that the banners are shown to all users of and that we should not have any "banner size issue" code in place.

For example, the smallest resolution we regularly see for mobile phones is 320x480 according to the data I sent you via email, that's equivalent to an iPhone 4 or similar. If it's a requirement that the search bar and the Wikipedia logo need to be visible, we can already determine that the maximum height of the banner should be around 200 pixels when the viewport width is 320px. Since that is our reference point, we already know that there will not be any "banner size issues" for any other mobile device (320x480 is also the smallest resolution we target on the Spenden application):

We can repeat this process for the other resolution groups (desktop and tablet) and come up with a responsive banner for this purpose. I was suggesting that we maybe do a hybrid banner which includes the sliding banner from last year but we can also switch to a static design on mobile.

Keep in mind that it's not possible to deliver a "non-responsive banner" to the redesigned because it "does not make sense" from a technical point of view - the banner must be responsive. If what I wrote is not clear, please don't hesitate to ask me, when in doubt we can also talk about in person or over the phone to speed this up. Please note that this ticket is in our current sprint and we plan to finish it within the next two weeks in order for the banners to be ready for the campaign start.

Also pinging @Jan_Dittrich and @Erdinc_Ciftci_WMDE.

As the task does not have a description: What is needed as input from UX? What are the current problems?

it is basically making a banner responsive including respective designs for the different viewport cluster. How the banner reacts to certain break points, need to be defined though. Due to the high ratio of mobile users, the banner design must be modified more than the responsive banner design on - that is for sure.

I have created a ticket description to give an introduction to the topic and left a link to a working version of an old banner from a web archive.

I also wanted to note that for, we have always used two banner "styles" for each banner: A large and small version. The large version is only shown the very first time a user sees a banner and the small version is shown all times after that (up to 10 times, I believe). We need to take this into account and I guess @tmletzko also needs to decide if the mobile banners also become larger on the first load or if they will always stay relatively compact. Maybe there are also some clever ways to make the banners more visible (but also more annoying) on mobile on the first page load. Either way, it's something we need to think about as part of this ticket.

Since the size of the banner is the main reason for the "two style concept" whileas now due to the responsiveness the size changes, we do not need the "two style concept" anymore. Therefore: the designs of the respective view port cluster should be relatively compact. How compact/big the banners will be at the end need to be discussed, though.

@tmletzko I am confused, I thought the initial banner is bigger to draw more attention rather than being related to responsiveness?

So, in our little meeting @Tim_WMDE we talked about:

  • 3 versions needed: iPhone-4 resolution (320 width), Portrait Tablet (768*1024 eg), Desktop (width 1280+)
  • possible: one fully responsive OR the slidy-banner + desktop and tablet version
  • there needs to be a "big on first load" for the desktop banner?

As for the working mode: It should be the same red banner as we are used to, so no redesign or bigger changes. This would leave us with defining the responsiveness. However, this is something hard to do in our design tools because in frontend terms they work with "absolute positioning" (simply put). So I would suggest we would deliver more something like sketches for where to put the breakpoints and what to show and what not, since putting everything into figma for the one thing such tools are not good at does not make a lot of sense to me.

The exact behavior (no matter how hi-fi our deliverables are) would need to be determined in code in collaboration with the developers.

I am confused, I thought the initial banner is bigger to draw more attention rather than being related to responsiveness?

yes, that is the reason behind the non-responsive banners. With the introduction of the responsiveness we have a new concept and the height of each banner (mobil, ipad, desktop) will be reconsidered. The old concept is not needed anymore.

the reference banner for responsiveness is this one should be adapted to the excisting banner. BUT the sentence "Es ist ein bisschen unangenehm, daher kommen wir gleich zur Sache." should always be there. That was a mistake back then.

chrp renamed this task from Making banners work and responsive to 🎬 | Making banners work and responsive – ⏰ 10.11..Nov 4 2019, 2:26 PM
chrp edited projects, added WMDE-FUN-Funban-2019; removed Internet-Archive.
chrp renamed this task from 🎬 | Making banners work and responsive – ⏰ 10.11. to Making banners work and responsive .Nov 4 2019, 3:26 PM
chrp removed a project: WMDE-FUN-Funban-2019.
Aklapper added a subscriber: Tim_WMDE.

Resetting task assignee as the assignee user account has been disabled.