CheckoutWC 7.0 Released
Table of Contents
- Better Optional Address Fields
- A New Full Name Field
- Example 1:
- Example 2:
- Field Rendering Jujumagumbo
- Inline Postcode Validation
- Inline Email Domain Validation
- A New Login Flow
- The New Login Modal
- New Admin Settings Design
- House Number and Street Name
- New Free Features
- New Order Bump Feature
- That's It For Now
We finally released CheckoutWC on March 5th and now that we’ve been through a few hotfix releases it’s time to officially announce it.
CheckoutWC 7.0 is a pivotal version for us. With the refactors in this release, we moved the project into a better trajectory – one in which we hope to do fewer substantial refactors and focus more on long term stability.
Now let’s dig into the release notes!
Better Optional Address Fields
Sometimes the most exciting things are the little things. Optional address fields will now be hidden behind a link by default. Research indicates that users are often confused by fields such as Address Line 2, which are infrequently filled out and often filled out incorrectly.
By hiding these fields behind a link such as “Add Address Line 2 (optional)” or “Add Company (optional)”, we can reduce customer confusion and improve our conversion rates.
A New Full Name Field
Another area of usability we are addressing is the number of form inputs which can be especially costly to fill out on mobile.
Namely we are providing a new optional feature to combine the first and last name fields as a single Full Name field.
We parse the full name into the respective first and last name fields so everything else will work the same. And our parsing library understands a large variety of names.
Example 1:
Entered Full Name: Dr. David Livingston Jr.
First Name: David
Last Name: Livingston
Example 2:
Entered Full Name: Olivia de Havilland
First Name: Olivia
Last Name: de Havilland
We are excited to hear from customers like you on whether this boosts your conversion rates.
Field Rendering Jujumagumbo
7.0 also includes a big directional change regarding how we render fields. Since our first version, we used a separate function to render input field markup: cfw_form_field()
In 7.0, we are reversing course. We are using the raw input markup from woocommerce_form_field() and making minor adjustments to it. This should cleanup a lot of lingering edge cases where plugins expect fields to be rendered a certain way and then they are not rendered that way.
This should be completely invisible to the user.
Inline Postcode Validation
We have heard your feedback! The way we validate the shipping and billing post codes is not working.
Consequently, we’ve redesigned the whole process. This is how post code validation will work in 7.0:
Inline Email Domain Validation
How many times do you get an order where the customer entered the wrong email address, leaving you unable to reach out to them and leaving them frustrated, wondering where their receipt and updates are?
In 7.0 we’re going to help fix this by validating email addresses in real time. What we do is take the domain name from the email address and make a DNS request for the MX records associated with that domain. If no records come back, we display an error to the customer. It looks like this:
A New Login Flow
We are going back to the drawing board with logins.
As CheckoutWC has become more complex, we have started to question the usability of our login system. The way it works now is that if a user either enters a known email address that matches an account OR they click on ‘Login’, a Password field and Login button was revealed underneath the email address field.
This process worked pretty well, but it had some quirks. For example, when the login button was revealed, the email field functionally became a username OR email field. But it was still validated as an email field. This was confusing for some users.
On top of this, there were logistical issues with the other functionality that was co-located in that area of the form, such as creating an account and when to show a password field for that purpose.
The New Login Modal
Beneath the hood, there is more going on here.
- We’re still checking for existing accounts. If a user enters a known email address, we will open the login modal with their email address pre-filled. And we change the language: It looks like you already have an account. Please enter your login details below.
- Clicking “Lost your password?” seamlessly opens the Lost Password modal.
- We only prompt the user to login (by opening the modal automatically) once per 7 days.
New Admin Settings Design
Ok, I’m definitely biased but don’t these new admin screens look sexy?
But it’s more than just a new look. We took care to categorize settings into useful groups that pair similar types of settings together
It’s also clearer when a setting is dependent on another setting.
We have more to do here but we’re really happy with how it turned out.
House Number and Street Name
We’ve been asked a lot about how to better handle addresses in certain European countries. The pain point is that WooCommerce doesn’t offer discrete fields for Street Name and House Number.
This is problematic for certain jurisdictions where culturally people think of Address Line 1 as two components, and when they see ‘Street Address’ they instinctively write their street name, resulting in an incomplete address and sometimes a failed shipment.
We’ve solved that by allowing merchants to enable discreet Street Name and House Number fields. In additional to enabling the fields, you can also choose the order in which they appear.
On submit, we stitch them back together into one Address Line 1, following the country based formatting rules we apply for Google Address Autocomplete.
New Free Features
7.0 also makes some common features free for everyone:
- User Matching
- Order Review Step
- One Page Checkout
- Php Snippets
Now that we have thoroughly vetted these features and no they don’t increase our support load, we’re comfortable making them available to all license holders.
New Order Bump Feature
In 7.0.9 we added a quick new feature: You can now choose what happens when an Order Bump becomes invalid.
Example, say someone adds a T-Shirt to the cart and they get offered a second T-Shirt at 50% off. They accept the offer and then they decide to remove the original T-Shirt from the cart.
Previously the second T-Shirt would revert to the normal price and they would no longer get the discount. However now you can configure this on each Order Bump. You can elect to remove the Order Bump from the cart if it no longer meets the conditions required to show it.
This is helpful for stores that offer unpublished products as Order Bumps and don’t want people to be able to purchase them at any price without the requisite conditions being met.
That’s It For Now
We have more coming in 2022. If you would like to be notified about updates, subscribe to our e-mail list by signing up in the box below.
