We've been planning to use the Commerce Checkout Login for our new webshop due to its friendliness towards the end-user. However, the branch 2.x is forcing us to rethink this plan and I am asking myself if the 2.x approach is the right one, as I feel it is a major regression in user experience, both on desktop and especially on mobile devices. In branch 2.x, the module joins a great pile of modules that already offer a similar mechanic, including Commerce Extra Login Page and Commerce Checkout Redirect which is included in the Kickstart 2.
User's primary task in a checkout is to buy a product / service. By forcing him to login/checkout/continue as guest, we are adding an unrelated decision to the process, which increases bounce rate.
If the login is required, it makes sense to go with a modal approach (or a redirect as with Commerce Checkout Redirect), which reuses the site's standard login and registration forms. If the login is not required, the user should not be forced to make a decision about his account until after he has completed his primary task.
The situation is even worse on a mobile device where lack of width forces us to align forms one on top of another (which clutters the UI) or use yet another related solution in the form of Commerce Login Step - not to mention that I have no idea what all those instructions are doing on what's supposed to be a simple step for the user.
Consider that in branch 1.x, the user initially only saw one simple e-mail field - a standard staple of e-commerce checkouts. In 2.x, he sees one form for login, one for registration and a bucket load of needless text. We're not Amazon in 1995 here, we're supposed to have evolved beyond reading 60-page instructions just to buy that yellow umbrella.
TLDR: In my honest opinion, 2.x is a hard miss, mimicking existing solutions, while losing its unique and UX-friendly approach in the process. End-User should always be first.
Comments
Comment #2
legolasboEven though I disagree with your opinion I first of all want to thank you for your honesty.
In my experience as the 1.x branch is not as user friendly as it seems. The Ajax refresh is often confusing for users and throws errors during the checkout process if a user submits the form too quickly after entering their e-mail address. This can cause the user to be shown the same form several times, often without explanation.
Besides those issues, the 1.x version of the module has proven to be fragile and hard to maintain and extend.
However I do see your point that there is room for improvement in the 2.x branch. The instructions could probably be made simpler and the login/register forms could use a designer/UX-expert's touch. Looking at Commerce login step I do like their solution.
Anyway, I feel I might have been a bit too rigorous when I made the 1.x branch unsupported, so I've re-enabled it if you wish to use it. However, I will not provide any support on that branch other then committing RTBC patches.
Comment #3
legolasboI created #2684461: Simplify the account pane as a follow up issue to simplify the login/register pane.
Comment #4
andrej galuf commentedThank you for hearing me out and reopening the 1.x branch (for now). I will be sure to test #2684461: Simplify the account pane and leave my comments.
Just one more short comment on this matter:
I agree with the Ajax refresh being fragile when the request is still running. This goes for all ajax requests however - how often have you tried updating a View while the automatic preview was still being processed? Generally, the way to deal with those requests is either by blocking a submission while Ajax is running or by deferring the action until after Ajax is done (the first being my preferred way unless you're running an Ajax in the background). Since the commerce checkout process is littered with ajax anyway and since we tend to use a lot secondary calls such as automatic shipping calculation, zip code lookups and so on, we never really found that part an issue.
In my experience, users like the simple interface in 1.x. What does come up from time to time though, is a question of security and privacy, as everyone could essentially check if a certain e-mail exists in the database.
Comment #5
brianlp commentedAfter switching to the "new approach" it turns out that some of the Guest checkouts are still willing to create an account after checkout. This is my finding from the "I want to set a password for this account" button on the checkout-complet page.
I'm not familiar with the code, but would it be possible to turn a guest account into a regular account after checkout if the user is willing to do so?