I'm starting to play with uc_addresses... so far, it looks like it does what I need -- thanks!

One minor UI/UX improvement would be to use drupal_set_destination() when we link from the cart checkout page for users to edit their stored addresses. That way, after they update their address, they're automatically redirected back to the checkout page again...

Patch coming soon, stay tuned.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dww’s picture

Status: Active » Needs review
FileSize
3.65 KB

Due to how uc_addresses works, this wasn't quite as easy as I hoped, but this works... ;)

freixas’s picture

I've been catching up on bug reports today and I took a second look at this patch.

When the user clicks on the address book icon on checkout, all they are saying is that they want to look at their address book. They may want to edit an address. They may want to add an address. They may just want to look at their address book. After they look at their address book, they may want to do something else before returning to checkout—assuming that they ever return to checkout. They may also do what I do, which is to use the middle mouse button to bring up the address book in a separate tab.

The address book icon is simply a short cut to the address book. It is not an "edit this address" button. It is not an "add an address" button.

It does not feel right to assume that the user will edit an address and then want to return to the checkout form.

The "return to checkout after editing" feature should only be applied if the user is selecting a button or link whose function is to edit an address.

It isn't clear that this is the best way to handle editing an address. A new address is easily added by just typing it into the checkout form. Perhaps if a user edits a named address, the system should assume (or ask) that this is an edit to the existing named address rather than a new address? So the patch may not be the best way to improve the user experience—it may be better to allow the edit without ever moving off the checkout form.

Having reviewed this in more detail, I don't feel this patch is the best way to improve the user experience. I'm open to discussion, though.

dww’s picture

IMHO, the *entire* point of a UC site is to get people to give you money and buy stuff. Anything that distracts from that is a step backwards. If they're already in the process of checking out and they decide to edit an address, by default they should return to the checkout process, not just be left looking at their user profile page. I believe it's important to think like a customer on the site, not like the developer of this module... While what you say is technically true to us developers, it doesn't make sense from an end-user's perspective. If they're checking out, and they click on something to manipulate their saved addresses, they should return to checking out when they're done.

stephthegeek’s picture

This would be a very useful feature. As someone who has extensively researched and put into practice UX principles for e-commerce sites, dww's right on the money (literally) with wanting to streamline the checkout process as much as possible. Since this patch only redirects them back to the checkout if they were already there to start with, I think it's extremely unlikely that they'd want to go somewhere else after editing addresses.

"When the user clicks on the address book icon on checkout, all they are saying is that they want to look at their address book." <-- I would have to disagree with that. If they're in the checkout process and fiddling with their addresses (adding, editing, checking what's there already, etc) then they are trying to buy something and simply dealing with the address part of that process. And for the small percentage of people who are not, it's not like we're dumping them off in a ditch somewhere :)

freixas’s picture

I absolutely agree with your main point—that we want to put as few barriers to users checking out as possible.

Some background: this module was created to add user addresses to Ubercart without making a lot of functional changes to the way Ubercart worked (because I was still learning a lot about Ubercart and Drupal). The Ubercart developers chose to include the address book icon in their core code and it pointed to a collection of addresses they obtained from prior orders by the same customer. All I did was change where the icon took you. This was not deeply thought out—I had to do something about the icon and I had no clue as to the implications of just removing it.

Looking at the checkout form now, the address book icon seems like a big UX wart.

  • The address book icon is not labeled, not even with a title tag. The user has to guess what it means.
  • If they click on it, it takes them to their profile's Addresses page. They have to figure out why a button exists to take them to this page and what they ought to do once they got there.
  • We don't know what they will decide this function is for. They might decide it's a add-and-edit-multiple addresses function. If so, then your functionality will confuse them: if they add an address, they go back to the addresses list, but if they edit an address, they go back to the checkout form.

I am all in favor of improving the UX. I am not defending the current approach.

If they're already in the process of checking out and they decide to edit an address, by default they should return to the checkout process, not just be left looking at their user profile page.

If they are in the process of checking out and decide to edit an address, I actually don't see anything on the checkout form that helps them perform this task. This should be the start of any UX improvement. If they can actually figure out that the icon will help them accomplish this, they are way ahead of the game. I'll wager the typical customer will never even click on the address book icon—they don't know what it is and will ignore it.

Here's an alternative: it might be better to remove the address book icon and just let them edit the address directly on the checkout form. This wouldn't take them away from the checkout form at all and would seem pretty intuitive. What if they don't want to edit the address, but enter a new one? Maybe we should offer a button that clears out the pre-filled address. Or maybe the drop down should have a "Enter a new address" option.

There may also be a completely different and better way of addressing the add/edit addresses during checkout problem. I haven't taken the time to survey the different approaches in use. I encourage you to look at the checkout form and think about the simplest, easiest ways to deal with the functionality the customer might want (with regards to addresses):

  • How can I re-use an address so I don't have to re-enter it each time?
  • I have various people I ship things to. If I can re-use an address, how can I select which one to use?
  • I don't want to use any of the saved addresses. This stuff will be shipped somewhere new (and I may want to re-use this address later)
  • I don't want this address saved—I'll never re-use it and it will just clutter up my address book.
  • I just realized Joe has moved and this is his old address. How do I update it and make the change permanent?
  • Huh? What's this address doing on the list? Can I get rid of it?
  • I want to use Joe's existing address and turn it into an address for Suzy without losing Joe's address.

You may be able to add to the list. Not all the above are equally important. The less common ones might require more clicks.

But let's get away for any solution that begins with "the user will click on a unlabeled icon". :-)

freixas’s picture

Status: Needs review » Postponed