Please start with these mockups. We will need to switch them out and offer multiple variants.
https://design.bytrilogy.com/repermissioning-landing1/coded-version
Please start with these mockups. We will need to switch them out and offer multiple variants.
https://design.bytrilogy.com/repermissioning-landing1/coded-version
Thanks @Ejegg, I'll pass that positive feedback along to Eric and Randy :)
Got a couple new versions that have gotten valuable feedback from Caitlin and Peter, so I'm ready to call them legit semifinal:
An important note about #2 (lightbox gallery) : it uses a plugin to achieve the lightbox effect. As far as licensing, I'll quote @Pcoombe :
The lightbox plugin appears to be available under the GPL (https://github.com/sachinchoolur/lightGallery/blob/master/LICENSE.md) which should be okay, although fr-tech might have security concerns about bringing in 3rd-party code.
If you do have concerns, we'd be ok going w/ the hover effect, no click variant.
Elliott and company, could you tell us what you think re: the lightbox plugin, and we can pick one to use as our base for implementation?
@spatton - the lightbox plugin should be fine.
With all those captions, are you planning to pay to have them translated, or wait till the translations come in from translatewiki.net before sending out mailings in different languages?
Re translations, yes, we will be getting them, starting with Italian but moving on to Swedish and likely Dutch in April and May. I don't know what the merits are of using translate wiki vs doing them as one-offs. Can you help us decide what would be the best an ongoing workflow?
Ooh, there are translated captions and descriptions under a bunch of the pictures on commons - looks like some of the payoff from the structured data project! I'll play around with some queries to pull those into the translation files. If I can get that working, it would be great to do the translations right on commons with the pictures.
Change 498287 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] WIP: fancy variant for opt-in page
Change 501406 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/vagrant@master] Queue settings for FundraisingEmailUnsubscribe
Change 501406 merged by jenkins-bot:
[mediawiki/vagrant@master] Queue settings for FundraisingEmailUnsubscribe
Change 498287 merged by jenkins-bot:
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Fancy variant for opt-in page
OK, this is deployed. An example of the new form:
We just need to decide where to put the variant name when it comes in on the backend. A new column in the communications table? Or a whole new table for opt_in metadata, which would have this plus attempted amount?
Awesome @Ejegg! So motivating to have a live link.
Thanks so much, @Ejegg, this looks great! My notes are below--each of Sam's items are included so you don't have to hop back and forth:
Thank you again! I'm really excited to get a first test out.
Just a couple initial answers:
I'm pasting two of your items back in here to reply in-line:
This could be a sticking point. I think, even if we pre-populate the email field, a user is likely to change the pre-populated value and replace it with a new email address. I'd expect this to happen for at least 20% of users, though that's just a guess.
Would sending the contactID in the URL make any difference?
Yes, that would be awesome! Though I always forget how do_not_solicit is used and if that's a field MGF uses for some custom preference.
Per T220647 my yubikey access is pending so I haven't been able to check again if the data is appearing differently in the back-end. Either way, I see the below as outstanding items or questions. Would it be good to get on a call to talk through these last details?
My view is it should live on payments wiki as well, as part of the extension, so that there's a single place for translations and we're not bouncing users around domains needlessly. If that's not possible though, then we can make something on donatewiki.
Change 504213 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/crm@master] Opting in reverses opt-out fields
The patch in Monday's gerritbot comment should address point 3.
Contact ID on the URL would definitely be useful to link a record with any new email address the donor adds. We'd want to include the contact_hash as well to make it harder for random ppl to change any contact's email address.
I agree with @Pcoombe that the thank you page should be part of the same extension and live on payments wiki as well.
Great re: point 3! Thanks for plugging away. I have sql access again but am
having trouble figuring out how to read the civicrm_value_1_communication_4
table to actually check if the opt-ins are happening. Which of the ID
fields can I tie back to a contact record? I tried querying where id or
entity_id = 16134285 (my contactID I'm testing on) and I get an empty set
back.
The remaining outstanding questions are below. #2 is a high priority for
us, otherwise the page doesn't meet legal requirements.
@Ejegg lots of little details here! Are you free to talk this afternoon or
tomorrow so we can get through these questions?
Talked with Elliott today, he said item #2 above is what is hanging this up. My over-simplified summary: the page was designed to require an email address so he needs to rewrite some of the code to make it work without one.
For TY page: it will be a template on payments wiki, like the main opt-in page. fr-creative can start working on design for this cc @spatton
Also from today, we know that the remind me later email addresses are getting into civi without any more info. @Eileenmcnaughton do you know how that's happening? I'm going to look for CIDs that are good examples of this and reply later.
In case it's useful, here are details about how remind-me-later gets into civi. From the banner, a background POST is made to a URL like this:
https://www.pages04.net/wikimedia/remind/Form?sp_source=B1718_123100_en6C_dsk_p1_lg_dsn_decal4
This is a silverpop endpoint. The value of sp_source is the name of the banner.
Example of form data POSTed to that URL:
param | value |
formSourceName | StandardForm |
sp_exp | yes |
rml_source | B1718_123100_en6C_dsk_p1_lg_dsn_decal4 |
rml_group | dsk_lg |
rml_country | US |
rml_language | en |
rml_submitDate | 04/18/2019 |
rml_segment | 56 |
test@example.com | |
Hope this helps!
Thanks for those details, @AndyRussG and @DStrine.
@Ejegg, we've talked about TY page options and our preference would be an inline confirmation in the same container holding the email submission field. Here's a simple example:
Initial form appearance:
Thank you confirmation after successful email submission:
We'll provide the content for the TY block; can you let us know if you foresee any problems w/ this approach?
Sure, that should be fine.
The way we're building the form now, we would post back the whole thing and re-render even though that's the only changed bit. We can do that for starters then work on then work on de-duplicating the rest of the template.
Thanks @Ejegg, I've asked Trilogy to provide a coded version of the page w/ the Thank You block swapped in for the form element.
Hey @Ejegg, how is the work going on your end?
Here's a post-submission TY variant Trilogy created - simple but sufficient.
Change 508477 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Add fancy version of Thank You page for opt-in
Change 508477 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Add fancy version of Thank You page for opt-in
Change 504213 merged by Ejegg:
[wikimedia/fundraising/crm@master] Opting in reverses opt-out fields
@CCogdill_WMF In the case that we get an opt-in that comes in with the contact ID, but the user gives a different email than what we have in civi, should we replace the old email with the one the user entered, or just add the new email alongside the old one?
I can do either way. I'm just not sure what the intended behavior is.
I think we should go with whatever behavior the dedupe process uses--I think it makes the old email secondary and the new one primary? But I'm not sure.
Thanks @Ejegg! Still one optimization that should happen: it's currently possible to submit the form without a valid email address, or with no data in the email input field at all. That causes a redirect to an error page that doesn't include any link to return to the repermissioning page.
Could we add validation to the email field, so that no one gets that redirect?
Good catch, Sam! +1 to adding validation.
I tested with an active contact record (my own) and can confirm my opt-in
preferences were updates to "YES"! Woo!
Change 511604 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Basic email validation for opt-in
Change 511748 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Add retry link on opt-in error
Change 511604 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Basic email validation for opt-in
Change 511748 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Add retry link on opt-in error
OK @CCogdill_WMF and @spatton , those changes are deployed. There's now some basic client-side validation on submit, and the error page has a retry link. If you want to test the error page, use an almost-valid email address like "test@domain.1". That will get past the front-end validation but the back-end's stricter checking will cause an error. Note that the error page is still not styled for the variant.
Awesome @Ejegg!! Thank you!
I *think* we're ready to test this. @MBeat33 can you do a round of QA and
make sure this looks OK from a DS perspective?
Here's the link! https://payments.wikimedia.org/index.php?title=Special:EmailPreferences/optin&variant=wle_001
This looks great, everyone! I like the red frame around the field for incomplete entries, and the wee jig the Yes button does on mouse over.
@CCogdill_WMF the 'by' attributions for photos 1, 3-5, 8, 10-15 are blank, so we might see questions about that. I might also swap the word created for taken in the blue text box, but apart from those quibbles this looks very cool.
Please give me a heads up before testing and we can watch the Zendesk queue for any questions.
Good catch on the captions, @MBeat33 ! That's a bit mysterious, since the credits for all the pictures are in the source code. It looks like the Cyrillic ones are the ones that get dumped somewhere in the process of rendering the template. Trying to figure it out.
Change 511800 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Mustache flag to use spaces in helper args
Change 511800 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Mustache flag to use spaces in helper args
@MBeat33, @CCogdill_WMF Turns out the problem was names with spaces, not cyrillic characters. I found the template setting that was blocking those and have just pushed a change to production that fixes it. Looking good now as far as I can tell.