Rewrite of the donation wizard

[wwahammy]

As the current donation wizard is written in flimflam (and the event wizard is in something earlier), everyone has found the wizard is impractical and difficult to work with. Rewriting the wizard is a difficult task but necessary. While there are many practical improvements we could have to the wizard, I think we should summarize what those requirements are here:

MUST haves:

• Embeddable at the same size as the current wizard implementation (410px x 390px)
• Support for an API from the hosting page that is as flexible as the one currently in use (custom fields, no anonymous donations, etc.)
• Support recurring and one-time donations
• Support dedications
• Support campaign donations/campaign gift donations
• Support for wizard events (such as start, choosing a particular amount, entering addresses, entered credit card, finish, etc)
• Configuration driven design, i.e. if you have only Stripe available, don't allow selection of another provider, if you have SEPA too, give the user a choice.
• Support for nonprofit level customization (preferred colors for example)

SHOULD have:

• Support for donor paying any fees (for Stripe and/or the Houdini instance provider)
• Support for Analytics callbacks for responding to wizard events
• Nicer UI elements for some fields (phone numbers, credit cards, etc)
• Support event ticketing

NICE to have:

• Flexible sizing, i.e. allowing the iframe to adjust based upon the size of the inner field.
• Animations to illustrate the process, i.e. moving between wizard steps, getting additional info for the dedication, etc.

[tttp]

Hi, Two additions to that list based on what we developed in the widget API that would be worthwhile to explain/highlight in the wizard:

• pre-select the amount (either in the wizard call itself or in the url of the container page)
• pre-fill the contact details (name. country, address) tiny, but useful:
• default recurring pre-check monthly donation, but give the option to uncheck)

and one API that could push houdini to the next level is being able to communicate better between the widget and the container ( postMessage and window.addEventListener). For instance the widget could send a message "donation completed" so the container can move to the next stage in a donor journey after a successful donation.

I'm adding these here, because the issue isn't so much about how to write a trivial api but more how to explain its benefit and usage ;)

[wwahammy]

I thought we had something like that with the donation completed event but I'll have to check.

[wwahammy]

Another thing:

• support for non-monthly recurring donations durations, including annual.

[wwahammy]

• Designations (must to have since we already have them)

[wwahammy]

• End date for recurring donations, including forced end date for donations
  • End dates that aren't specific such as "one year, one month, one week"

[wendylbolm]

Specific details for what we need in recurring donation rewrites (from user feedback)

Customizations users (Admins and Associates) should be able to set in the website based button

• Ability for donors to set send date
• User-set end date specific to a button
• Ability for donors to set frequency
• User-set frequency specific to a button
• Adding these customization options to the button builder and advanced code
• Ability for user or donor to set payment date (i.e. 15th every month) (?)

Customizations users (Admins and Associates) should be able to set in campaign wizard/pages

• Ability for users to set frequency and end dates for donations made through campaign contribution buttons
• Ability for users to set frequency and end dates for donations made through campaign gift levels