Organisations need the contribution interface to flow. CiviCRM contribution forms are very featureful, but customising them for a specific flow can be more complex than it might be to build the interface from scratch.
CiviCRM users want to make the contribute interface efficient, or to gather information in ways that suit their organisation. A recent request got me thinking about how much of the CiviCRM form interface could be removed from a contribution form.
Let's think about the experience of contributing through CiviCRM at the moment. Here are some forms we might like to use -
A reduced form, collecting the bare minimum details for transaction and contact creation. Requires post-processing of the contact name for CiviCRM data model.
A minimal form which uses staged disclosure to get people through the process as smoothly as possible, presenting a few questions at a time to avoid overwhelming.
An organisation might want a mobile app which permits donations via a reduced form interface, either for an on-the-go collector or for contributors themselves. An API interface would permit apps to interact with contributions and make transactions directly to CiviCRM. This needn't be a mobile app ...
Organisations may wish to collect data from partially completed forms, eg by capturing data entered in steps 1-2 of a multipart form which the user ultimately doesn't complete.
A single form which rolls contribution and contact data together won't permit this as easily, but an API backend could permits us to capture contact details after page one can and retain that contact data whether or not the donation on page two is completed.
CiviCRM does pretty well handling this simple format.
- In the contribution page settings, disable the confirmation page to remove the second "confirm" form.
- Relabel Billing Name => Name.
- Remove several fields - Middle Name, Street Address, City, Country, County, Postcode, Card Type.
- Rearrange fields in template.
The form on http://contribute.barackobama.com uses JS validation (without serverside feedback) to validate steps of the form during completion. If the submission fails, then we see the whole form alongside the error message.
For this form, we need to -
- Disable the confirmation page.
- Relabel, rearrange and remove fields in template and javascript.
- More javascript for nice flow between steps.
Here are some other examples which you might want to consider - how would you use CiviCRM forms (or similar tools, eg WebForm CiviCRM integration) to achieve these?
- University of South Carolina's "Give Now" program? This form puts commitment details up front, then asks for contact and payment details on the second page.
- Anonymous donation forms - how do you handle a "tip jar" without requesting contact details?
- A cart-based donation method like DonorsChoose?
- Any complex series of web forms which incorporates a contribution or transaction amongst other processes.
- Connecting transactions through an external system (Drupal Commerce or Ubercart, Joomla or WP shop plugins, or something entirely separate) as CiviCRM contributions.
The CiviCRM site profiles these two forms on the page about Contributions -
- Leukemia and Lymphoma Research's donate pages
- United Methodist Church's "Imagine No Malaria" campaign
- Alternatives Canada
- Art for Impact (Unsure if this is meant to be found?)
- channelAustin
- Greater Washington Urban League
Bar the first, the above examples from the CiviCRM site use a very stock-looking CiviCRM donation form. Leukemia & Lymphona Research's form stands out for being heavily themed from the default look, but it's still very much a CiviCRM contribute form. I'd love to see some great examples of compelling contribution interfaces in this portfolio!
I think so - I think that while you can enhance the default CiviCRM forms into different shapes through templating and JS, being able to work with a flexible form layer is much nicer for building interfaces which don't match the default behaviours of CiviCRM.
Webform provides great facilities in this regard, and for contact creation or even free event registration it works just fine. But there's room for improvement -
- Can't run transactions from Webform?
- CiviCRM expects all contributions to be connected to a specific contribution form?
- Email receipts etc?
- Other questions?
Using custom built forms talking to the CiviCRM API will run into most of the above issues too. CiviCRM Webform does the best it can with what CiviCRM exposes to the API, and most of the work here needs to happen in CiviCRM (and in the API layer).
- Expose transaction processing to CiviCRM.
- Support for Price Sets and online contributions / events - talk to colemanw about this
- Paying for Events and Memberships with Ubercart
- We don't want to expose an API method to bulk-test stolen credit cards. Exposing a Contribute API interface may require consideration of attackers firing lots of small donations at the organisation site to test stolen cards. This isn't unique to an API though; any contribute form can be abused in this way.
- Why do we say the word "Billing" on the default form not once but four times? Might an impulse donor be dissuaded by the thought of receiving a bill in future?
- The default form order - email, card, name & address - feels odd to me; I'd expect to group personal details and payment details together.
http://www.themonthly.com.au/subscribe is another good example, talk about pattern of tabs or buttons which link to another contribute page entirely. this feels bad, but is it really?