It seems to be ready to go, they all have nice yellow batches, now :)

@Jan_Dittrich what about the vertical form of this design? We would need that too. Or is this provided somehow else?

@Jan_Dittrich what about the vertical form of this design? We would need that too. Or is this provided somehow else?

What do you mean with vertical form? The banner, overall being vertical (more high then wide, e.g. on a mobile screen) ) or the form sections in it being vertically positioned to each other? (e.g. on a right-hand-column?)

the design, in which the form is on the right side of the banner (and in which the form sections are positioned underneath each other)

This is a layout that does not exist in this banner, since it makes the banner too high.

as Tobias already wrote in Asana:

"Indeed that would increase the banner height too much but since this test is part of a longer test row that is not so much a problem. Let me explain our rationale: In the next test of this test row (currently scheduled as test 10, see: https://docs.google.com/spreadsheets/d/1poP2ZLNLST1eGE2sBQq_l7yRiAcRGjrHZ0jtR1TkFiA/edit#gid=0) we would introduce a two-step donation form in the banner. The (new) part of the form where one chooses to state an address or not would be the content of the second step of the donation form then. Therefore the banner wouldn't be too big anymore. But in the first step we want to test solely that option of choosing to state an address and to learn about the effect it generates. The control banner would be also increased in height to exclude the effect of different banner sizes.

So, as it is only a step-in-between, it is important to also have a design of the address-option for the vertical form layout. "

Therefore, we would need a design for this layout aswell.

So, if I understand correctly, the banner would:

1. start with a the usual vertical, right-hand-form
2. on making the browser smaller, switch to the full-width form
3. when the browser becomes even smaller, the full width form would have another step where the Kontonummer etc. is below the form.

This is what was implemented by @CorinnaHillebrand_WMDE already, so I would not create an additional design, since the code is already there anyway (and looks all good).

@CorinnaHillebrand_WMDE @Tobias_Schumann_WMDE-ext

I wonder if it would make sense not to test against the old banner (which is what I would read from the description above) but against a copy of this new banner, but with the address switch hidden.

yes, we can also use the banner without the adress switch if that makes it easier to implement.
@CorinnaHillebrand_WMDE if we hide the banner switch section, that might cause some ugly free spaces. Maybe the spacing should be adjusted slightly. If that is ok for you, we can proceed with copying the new banner.

According to my understanding at this point,

• the (updated) CTRL will be this: (question titles are visible, address switch is hidden)

The design is approved by @Jan_Dittrich.

• the VAR will be this (not 100% finished): (question titles are visible, address switch is visible)

What still is slightly in question is how the IBAN information should be displayed on the resized banner on "medium size"
because it gets a bit cramped in this grey box with the 4 question columns.
current cramped VAR solution:

it gets a bit cramped in this grey box with the 4 question columns.

Could we put Überweisung/Paypal below Lastschrift/Kreditkarte in case the banner gets this small? The form area is 4 bullet points high already.
I guess that should be possible with flexbox. And

I wonder if having the payment amounts back into two lines is an option. The banner introducing the headlines was designed like that (see here) but not implemented like that (see here). Somehow we switched to a three lines section. Any objections to have them on two lines again like we had in Test 4?

Could we put Überweisung/Paypal below Lastschrift/Kreditkarte in case the banner gets this small? The form area is 4 bullet points high already.
I guess that should be possible with flexbox. And

I wonder if having the payment amounts back into two lines is an option. The banner introducing the headlines was designed like that (see here) but not implemented like that (see here). Somehow we switched to a three lines section. Any objections to have them on two lines again like we had in Test 4?

did both ✔️

Additional question about this acceptance criterion:

if you click the radio button "nein" in the adress data section and afterwards change the payment method to BEZ, a respective notice is being displayed (according to the respective notice for this use case which we use for VAR of Test 6)

what is implemented so far

• step 1 ("Nein" is clicked):

Notice message is getting shown

• step 2 ("Lastschrift" (BEZ) is clicked):

In this step the address switch automatically switches to "Ja" (and hides the notice message, "Nein" becomes disabled anyway)

@CorinnaHillebrand_WMDE in the current test the solution for this use case is the notice "Für Lastschriften ist die Angabe einer Adresse erforderlich." (open the current VAR banner, submit PPL as payment method, click _no_ in adress data switch on landingpage, click "Zahldaten ändern", on page 1 of the landingpage, the notice is being displayed and BEZ is deactivated).

The automatic switch is doable but not optimal since a user might not see that the switch is automatically changed. But on the other side applying the whole landingpage logic to the banner might be problematic because you would have to deactivate BEZ once a user clicks no and show the notice "Für Lastschriften ist die Angabe einer Adresse erforderlich." at the same time That is too much useless moving.

Therefore, I would add the notice to your solution: "If a user checks no in the adress switch and afterwards choose the payment method BEZ, the adress switch will be automatically changed to ja and the notice "Für Lastschriften ist die Angabe einer Adresse erforderlich." appears.

I updated the notice for the automatic switch to "Für Lastschriften ist die Angabe einer Adresse erforderlich." as @tmletzko proposed.

A change that had to be done was the following (already checked with @Jan_Dittrich):
At a certain resolution the space for the grey form became way too narrow,

@CorinnaHillebrand_WMDE looks neat for the most part.
5 things that need to be fixed please.

1.)
Landing pages aren't correct as both CTRL and VAR are using the same landing page at the moment.

It should be:
CTRL = Banner WITHOUT address-data-switch, leading to Laika WITH address-data-switch (VAR of Test 06)
VAR = Banner WITH address-data-switch, leading to Laika WITHOUT address-data-switch (CTRL of Test 06)

2.)
"Heute ist der 5. Tag unserer Spendenkampagne. "
This sentence needs to be completely removed in CTRL+VAR

3.)
CTRL looks like this in IE :(
(it's fine in all other browsers)

4.)
when chosing to pay by creditcard the tracking in our backend says "04-ba-190902/org-04-190902-10h16" while I definitely didn't use 10h16 but laika

5.)
No make or brake but weirdly the payment methods are slightly closer cramped together in the vertical version of the VAR (with address-data-switch) banner

ctrl

4.)
No make or brake but weirdly the payment methods are slightly closer cramped together in the vertical version of the VAR (with address-data-switch) banner

@JanJaquemot which browser did you use here?

6. in both banners the radio buttons are not positioned correctly. Monatlich is too close to radio button jährlich.

@JanJaquemot which browser did you use here?

This happened in Chrome

in both banners the radio buttons are not positioned correctly. Monatlich is too close to radio button jährlich.

@tmletzko same question here: which browser produced this? we can't seem to reproduce it on IE, Firefox, Chromium and Chrome...

sorry. FF 70, Windows but I found out why it looks like this. Zoom was on 90 %. We do not have to take that into consideration though.

so 6) is not an issue anymore.

Can confirm that all my points 1-5 are successfully solved. Thanks!

See issue at https://phabricator.wikimedia.org/T236465
Different sizes (at least on Firefox)

Fixed