2018 English campaign fundraising on apps
Open, NormalPublic

Description

As Online Fundraising (@spatton and @schoenbaechler) discussed with @Charlotte and @JMinor on September 6, we’re taking the app fundraising conversation to Phabricator. Josh and Charlotte asked us to prioritize things we’d like to try out in this year’s English campaign. We’d like to focus on the following areas to improve app fundraising in 2018, sorted by priority:

  • App article fundraising: We think app fundraising has the most potential in this year’s campaign. Check out the Fundraising in the iOS / Android document to read why. Charlotte and Josh mentioned that there’s a chance that we might be able to have it ready for December. They have to speak to the lead engineers first. We think that app article banners could use similar copy and styles as used in app feed banners. Here’s a reference link to our current best Mobile article banner (Mobile Small).
  • Weekday variable: Using copy that includes weekday has proven to be very effective. This would require a simple variable (%weekday%) that outputs the current day of the week. We’re using it throughout our banner web portfolio, here’s an example from our Desktop small banner
  • Visible payment methods: An element that works well on the web is displaying payment methods that are accepted in the corresponding country. Accepted Credit Card providers slightly vary per country (see list below) and should ideally only be displayed when they’re available:
    • US: Visa, Mastercard, Amex, Discover, Amazon
    • CA (Canada, not California 🙃), NZ: Visa, Mastercard, Amex
    • GB, IE, AU: Visa, Mastercard, Amex, JCB
  • Device variable: In the Mobile Small banner, we’re using the following copy: „It's easy on your phone and only takes a minute.” We know that tailoring the fundraising message to corresponding reader works (weekday, country). Replacing the *phone* part with the reader’s device name (Galaxy S9, Galaxy Note, iPhone, iPad, etc.) will almost certainly be effective.
  • Visual helpers: Our experience tells us, that adding a red border, „information“ iconography, highlighting key copy lines (e.g. a red underline) or adding text hierarchy (e.g. bold title) to the banner helps in raising attention and conversion.
  • A/B testing: As WMF’s A/B testing ambassadors, we’d love to look at some p-values in this year’s campaign. This sounds nerdy and we’re aware, but it’ll give us helpful data that can be compared with Mobile web. In short: The app is an exciting environment to learn from. This could be as simple as A/B testing the 2016 app feed banner with the one from 2017 and/or the 2017 with the overhauled 2018 variant.

Let’s discuss!

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 19 2018, 12:55 PM
schoenbaechler updated the task description. (Show Details)
schoenbaechler updated the task description. (Show Details)
JMinor removed Charlotte as the assignee of this task.Oct 12 2018, 5:22 PM

We've done an initial triage of what is possible for the 2018 Big English time frame. Below some comments/triage. Please note that overall we are happy to push forward fundraising in the apps and work to improve it, but have to balance that with already planned work.

  • App article fundraising: This is something we are interested in, and can probably make work in a hacky way, even with limited support from CentralNotice, however given the time frame and risk, we suggest we look into supporting this for a smaller campaign in another geography in Q3 or Q4. This will give us more time to figure it out, and make its first test a less vital/risky context.
  • Weekday variable: This is a possibility and we're looking into the details.
  • Visible payment methods: This can likely be done using existing feed banner mechanism, since these are essentially images. We will need to double check that this kind of logo based solicitation won't run afoul of Play Store or App Store rules, but technically seems doable.
  • Device variable: This is similar to Weekday Variable, its something we can maybe support, but needs confirmation/estimation.
  • Visual helpers: Much of this may be possible in the existing banners. @cmadeo can work with your team to determine what is do-able/needed here, but basic HTML formatting should be possible.
  • A/B testing: I think this is going to have to wait for another year. We can sequence test, but parallel population a/b testing is not in place for 2018.
JMinor triaged this task as Normal priority.Oct 12 2018, 5:22 PM

Thanks @JMinor for the update, sounds good so far. I’ll sync with Fundraising and explore some directions with @cmadeo in the meantime. Will post updates here.

@spatton and I were talking about app fundraising this morning. Let’s say we’d use more or less the same designs as in 2017 and enhance it with the following features:

  • Weekday variable
  • Device variable
  • Visible payment methods
  • Visual helpers (“info icon”, red border for card, highlighting key sentence)

In which timeframe could we get there / what is your estimate to implement it @JMinor & @Charlotte ? Thanks!

Charlotte added a subscriber: Dbrant.EditedOct 31 2018, 11:02 AM

@schoenbaechler The border round the card is harder than it seems on iOS afaik - @cmadeo can confirm. If the "visible payment methods" are just images then this is fine. What we will need are the finalised designs for the feed card (base them on what we've done before, which I think Carolyn and @RHo have shown you) and then we can estimate at our next grooming. @Dbrant - can you take a look at Robin's initial thoughts (in the ticket description) and flag up anything that he should know to avoid in the design?

On the Android side, we have the following technical constraints at the moment:

  • Similar to what Josh mentioned, we currently don't have a way of displaying banners inline with articles. We currently can only show cards in the Explore feed.
  • The card that appears in the Explore feed must adhere to the layout seen below (the text can be arbitrary, with limited HTML, and an optional image across the top of the card (not seen in this screenshot)). If we need to make changes to the layout, we'll need to act quickly to release an update to the app so that a sufficient proportion of users receive it before fundraising begins.

schoenbaechler added a comment.EditedNov 3 2018, 12:29 AM

TLDR; here are some design explorations for Android, listed by visual level of urgency for the fundraising appeal:


Thanks for the infos @Charlotte and @Dbrant. I’ve been working on some visuals today. They’re all primarily designed for conversion. I explored three levels of urgency for the app fundraising appeal.

Based on our experience in Mobile web fundraising, it can be assumed that android-app-fundraising-03-border.png is going to convert best. It features a red border that has proven to be effective.

android-app-fundraising-01-border.png is the least urgent version, it doesn’t feature an info icon or underlined text in red.

android-app-fundraising-02-border.png is a hybrid and could be the way to go if an inside border of the card is not feasible.

Again, if we’re aiming to create the best converting banner possible, I suggest to go with android-app-fundraising-03-border.png. The question is: is that level of urgency needed or not? Let’s start the conversation @spatton, @JMinor & @Charlotte.

In regards to copy: The parts that I used to create the mockups mostly derive from the Desktop Large banner, which is IMO suitable in terms of length for the app appeal. @TSkaff, @jrobell, @Pcoombe & @spatton: I added this discussion point to our weekly agenda for next week. And what are your thoughts about using the accurate average variable? For the sake of completion, here’s the copy I used (variables highlighted bold):

To all our readers in the U.S.,

It's a little awkward, so we'll get straight to the point: This Friday we humbly ask you to protect Wikipedia's independence. We depend on donations averaging about $16.36, but 99% of our readers don't give. If everyone reading this gave $3, we could keep Wikipedia thriving for years to come. The price of your Friday coffee is all we need.

Wikipedia is a place to learn, not a place for advertising. It unites all of us who love knowledge: contributors, readers and the donors who keep us thriving. Please take a minute to help us keep Wikipedia growing. Thank you.

Visually displaying payment methods has also been proven to be effective in Mobile web fundraising tests. To simplify the process, the list of methods in the mockup can be exported as a single *.png image and scale based on the user’s device. Probably best with a max-width to not take up too much vertical height on bigger screens. As mentioned in the card’s description, supported payment methods slightly vary per country:

  • US: Visa, Mastercard, Amex, Discover, Amazon
  • CA, NZ: Visa, Mastercard, Amex
  • GB, IE, AU: Visa, Mastercard, Amex, JCB

I can take care in preparing the different payment method images.

In terms of design in general, do you see notice any substantial issues on Android in these mockups @Dbrant?

@cmadeo: It would also be great to your feedback on the Android designs. And would a similar conceptual approach work on iOS as too or do you see any issues with it?

Thanks in advance. Have a wonderful weekend everyone!

@Dbrant When you say a limited amount of HTML, does that mean that we're able to insert stuff like the correct day of the week?

Dbrant added a comment.Nov 7 2018, 6:26 PM

@Charlotte Nope, the HTML is limited to things like bold or italic text, and not much else. The day of the week is not related to HTML presentation anyway -- the only way to do this would be to have different announcements scheduled for each day, with the correct day stated in the announcement verbiage.

@schoenbaechler To clarify a bit further, the screenshot I posted above is quite literally the layout to which we're currently restricted. It's not currently possible to have a red border around the card, or the payment method images at the bottom (we can only have an image at the top of the card), or the "lock" icon in the Donate Now button.

bearND added a subscriber: bearND.EditedNov 7 2018, 6:39 PM

Getting the day of the week from the announcement text is problematic since we don't know what time zone the client is in, e.g. Australia vs UK. I think the day of the week should come from the client based on the local time zone.

On second thought we could do it theoretically based on the country (and approximating the time zone to 1 per county so we might be off by a few hours but close enough). Still this would bloat the announcement JSON we would send to the clients quite a bit.

Dbrant added a comment.Nov 7 2018, 6:49 PM

Agreed, and this can potentially be done by introducing special keywords in the announcement text like $dayofweek, but this would necessitate an update to the app client logic, and bumping the version of the announcements (i.e. AndroidV3) since existing app versions won't know how to handle the keywords.
As a side note, does anyone know if this kind of thing is done in CentralNotice? And if so, how?

Time frame

I suggest to run the campaign for the same amount of time as last year and start/end it on the same weekdays. This makes it possible to compare the outcome of the campaign with 2017 as good as possible.

Here is 2017’s time frame:
Start Date: 11/30/2017 16:00:00 UTC
End Date: 12/20/2017 23:59:00 UTC

Here’s my suggestion for 2018:
Start Date: 11/29/2018 16:00:00 UTC
End Date: 12/19/2018 23:59:00 UTC

How does that sound @TSkaff @spatton @Pcoombe @jrobell?

Thanks for the all the infos @Dbrant and @bearND. Some answers and questions below:

As a side note, does anyone know if this kind of thing is done in CentralNotice? And if so, how?

The output of $dayoftheweek in web banners is handled via client side JS, not CentralNotice.

“(...) but this would necessitate an update to the app client logic (...)“

Just making sure I understand correctly, are you saying that $dayoftheweek isn’t feasible for a possible campaign start on November 28, 2018? (details on time frame suggestion below)

@Charlotte mentioned, that it might be possible to make parts of the copy bold and add an underline (e.g. border-bottom: 3px #B32424 solid;) to it. Is that doable @Dbrant?

It's not currently possible to have (...) the payment method images at the bottom (we can only have an image at the top of the card)

Thanks for this clarification. I’ll explore alternative designs today with the payment methods above the copy. It’s probably not going to work though since the logos usually need to be positioned in proximity to a call to action (“Donate now”).

Dbrant added a comment.Nov 8 2018, 2:44 PM

$dayoftheweek isn’t feasible for a possible campaign start on November 28, 2018

That is correct.

make parts of the copy bold and add an underline

Parts of the text can be bold, underlined, or different colors. However, the underline must be the same color as the text.

I created new mocks, based on your feedback @Dbrant & @Charlotte. Here’s our suggestion for the app fundraising campaign in 2018:

Timing:
Start Date: 11/29/2018 16:00:00 UTC
End Date: 12/19/2018 23:59:00 UTC

Design & Variables:

Country:USGBIEAUNZCA
Design:
Variables:Header image, in the U.S., $16.36, $3Header image, in the UK, £10, £2Header image, in Ireland, €10, €2Header image, in Australia, $15, $3Header image, in New Zealand, $15, $3Header image, in Canada, $15, $3

We might tweak one or the other word in the copy but wouldn’t add any additional variables. Please let us know if you see any problems with this layout or if you need any other infos from our end.

Although we’re quite limited on Android, it shouldn’t hinder us on going “all in” on iOS! This is a great opportunity to enter a new world of fundraising in one of our apps. @cmadeo & @JMinor: Do you see any potential issues with a design like this on iOS:

As mentioned beforehand, it features winning elements from Mobile web, such as: info icon, weekday & accurate average variable, red key sentence underline, payment method image and a lock icon inside the “Donate now” button. We’re confident that this is a high performing version of the feed banner.

The timing of the campaign is the same as on Android:
Start Date: 11/29/2018 16:00:00 UTC
End Date: 12/19/2018 23:59:00 UTC

@JMinor: Please let me know about the current project status. Thanks.


CC: @jrobell @TSkaff @spatton @Pcoombe

Here’s a wireframe for the iOS version as a discussion starter @cmadeo & @JMinor:

Here's a first pass of what's possible on iOS with our current server-side announcement format and an update to the iOS app (6.1.1):

Older iOS app versions would be shown the same card without any bolding, underlining, or red border.

The Android app will render bolding & underlining:

@schoenbaechler, two things that came up in our iOS meeting today:

  • Currently the feed cards are associated with a specific date (eg. if we push the card on Monday, December 1, it will fall under the 'Monday, December 1' header and will be pushed down the feed each day after the first of December). We won't be able to change this behavior for this release, so would it be okay to not include the Weekday variable?
  • Supporting the credit card images at the bottom would be tricky, as the image scales proportionally with the device and we currently only support banner images at the top of the card. That being said if you wanted to create some sort of background pattern of payment types, we could show it as a top full bleed image to the card. Just noting that the height for this card image is 150pts. Happy to help you with creating this image if you need!

Thanks @JoeWalsh for the update, the screens look great. And there it is, the unicode info i! ;) We might try that one in banners too.

Since it’s not possible to have the info icon in bold, I think it’d make more sense to have the greeting in just font-weight: normal;. What do you think about that @cmadeo?


Also @cmadeo (& thanks for working on this on the iOS side)

Currently the feed cards are associated with a specific date (eg. if we push the card on Monday, December 1, it will fall under the 'Monday, December 1' header and will be pushed down the feed each day after the first of December). We won't be able to change this behavior for this release, so would it be okay to not include the Weekday variable?

Yeah, I can see that it could be confusing to have different weekdays in the copy and header. I’m ok with not including it for now.

That being said if you wanted to create some sort of background pattern of payment types, we could show it as a top full bleed image to the card. Just noting that the height for this card image is 150pts. Happy to help you with creating this image if you need!

Hmm, Sam and I already heavily discussed the proposal below on Android, in which payment methods are positioned at the top of the card. The appeal has more of a transactional feel, when beginning with payment methods:

A 150pts background image will probably strengthen this effect. Just that I understand correctly @cmadeo; it’s not possible to limit the height of the image, right? (as in the Android mockup above) I remember that Dmitry mentioned, that it might be possible on Android. If it’s not feasible, then I suggest to not include an image at all on iOS.

RHo added a comment.Nov 14 2018, 1:10 PM

@schoenbaechler - yes on the Android version the image definitely can fit height.

@schoenbaechler, I'm not sure, @JoeWalsh would know best about the image height

@schoenbaechler we can implement the image height restriction on iOS to match Android behavior @RHo on android does it scale to fit or scale to fill?

RHo added a comment.Nov 14 2018, 3:05 PM

@schoenbaechler we can implement the image height restriction on iOS to match Android behavior @RHo on android does it scale to fit or scale to fill?

hi @JoeWalsh - the image is centered in the card and scales to fit height. T191640 links to an example image on commons.

Ok, matched the scaling on iOS to android:

image_height: 50


image_height: 150


@JoeWalsh, can we try it with the image below? It’s the US version of available payment methods in an @2x resolution. The actual height is 80px. Based on the specs from Rita it should be centered when the viewport is wider than 520px (the size of the image).

The original design suggestion also features a padded border below the payment methods. I’m assuming that this won’t be possible since the image stretches to full width, right? Maybe a separation between logos and copy can be achieved by adding a centered asterism to the image. I’ll explore in case we can’t do border-bottom.

Thanks all!

Looks good on Android for the two devices I tried:

Not so good on iOS:

On iOS, the image view is scaleAspectFill which means the whole image will be scaled proportionally to fill the entire image view, centering & cropping the larger dimension. I'm not sure now that's exactly matching what Android is doing, but we also have narrower cards for some devices and orientations that wouldn't be able to fit all of the payment types. Something like https://upload.wikimedia.org/wikipedia/commons/1/1f/Multilingual_announcement_graphic.png works because there's a large crop-able width and a narrow area of interest in the middle.

Thanks @JoeWalsh! Agree, the one on Android seems fine (or a good starting point).

I'm not sure now that's exactly matching what Android is doing

Yeah, it seems like on iOS it behaves differently. It should be more of an inline image with a max-height. It currently reminds me of background-image in CSS. Do you think it’s possible to adjust iOS to match Android or is that too much of an intervention? If it’s not possible, it might make sense to just try payment logos on Android.

Matching iOS to Android image scaling is going to be too much of an intervention at this point. I'd agree it make sense to just try payment logos on Android for this year.

Ok, let’s try it on Android, @JoeWalsh! One more question before I produce the images for other countries (GB, IE, AU and NZ, CA):
Can we do a border-bottom on the image as in the design suggestion below? (full width border-bottom would be ok too if not feasible with padding on the left and right).

Change 473248 had a related patch set uploaded (by Mholloway; owner: Joewalsh):
[mediawiki/services/mobileapps@master] WIP: 2018 app fundraising announcements

https://gerrit.wikimedia.org/r/473248

There are some issues with the image being large and cropped:


The above is on an old Nexus 5 in portrait mode. In landscape it's marginally better but still too big and a little bit cropped.

bearND added a comment.EditedMon, Nov 19, 11:17 PM

Yes, my bad. Had tested PS6 instead of PS8. Now it looks much better:

(As an aside, the Continue Reading is a bit annoying here.)

Now checking the URLs, I think we should consider using the mobile (.m) version of the donation policy link.

@bearND I'd be inclined to agree, except that the mobile site handles the initial language selection menu very poorly, and requires scrolling down (on almost any device, I'd think) to get to the policy text...


bearND added a comment.EditedMon, Nov 19, 11:52 PM

@Mholloway Ok, that makes sense. It's a bit annoying to have to open the section with the actual text, too. So, it's not a clear cut improvement over the desktop URL. I'm fine leaving it as is then.

Change 473248 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] 2018 app fundraising announcements

https://gerrit.wikimedia.org/r/473248

Mentioned in SAL (#wikimedia-operations) [2018-11-20T18:04:35Z] <mholloway-shell@deploy1001> Started deploy [mobileapps/deploy@7553087]: Deploy 2018 app fundraising announcement config (T204821)

Mentioned in SAL (#wikimedia-operations) [2018-11-20T18:08:12Z] <mholloway-shell@deploy1001> Finished deploy [mobileapps/deploy@7553087]: Deploy 2018 app fundraising announcement config (T204821) (duration: 03m 37s)

App devs/QA, please test the announcements. You'll have to ignore the date and may have to override the country. (There are dev settings for the Android app to do so. I don't know if the iOS app has a similar setting.)