|
I wanted to pipe in here having "lurked" on it for a few days and also having clients come at us with the same concerns ... and because I think this conversation is worth having and shouldn't be quashed by it causing debate.
I get it from the perspective of a techie, and from the perspective that one's "grandmother" is one's best beta tester ;-)
As a techie, and having worked a little with EI on the initial build, I get the technical challenges up against the current OPC to potentially provide a large number of features in context -- many of which most merchants don't use and probably aren't even aware of. It's complex to work through and validate all of these possible scenarios -- hence the code here is complicated to modify.
One of the major inspirations for this build was Gap.com, and while Gap.com has changed some things since EI released this with 4.0, the essential nature of Gap.com's checkout funnel is the same.
I have been thinking about it for a good while now, and I do think there is some room for improvement/streamlining things for the typical merchant.
Whether or not opening up the core fields of the form here would overwhelm users or assuage their concerns about how many things they are going to have to move through is not a very helpful debate, pragmatically speaking. Opening it all up (something like Lulus.com) just isn't going to happen without a complete overhaul of how the whole thing is AJAXed.
So, more pragmatically speaking, I'm interested in how this could be a bit more streamlined given what it currently is.
Right off the bat, I'd like to restrict this to just thinking about the most basic aspects and not all of the possible features options available. I think those are handled well and fit into their panels just fine.
With that said, in my mind I've boiled it down to this primary observation: There are essentially three panels to the accordion: Address info, Shipping Method and Payment & Other Info. I think that essential structure will have to remain true unless or until the whole thing is done differently.
The Shipping Method panel kinda has to stay as is without a whole lot of re-invention of the process here. The shipping address info and customer level simply must be known first before the appropriate shipping options can be populated (and the layout of that panel -- tabbed out by Carrier + Custom Shipping Options has to be that way to comply with UPS rules).
That leaves the two other panels as candidates for improvement.
My thinking on the Address panel is that this should/could be opened up if an option to allow the merchant to toggle off allowing customers to save addresses to an address book could be introduced. If this were the case, then for new/guest users this panel could show both billing address and shipping address forms at once and skip over whether to use billing address as shipping address else add a new address ... and for returning users the shipping address form would be populated with their "default" address last used. This would skip over the interim step in this panel. The link above the shipping address to fill from the billing address could be offered (this is just JavaScript) to help streamline for either user, and of cause the option to nick name the address would be foregone.
Boom! Now the first panel is closer to what folks are looking for ... yet they'd still have the option to step through this panel as it currently is IF they want to let folks use an address book. I've spent several hours playing with this idea, and the option definitely seems viable to me with the code paradigm as currently built .... I just can't seem to quite get the AJAX right, though. I'm still convinced that it is a viable option to let some merchants streamline OPC while letting others provide more nuanced options to their customers/users within this panel.
The Payment & Other Information panel does a lot of work -- most of which is situational depending upon the features the merchant is using and the options that therefore may or may not apply to the customer/user. There are some tweaks to the layout of those options I always apply to make it a little nicer for the user, but the big fat elephant in the room there is that when the merchant is using a payment gateway (probability of that being nearly 100%), the "OPC" degrades to a "TPC" forcing a save order and redirecting to a gateway page.
Understandable from the techie perspective -- M'Gosh! there are SO MANY gateways integrated!!! It would take a tremendous effort to work them all into the OPC. However, there is an easily restricted very small set of payment gateways any given merchant is very likely to be using. I have looked at this very closely and am moving on integrating Authorize.Net and PayPal Pro (was Websites Payment Pro) into this part of the OPC. Not easy, but I don't see why it's not doable.
That would just leave one other beef I and many PC merchants have: entering coupon codes. Forcing customers to wait until the very end of the OPC freaks them out; it's just too much to ask of them, and they abandoned their carts.
We have already solved that issue with a recent add-on to enable them to enter their code on viewcart.asp (the cart summary page before they proceed into the OPC). It's available here: http://www.wmsmerchantservices.com/shopping-carts/ProductCart/Discount_Codes_before_Checkout.asp" rel="nofollow - http://www.wmsmerchantservices.com/shopping-carts/ProductCart/Discount_Codes_before_Checkout.asp
I am going to continue working on my ideas here for how to streamline the current OPC, but without a budget generated from folks seriously interested in seeing this happen soon, I can't make it happen soon and I'm pretty sure that resources currently allocated to the next update of PC are not focused on concerns here either. This is where we 3rd party developers can help liaison between where the application is now and where the PC developers are working on taking it.
I believe my approach here is pragmatic and can step forward on bridging the gap between how PC's OPC is currently built (and the plethora of scenarios it has to contend with) and a more streamlined version of it many merchants would like to be able to deploy on their own sites.
|