Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine an appropriate [donation_history] "thank you" text by the transaction status. #509

Closed
pryley opened this issue Mar 9, 2016 · 9 comments
Assignees
Milestone

Comments

@pryley
Copy link
Contributor

pryley commented Mar 9, 2016

The [donation_history] shortcode always shows "Thank you for your donation!" regardless of whether the donation status is failed/cancelled/abandoned/etc.

I suggest you change this text depending on the transaction status.

image

@DevinWalker DevinWalker added this to the 1.3.7 milestone Mar 9, 2016
@pryley
Copy link
Contributor Author

pryley commented Mar 10, 2016

I wonder also if the default title is the best to use (Donation Confirmation). Perhaps using something like Donation Status instead with the variable text saying something about confirmation of a successful transaction on success, etc.

Worth discussing.

@DevinWalker
Copy link
Member

I think it's fine being named Donation Confirmation but I think the sub-headline could be conditional based on the status. That seems to make the most sense.

@DevinWalker
Copy link
Member

I just had a chance to review this and my findings:

  1. The "Thank you for your donation" is included by default when the page is created on install: https://github.com/WordImpress/Give/blob/master/includes/install.php#L53 - My thought is that the donor can easily delete this or adjust the text to suit their needs.
  2. If the donation has failed the donor is taken to the transaction failed page

@pryley
Copy link
Contributor Author

pryley commented Mar 23, 2016

Although the donor is sent to the transaction failed page on failure, the donation still appears in the Donation History page and can be viewed.

There are also other statuses to think about, for example if a donation has been refunded, does it make sense to thank them for their donation when they view the donation page from their donation history?

I think that a different message per/status (or at least the ability to add_filter the message with the passed status) would be beneficial.

image

image

image

@DevinWalker DevinWalker reopened this Mar 23, 2016
@DevinWalker DevinWalker modified the milestones: 1.3.7, 1.4 Mar 25, 2016
@DevinWalker DevinWalker modified the milestones: 1.5, 1.4 Mar 29, 2016
DevinWalker pushed a commit that referenced this issue Apr 18, 2016
Improved upon Transaction failed message on install

#509
@DevinWalker DevinWalker modified the milestones: 1.5, 1.6 May 10, 2016
@DevinWalker DevinWalker modified the milestones: 1.6, 1.7 Jul 26, 2016
@DevinWalker DevinWalker modified the milestones: 1.7, 1.6 Jul 26, 2016
@mathetos
Copy link
Member

Here's my suggestions for this:

FAILED

donation-confirmation-failed

PENDING

donation-confirmation-pending

Do we need additional messages for the following? Would they even show up on the Donation Confirmation page at all?

  • Refunded
  • Cancelled
  • Abandoned
  • Pre-Approved (I guess this would show for sure, particularly with Stripe)
  • Revoked

@kevinwhoffman
Copy link
Contributor

I like giving the status more attention by pulling it out of the table.

Also thinking Donation Details makes more sense for this page title, since the donor can click into it from the Details column of the Donation History page. "Confirmation" implies success, but not all of the statuses are positive.

Do we need additional messages for the following? Would they even show up on the Donation Confirmation page at all?

We should account for the possibility of a donor seeing any of the donation statuses. An admin could change the status in the transaction details screen, and the donor would see that status reflected in the Donation History page.

@mathetos I'm not quite clear on the meanings of every status just yet. Would you prefer to write the copy and I can hook it all up?

@DevinWalker
Copy link
Member

DevinWalker commented Oct 19, 2016

Feedback on Direction

I also like giving the donation status more attention by bringing it outside the table but I feel there should still be an option to output in the table if the admin wants, just not set by default.

What I dislike about the current functionality of the "Donation History" shortcode is how the "View Receipt" link redirects to the "Donation Confirmation" page. Rather, the functionality should be that the page reloads and the donor is shown the [give_receipt] shortcode content with the ability to return to the previously shown [donation_history] shortcode content.

The donor remains on the same page which is a better experience and it allows more freedom for themes to customize the donation confirmation page. For instance, on GiveWP.com we are using EDD and have customized our confirmation page. When customers click to view their receipt via our Account dashboard: https://givewp.com/purchase-history/ the entire page changes. This bugs me. If it were using the above functionality, the user would remain on the same account layout.

Thinking through development of it, we would check via $_GET['payment_key'] whether or not the donor is choosing to view a receipt in the [donation_history] shortcode and output the [give_receipt] content.

  • This approach doesn't require the name of the "Donation Confirmation" page to change
  • The donor only will see the "Donation Confirmation" once now, after they have given. Providing more customization options for themes and better UX overall.
  • The email receipt link will also have to update to be the donation history page now instead of confirmation. Other links may need updating. Backwards compatibility needs to be a priority as always :).

User Experience

  1. Output the various status messages above the receipt table using Give's give_output_error with the appropriate notice according to the status:
  • We should provide additional attributes for the give_receipt shortcode to override the default messages passed per status since people are going to want to customize them. Also, provide a filter which passes the $form_id so we can use code to customize the messages per status.

Failed Example
2016-10-19_11-55-01

Success Example
2016-10-19_11-56-51

Link added to return to Donation History

2016-10-19_11-58-48

@kevinwhoffman
Copy link
Contributor

kevinwhoffman commented Oct 20, 2016

@DevinWalker I'm implementing what you described, but I came across a new issue. By moving the receipt view to Donation History, the user has no way to customize the shortcode from WP admin. That's because I'm calling give_receipt_shortcode() programmatically based on the presence of payment_key in the query string, which means that [give_receipt] is not in the post editor of the Donation History page. Only [donation_history] is present in the post editor.

A related point of confusion is that the [give_receipt] shortcode will be present in the Donation Confirmation page. If a user customizes the messaging within that shortcode, they will expect it to apply any time the receipt is viewed. In reality that would only be customizing the messages for receipts on the Donation Confirmation page, but not for the Donation History page.

For these reasons, customizing these notices might make more sense through plugin settings, rather than shortcode attributes. What do you think?

@kevinwhoffman
Copy link
Contributor

Following Slack call with @DevinWalker and @mathetos , here's expected behavior:

  • Receipts are viewable from Donation History page with link back to view all donations.
  • By default, payment status is displayed above the receipt as a notice, and the status row is hidden.
    • Shortcode attributes will be available to toggle this behavior.
  • Notice message will be filterable with the following variables provided to hooked function:
    • $form_id
    • $post_id
    • $status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants