Page MenuHomePhabricator

Put new address data switch on the banner
Closed, ResolvedPublic5 Estimate Story Points

Description

The scope of this banner test is to test the effect of adding a new section asking the user whether he/she wants to submit adress banner in the banner form. The not yet finalized design is on Figma. The banners are based on CTRL used in test 05 or if changing the height again is too tricky the Laika banner of test 04.

Acceptance Criteria

  • if you click on external payment providers and choose "no" the switch leads to the external payment providers. When doing so, we track this as a visit.
  • if you click on UEB and choose "no", you will be directed directly to the confirmation page
  • if you click on BEZ the radio button "nein" in the adress data section will turn deactive as seen on Figma. A respective notice is being displayed (according to the respective notice for this use case which we use for VAR of Test 6)
  • 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)
  • Error messages are displayed as shown in the design update of September 6th.
  • CTRL Banner leads to the laika skin of the donation page (VAR of Test 06; with adress data switch).
  • VAR Banner leads to the laika skin of the donation page (CTRL of Test 06; without adress data switch).
  • Changes to the Design: we do not show the notice as seen on the figma design "Ohne Adresse können wir Ihnen keine Zuwendungsbescheinigung ausstellen.". Instead a notice appears after I click on Nein in the adress data section. This notice is the same we have on the landingpage ("Bitte beachten Sie, dass wir Ihnen ohne Adressdaten keine Zuwendungsbescheinigung ausstellen können. ". The design of this notice shall be the same as the other notices.
  • banners have the same height

Notes:
For anonymous donations, the form should POST to https://spenden.wikimedia.de/donation/add and send the following fields:

  • betrag with amount with English decimal separator
  • zahlweise payment type
  • periode payment interval 0-12
  • addressType set to anonym
  • mbt set to 1 (for tracking while redirecting, see AddDonationController.php lines 59-69)

Remember to reset the fields for non-anonymous selection to the field names and URLs that are currently in the banner.

Event Timeline

tmletzko created this task.Oct 15 2019, 3:02 PM
Reedy renamed this task from Put new adress data switch on the banner to Put new address data switch on the banner .Oct 15 2019, 3:32 PM
tmletzko updated the task description. (Show Details)Oct 15 2019, 4:20 PM
Tim_WMDE moved this task from Todo to Doing on the WMDE-FUN-Sprint-2019-10-14 board.
Tim_WMDE set the point value for this task to 5.

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

tmletzko updated the task description. (Show Details)Oct 16 2019, 11:24 AM

@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?)

tmletzko updated the task description. (Show Details)Oct 16 2019, 12:09 PM

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.

Jan_Dittrich added a comment.EditedOct 16 2019, 3:01 PM

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).


(rescaled copy)

@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.

tmletzko added a comment.EditedOct 18 2019, 8:55 AM

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)


...with info message

...disabled on BEZ

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:


Should the IBAN info go in 1 line below the whole banner for this medium resized banner *?
(*this means: stretch the grey question area full length, put the IBAN info in 1 line below it like this:
)

Jan_Dittrich added a comment.EditedOct 22 2019, 9:24 AM

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)


Is this flow alright or does there have to be another notice/infomessage about this automatic switching to "Ja"?

@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,


so for this medium resolution banner the IBAN info is now in a line below the grey form in a horizontal alignment. (For smaller banners and larger banners the IBAN info is still in vertical alignment like before)

JanJaquemot added a subscriber: JanJaquemot.EditedOct 24 2019, 11:49 AM

@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


var

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?

  1. 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)

gabriel-wmde removed CorinnaHillebrand_WMDE as the assignee of this task.Oct 28 2019, 9:28 AM
gabriel-wmde moved this task from Doing to Done on the WMDE-FUN-Sprint-2019-10-14 board.
gabriel-wmde closed this task as Resolved.Fri, Jan 10, 3:07 PM
gabriel-wmde claimed this task.