The 7 page 1 page checkout

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   I am wondering about the so called 1 page checkout.  I count it as 7 clicks through various things to actually checkout. The way it is set up you enter your password then click, enter billing then click..etc. now technically this may be the same page but it certainly feels like 7 pages to get through it.  Do other people see it this way? Have I missed something?

Thanks
Chris

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
Chris Hadden Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 23-January-2013 Status: Offline Points: 52	Post Options Post Reply Quote Chris Hadden Report Post Thanks(0) Quote Reply Topic: The 7 page 1 page checkout Posted: 21-August-2013 at 1:41pm
	I am wondering about the so called 1 page checkout. I count it as 7 clicks through various things to actually checkout. The way it is set up you enter your password then click, enter billing then click..etc. now technically this may be the same page but it certainly feels like 7 pages to get through it. Do other people see it this way? Have I missed something? Thanks Chris
	Chris

Hamish Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 12-October-2006 Location: United Kingdom Status: Offline Points: 56	Post Options Post Reply Quote Hamish Report Post Thanks(0) Quote Reply Posted: 21-August-2013 at 4:17pm
	Hi Chris, I know what you mean, but in the end we need to gather quite a lot of information from the customer. Sometimes what they fill in on one section has an impact on what is offered in the next section, for example shipping to a different address. Showing ALL the boxes that need to be filled in at once would probably lead to a higher rate of carts being abandoned as people may be intimidated by a long form. It would certainly be possible, just not wise IMHO. The OPC took a lot of time and effort to build including researching the look of other ecommerce sites. Of course for repeat customers life is much easier as so much is already filled in.
	Editing ProductCart Code? See WIKI Guidelines for Editing ProductCart's ASP Source Code

Chris Hadden Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 23-January-2013 Status: Offline Points: 52	Post Options Post Reply Quote Chris Hadden Report Post Thanks(1) Quote Reply Posted: 22-August-2013 at 11:11am
	I don't disagree you have a lot of info to gather. I run another web store using another cart and it just looks a lot cleaner and less confusing to me... about 3 clicks to checkout. The checkout in this cart seems a bit tedious, the way the windows pop up on each question your answering I think is a bit disorienting. Of coarse once you understand it you don't give it much thought...but that is not how first time customers will view it. It is a bit of an unusually designed checkout. The way it presents itself to a new comer is not similar to most of the other checkouts and I think that is a negative. I believe most people are familiar with working down a form, you see all the areas before you on a static sheet. Obviously productcarts checkout works well enough, I am just voicing an opinion here that I think it could be improved by simplification in future builds. Don't have techies look at it, ask your grandmother to checkout listen to what she says. Thanks
	Chris

whizzinpc Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 17-January-2006 Location: California Status: Offline Points: 20	Post Options Post Reply Quote whizzinpc Report Post Thanks(0) Quote Reply Posted: 09-September-2013 at 2:36pm
	I agree the one page checkout has way too many clicks. It should just be one screen opened already and you just scroll down and fill out the sections. The payment gateways should also be included on this page so there would be no need to go to a page just to fill out cc info.

Hamish Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 12-October-2006 Location: United Kingdom Status: Offline Points: 56	Post Options Post Reply Quote Hamish Report Post Thanks(0) Quote Reply Posted: 09-September-2013 at 6:38pm
	I think the checkout page in ProductCart and many other carts is always likely to be the cause of much debate, in fact we occasionally get requests to reinstate the old multi-page checkout, but it's not practical to support several versions. I think their are two key reasons for the page being in sections, it's rather less intimidating to a customer than seeing a really long form, also as each section is completed the values entered are validated and that can influence subsequent sections. For returning customers it's less of a problem due to some details being stored and pre-filled already.
	Editing ProductCart Code? See WIKI Guidelines for Editing ProductCart's ASP Source Code

Guests Members Profile Send Private Message Find Members Posts Add to Buddy List Guest	Post Options Post Reply Quote Guests Thanks(0) Quote Reply Posted: 12-September-2013 at 2:13am
	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 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.

whizzinpc Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 17-January-2006 Location: California Status: Offline Points: 20	Post Options Post Reply Quote whizzinpc Report Post Thanks(0) Quote Reply Posted: 12-September-2013 at 10:47am
	Excellent post Sean! The discount code mod is something that we've been talking about for a long time. Its definitely the right way to do it. Looks like you've put a lot of thought into OPC. What type of commitment do you need from us to get it done.

Guests Members Profile Send Private Message Find Members Posts Add to Buddy List Guest	Post Options Post Reply Quote Guests Thanks(0) Quote Reply Posted: 18-September-2013 at 12:39am
	Thanks, Art. Sorry so long to get back on this, but I have indeed put a lot of thought into it and have had to put more thought into it while also being called to task on other major enhancements. On the OPC, just to summarize, I see three primary shortcomings I would tackle: 1) Discount Code before Checkout (this is packaged for release here: http://www.wmsmerchantservices.com/shopping-carts/ProductCart/Discount_Codes_before_Checkout.asp) 2) Payment Gateway within the OPC This would have to be restricted to a very small set. I'm looking at Authorize.Net and PayPal Pro (was Website Payments Pro). I'm within striking distance of a beta on this, but it will still be a good deal of revamping ... and I don't have a budget for it: just one motivated client and a lot of folks wanting to see it happen. 3) Collapse the Address Info panel into one panel (rather than the current three sub-panels) This appears to be doable (assuming one forgoes the option to allow an address book option), but it's complicated, esp. as the Billing Info form adds the customer account (for new/guest users & updates the account for returning users) and that has to happen before a default shipping address can be added to it (for new/quest users). Doing this without major changes to the AJAX & JQuery here is a challenge, but I'm still convinced it possible. I think this would go a LONG way toward assuaging the concerns of PC merchants vis a vis the OPC, but I currently have no buy in on it ... and plenty of other fish frying or to fry. So, I don't currently have anything to push this idea forward, much as I would like to have. As for commitment, Item 1 is obvious (purchase through the link above). Item 2, I need enough folks to split an adequate budget (which is something not appropriate to discuss here, so I'd have to find an avenue to "herd the cats" -- soliciting RFQ's via http://www.wmsmerchantservices.com/rfq.asp would get them into our ticket system and could be managed from there). As for Item 3, I don't know at the moment. The SEO Toolkit we're actively working on is likely trumping that, so without a budget to dig in on it further, we're probably not going to get further on it than the exploration we've already done. Maybe NetSource would agree with what I see here and might run with it. Summary: For the majority of merchants using PC, I can see a simplification of the OPC that would assuage most all of their concerns if coupon codes could be applied before checkout (we've done that), the most used couple of gateways could be incorporated into it (we can do it this with more "buy in"), and the first panel could be collapsed into essentially a Billing & Shipping Info format (can be done with some serious effort, but we're not signing onto this yet). The bottom line is to accomplish all of this without changing the paradigm of how the OPC is built, but rather play off of what is there and change up the behavior of it -- so that updates are not painful if modifications such as these were applied to a site.