The interface for checking out something from your cart. The current interface is not optimized for checkout processes, where the slightest usability issue causes a drop out. The goal is to create a somewhat good bare bone for a checkout process. This interface will be build along the way of the actual cart implementation.

CommentFileSizeAuthor
#5 cart-form.jpg155.94 KBBojhan
#5 checkout-step1.jpg72.96 KBBojhan

Comments

redben’s picture

redben commented

I think an idea for the checkout process is to give the admin an option to disable drupal regions, during checkout, so as to keep the customer focused on the process and not divert his attention.

archimedes’s picture

archimedes commented
Version: » 7.x-1.x-dev

Is this issue dealing with the entire checkout process (UX-wise), or just the cart screen itself?

I think that one thing that would help the checkout process as a whole (but applies to the cart screen) is the ability to significantly customize text/buttons (including messages from the system). Customization is key for this system.

For example, in the current UberCart setup, the system always refers to it as a "shopping cart". If a non-profit organization uses it for handling donations, is it still a shopping cart? Would another term be better/clearer for them? I think so, so letting them have the ability to make that change would be excellent.

Additionally, having built in support for a themeable progress tracker to show users where they are in the process will go a long way to helping the UX.

Edit: Forgive me for changing the version number, but I couldn't post this issue without specificying it...not sure why.

Bojhan’s picture

Bojhan commented

Obviously, customization should be possible in any way possible UX wise I haven't really started on this yet. But I don't want to differentiate to much from the checkout and cart process. Since the cart screen is simply ,only one screen.

stephthegeek’s picture

stephthegeek commented

Agreed, there is no one-size-fits-all approach here. Some people are going to want to go right to the checkout page, some a one-page checkout, some multiple steps with registration at the beginning, or end, some with editable quantities in the checkout, etc etc etc.

For the comment in #1, I'm not sure if that's really relevant since it's a core functionality in Drupal itself to customize block visibility. It's pretty common to set blocks (especially sidebars) not visible on cart and cart/* in Ubercart.

Bojhan’s picture

Bojhan commented
StatusFileSize
new checkout-step1.jpg72.96 KB
new cart-form.jpg155.94 KB

Alright, so creating any design for the cart is difficult as the default would still create certain assumptions about the product. Therefore I kept everything, as sketchy as possible.

I envision a three step process :
1. Cart
2. Checkout (Billing information & Shipping)
3. Payment

So the big choice we need to make is, are we going to create a default workflow like that? Or are we going to put all of that in the theme layer? Either way, we need to make a choice which theme should be default in terms of making it look good. Since Garland is the default delivered with Drupal, I am siding for it - however if we choose to ship an profile with a different theme I am more then happy to go with that (ie, then I can create a progress indicator, different visual styling)

Instead of wasting hours, on making it fit with Garland's styling and figuring out the individual forms. I would like to discuss which elements will live on the page, and what the workflow will be first.

cart-form.jpg

There isn't much to this page, one thing I would like to throw up for consideration is Taxes & Shipping. At least for dutch sites, its mandatory to mention the delivery costs on this page. So this should be alterable to that extend.

checkout-step1.jpg

This page is a challenge, as I am still unsure from the feedback what elements will be exposed. If we can agree on the three; billing, shipping and products that'd already be enough to work from. The important reason for separating this out with payment, is that they are two very heavy cognitive tasks - putting them together should only be efficient for (very) experienced buyers.

I wanted to wait with creating the payment page, since that tends to highly depend on supported payment methods.

redben’s picture

redben commented

stephthegeek: While controling block visibility can be done through core, it is better to force you visibility settings on the page you need to. Like in the context module.

Bojhan’s picture

Bojhan commented

Moving discussion to #841954: Additional tweaks to the shopping cart form UX

Bojhan’s picture

Bojhan commented
Status: Active » Closed (duplicate)