Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

August 21 2018

Onboarding Users Of Your Product: From Trial To Payment

Onboarding Users Of Your Product: From Trial To Payment

Onboarding Users Of Your Product: From Trial To Payment

Joe Leech
2018-08-21T14:20:21+02:002018-08-21T13:33:03+00:00

(This is a sponsored article.) In part one of this series, we looked at the Attraction phase of the customer lifecycle. This three-part series outlines the three phases of the product lifecycle, the future for UX, and the skills and approach you’ll need to design modern digital products.

  • Part 1: Attraction
    Going out there to get users to evaluate your product.
  • Part 2: Activation
    Signing up, onboarding users, asking for payment.
  • Part 3: Retention
    Encouraging users to come back and keep using and paying for your product.

Part Two: Activation

Plotting Out The Journey

When we talk about the Attraction phase, we’re talking about users discovering they have a need, discovering our product and visiting our website to see if our product meets their needs.

Within the lifecycle, we can split the larger three phases into smaller phases to help us plan our approach. In this case, we can use Philip Kotler's model (expanded to 6 steps by Bryony Thomas).

  • Awareness
    Realizing they have a need.
  • Interest
    Looking for something to help with that need.
  • Evaluation
    Looking at products that help with their need.
  • Trial
    Trying the product to see if it meets their need.
  • Adoption
    Choosing a product and using it for a while.
  • Loyalty
    Deciding to stay using the product or switch to a different one.
(Large preview)

We’re interested in the middle two parts that fall under the Acquisition phase.

In part one, we looked at the Evaluation phase. The user is now ready to sign up and get going with our product; we used the example of the money management app:

Homepage showing what our app does. Homepage showing what our app does. (Large preview)

Let’s take that app forward into the Acquisition phase of the lifecycle.

A. Trial/Onboarding

In the Trial phase, our user is going to sign up and see if it is the product for them.

The first challenge is to onboard the user. Onboarding is a real challenge as it can be complex, involving the user entering personal information as well as getting to grips with what the product does. There is a huge potential for users to drop out and leave.

Joshua Porter sums it up:

“Onboarding should not be a separate function/consideration/afterthought. It should be an initial (and primary) focus of design.”

Joshua Porter

So with that in mind, let’s take a look at onboarding.

Onboarding: Steady Progress Showing Value

For our money management app to work well we need for our user we need to accomplish three goals:

  1. Collect some personal data from our users.
    Who they are (including email, mobile phone number, etc.).
  2. Bank account access, to auto pull in transactions.
    As we’re in the EU, open banking regulations mean that all banks have to provide API access to transaction data.
  3. Familiarize them with the product.

That’s a big ask. Let’s think about how we can soften that. We need a simple hook to get started. We use a concept in psychology called ‘incremental commitment.’ We ask for a low commitment to the product and then when the user gets something in return was ask for more.

We ask the simple question, “How much do you think you spend on coffee a month?”

A simple question to get started A simple question to get started. (Large preview)

This can be done along with a hook to encourage people to compare their spend to others. There’s now a quick, easy win for the user.

We give something back, in this case comparing to the average. Then, we ask the next question.

incremental commitment in action. We ask a follow-up. Incremental commitment in action. We ask a follow-up. (Large preview)

It allows us to build trust, and for the user to get value from our product early.

Next, the big ask. We want bank account access. If we’d asked for this early, we’d see a larger dropout. But we now have built some trust, and our user is invested in the product.

(Large preview)

We then go for the big ask, granting bank access. As you can see, we are gently guiding our user through the onboarding, showing useful content at each step, trying to make it feel natural.

Asking for what could be challenging data like the mobile phone number is much easier if we offer context and say what benefit there is to the user. We could include the following on the sign-up page asking for the mobile number.

showing how giving us your mobile number adds value Showing how giving us your mobile number adds value. (Large preview)

We can then ask further questions, like email and for a password which will have less impact being asked later after we’ve shown value.

Interaction by interaction we’re asking a question, gathering some data and showing how the product works.

Things To Avoid During Onboarding

There are other pitfalls to designing a product onboarding flow.

  • Avoid the term registration, Registration is a meaningless concept, offer a reason for why you are asking for a pieces of information.
  • Similarly don’t ask too many questions, that might sound obvious, but the more you ask the more likely it is for users to drop out.
  • Answer these three simple questions when it comes to form fields:
    • Why are you asking the question?
    • What will you use the data for?
    • What value does the user get from giving us this data?
  • Avoid Captcha; it is a big cause of dropouts as captchas can harm conversion rates. Plus, they aren’t very friendly.
  • And, of course, if your users are located in the EU, you need to wrangle with GDPR.

B. Adoption

Onboarding doesn’t end when the user has signed up. This is a common mistake made by organizations big and small. “Great, our new registrations are up month on month. But our retention rate is really poor” is a common problem.

We need to support our users through the first few weeks and months of using our app. We need to give them a reason to come back to us.

In part one, we talked about SEO and Marketing skills and tools we can use to improve the experience.

We’ll be expanding our skill set to look at email, and how we can improve the email experience. To encourage product adoption, we need to understand and map the email user journey.

Any modern UX or product designer needs to know how to design multi-channel experiences, and after the product itself email is the most important.

Planning And Encouraging The Second Visit

For our money management app we have access to the users' bank transaction data. Rather than hoping they return to our app, we need to reach out and give them a reason to come back.

The pull: using email to get users to come back to our app

Let’s look at an email we can send them the next day. But before we do that, let’s look back at one question we asked users:

Notice that the ‘on coffee’ can be changed for other spending items. (Large preview)

The user could have changed ‘on coffee’ to be ‘at Restaurants’ or ‘at Amazon’ or another discretionary purchase option.

This is a tiny piece of personalization, and the best follow-up emails are personalized.

When designing an email the most important element is the subject line. A good subject line encourages the user to open it.

Let’s look at the most common email provider of them all, Gmail. Like we did in part one when designing Facebook ads, we’ll design in context, in this case the crowded inbox. Actually, the promotions inbox on Gmail.

There’s one email in there that stands out, yes it’s us! (Large preview)

By referencing the Frotos we identified in part one (Frotos: are the current bad state the user has and their wish for a new state. The From and the To, Froto) we should get a better open rate.

And yes, that is an emoji you see. Two in fact. 😜

This article is great at helping you decide if emojis are right for you: Emojis in email subject lines: smiley face, or smiley poop? as it has a lot of data.

TLDR, emojis can help boost open rates, and well...

What an emoji (in a subject line) does is one of two things:

  1. It makes a bad subject line worse;
  2. Or it makes a good subject line better.

We also need to think about other email design considerations:

Don’t forget to test your emails to make sure they look as designed — Litmus is great at this.

User Research And Email

It’s a good idea to user research your emails, you’ll be surprised at what useful ideas you’ll get back. Using the emails as prompt material will encourage users to answer the question “What could you offer me that would make me come back to the app?”

Drip, Drip, Drip That Email

That’s email one done, great job! But now we need to think about an ongoing programme of emails. It takes a while to form a habit, and that’s what we’re after. Getting our users to keep coming back. It can take from 18 to 254 days so we need to keep sending those emails.

These emails should offer value to our users. The key insights our product offers should be easy to deliver by email, SMS, or indeed any digital channel.

Our product promises a “Personalised Savings Plan” that’s what we need to deliver.

The best performing products work seamlessly across digital channels.

To encourage product adoption and to help our user save we could offer SMS messages.

(Large preview)

SMS is a neglected message format. Yes, it can be annoying if done badly, but it can equally be effective for our users.

Some SMS stats:

  • 98% of text messages are read within 2 minutes;
  • Open rates are around 99% for text messages compared to 20% for email;
  • Click through rates are around 30% for SMS and less than 5% for email.

That makes a compelling case for the effectiveness of SMS. Look at the success of startup Shine and learn more about how they use SMS.

We can encourage our user to save money by using SMS, sending an email once a day. A daily, personalized, money coach is a huge benefit to our user.

(Large preview)

This article is a great for planning your messaging approach: Level-Up Email Campaigns With Customer Journey Mapping — Smashing Magazine.

Here’s some more great advice on planning email drip programmes:

User Research And Email/SMS

Researching the effectiveness of email and SMS is best done through AB testing. Testing different variants to see which performs better.

User research can help understand what content users will find useful and by what channel.

The Secret To Onboarding And Adoption: It Takes Time

Onboarding should be done gently, in short chunks offering value immediately. When it comes to asking for precious information like mobile phone number, bank account or email we need to demonstrate how we will deliver value.

To get a user to adopt our service takes time. We need to be able to deliver useful content over a long period of time to encourage them to keep using the product.

Next Up, Retention

In the first part we talked about the beginnings of the customer journey how to attract or users.

Coming up next, we’ll talk about how to retain users and get them to pay for our product — that holy grail of our user taking out a monthly subscription. Stay tuned!

The parts of the user journey The parts of the user journey. (Large preview)

This article is part of the UX design series sponsored by Adobe. Adobe XD tool is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

Smashing Editorial(ra, yk, il)

August 20 2018

UX And HTML5: Let’s Help Users Fill In Your Mobile Form (Part 1)

UX And HTML5: Let’s Help Users Fill In Your Mobile Form (Part 1)

UX And HTML5: Let’s Help Users Fill In Your Mobile Form (Part 1)

Stéphanie Walter
2018-08-20T13:45:31+02:002018-08-20T18:56:09+00:00

Forms are one of the most basic primary interactions users will have with your websites (and mobile apps). They link people together and let them communicate. They let them comment on articles and explain to the author how they strongly disagree with what they’ve written. They let people chat directly on a dating app to meet “the one”. Whether for forums, product orders, online communities, account creation or online payment, forms are a big part of users’ online life.

It’s 2018, and we have more mobile than desktop users around the globe. Yet, we still treat those users as second-class citizens of the web. Everybody writes and speaks about user experience all the time. So, why, why, why are so many websites and products still doing it wrong. Why is their mobile user experience damaged for half of the world? Why is it still a pain, why is it still super-hard to book a flight and register an account in a mobile form today? Users expect better!

Recommended reading: World Wide Web, Not Wealthy Western Web

This is the first part of a series of two articles. In this one, I will sum up some essential best practices to improve your mobile forms, including scannability and readability. I will guide you through label and input placement, size and optimization. We will see how to choose the right form element to reduce interaction costs. Finally, you will learn how to prevent and deal with errors on mobile forms.

In the second part, I will take a closer look at specific mobile capabilities and HTML5 form elements, and we will go beyond classic form elements to make unique and enjoyable web applications and websites.

Note: While most of the code enhancement in this article are web-related (because I don’t know Swift or Java), the usability best practices hold true for mobile applications.

Nope, we can't do any magic tricks, but we have articles, books and webinars featuring techniques we all can use to improve our work. Smashing Members get a seasoned selection of magic front-end tricks — e.g. live designing sessions and perf audits, too. Just sayin'! ;-)

Explore Smashing Wizardry →

Form Design 101: Prioritizing Scannability And Readability

“A form is the name, value, pairs, in a structure for storing data on a computer barfed out as labels and input fields to human being.” This is a direct quote from Luke Wroblewski at a conference. Like him, I believe that most form usability issues come from this tendency to serve the structure of the database to users.

Strong Information Architecture

To build better forms, you first need to take a few steps away from your database’s structure. Try to understand how users want to fill in forms. This is where doing some usability testing and user research on your forms becomes handy. User mental models is a UX concept that can help you with that. Nielsen Norman Group describes it as “what the user believes about the system at hand”. Ask your tester to think aloud and tell you how they would fill the form. Which steps do they expect? What come first? What comes next? This will give you a better idea of how to structure your form in a more user-friendly way.

Visually grouping fields that belong together will also help users fill a form. In the code, use the fieldset tag to group them programmatically. It will also help screen readers understand the hierarchy.

example of visually grouped forms Chunking information and grouping related pieces of information helps the human brain process this information in an easy, more readable way (Large preview)

If the form is long, don’t expose everything by default. Be smart about what you display. Use branching wisely to display only the fields that people need. In a checkout form, for example, don’t display all of the detailed fields for all of the shipment options. This will overwhelm the user. Display enough information to help them choose the right shipment option. Then, display only the details and fields related to that choice.

User attention spans get shorter with time: Ask for optional things at the end of the form. For instance, if your form is a customer-satisfaction survey, ask for demographic information at the end. Better yet, auto-fill them, if possible. Ask users only for what’s necessary.

Finally, plan ahead for localization: What will happen when your form gets translated? What will happen, say, for German? Will your design still work?

Label Placement And Input Optimization

Single-Column Layout Works Best

Due to the lack of space, you don’t get endless options for placing labels and fields on mobile screens:

  • Present fields in a single-column layout. There’s no room on mobile for multiple columns. Multi-columns forms are not a great idea on desktop either anyway.
  • In portrait mode, it’s better to place the label on top of the field so that users can see what’s in the field when they type.
portrait mode In portrait mode, it’s better to put the label on top of the field. (Large preview)
  • In landscape mode, the screen’s height is reduced. You might want to put labels on the left and inputs on the right. But test it to make sure it works.
landscape mode In landscape mode, you want to put labels on the left and inputs on the right. (Large preview)

For more on label placement, see Baymard Institute’s “Mobile Form Usability: Place Labels Above the Field”.

Labels Should Be Clear And Visible And Work Without Context

Remember that as soon as a field gets focus, the keyboard opens and will take at least one third of the screen’s area. On small mobile screens, users will also have to scroll to fill the form. This means that they will lose part of the context while filling the form. Plan accordingly:

  • Your labels should be clear, visible text that can be read and understood without context. User should be able to complete each label and field pair as a separate task, even if they lose context.
labels should be clear Just “Address” without context is more complicated to process that “Shipping Address”. (Large preview)
  • Avoid jargon, abbreviations and industry-specific language whenever you can.
  • Be consistent. If you use “customer” in a label once, stick with that word. Avoid using “clients” later because it might confuse users.
  • The font size should be big enough. Test your form on real devices as soon as possible, and adjust the size accordingly.
  • All-caps text can be hard to read for some users. You might want to avoid using all-caps text on labels.
  • The label copy should be short and scannable. If a field needs clarification, don’t put it in the label. Use a field description instead.
Avoid full caps, jargon and very long labels. Avoid full caps, jargon and very long labels. (Large preview)
Input Size Best Practice

If possible, the size of the input element should match the size of the expected content. This will help users quickly fill in the form and understand what’s expected.

Properly sized inputs help the user scan the form and understand what is expected in the fields. Properly sized inputs help the user scan the form and understand what is expected in the fields. (Large preview)

Using Masks To Avoid Splitting Inputs On Mobile

Don’t split inputs just for the sake of formatting. It’s especially annoying on mobile, where users can’t use the keyboard to navigate between fields. It requires extra taps just to go to the next field to fill in the form. You might be thinking, “But I’ll automagically put the focus on the next field when I get the required number of characters in that field”. That could work. But you will have taken control of the UI, which becomes unpredictable for the user. Also, it would be a pain if you automagically sent them to the next field and they needed to correct something in the last field. Finally, it’s more complicated to guess what’s mandatory with split inputs. So, let’s stop playing the “But what if” game and simply not split inputs.

Don’t split the phone number into many little inputs. Don’t split the phone number into many little inputs. (Large preview)

I get it: You still want to be able to format your user’s data in small pieces to help them fill in your fields. And you are perfectly right about that. To do so, you could use masks. Instead of splitting an input, just put a mask on top of it, to visually help the user fill it. Here is a video example of what a mask would look like to help users fill in a credit-card field:

Masks help to prevent errors by guiding users to the correct format. Avoid gradually revealing them — show the format directly. Also, avoid putting fake values in the mask. Users might think it’s already filled. That’s why I’ve replaced the numbers with a little “X” in my demo. Find what works best for your type of input.

Finally, remember that some data can vary between countries, and sometimes the format changes, too (phone numbers, for example). Plan accordingly.

Efficient Fields Descriptions

Displaying efficient field descriptions can make the difference between a seamless and a painful form experience.

What Can Descriptions Be Used For?

Descriptions can help users in so many ways. Here are a few examples.

  • What Exactly Are You Asking For?

    For whatever database-related reason, some shipment companies ask for "Address 1" and “Address 2” fields. This is highly confusing for users, but you might not have a choice here. Add description fields to help users understand what they need to put in each field.

    Inline descriptions help users understand why you need this information. Inline descriptions help users understand why you need this information. (Large preview)

    The same goes for acronyms and abbreviations. I know I said that you should avoid them, but sometimes you can’t. If you work on complex forms for a particular industry, for instance, they might have their own set of abbreviations. Any new user who needs to fill in the form might not be familiar (yet) with those abbreviations. Having a description available somewhere will help them.

  • Why Do You Need This Information?
    Users might be reluctant to give you personal information if they don’t understand why you need it and what you will do with it. But sometimes you still need to ask for such information for legal reasons (like date of birth for a website that sells alcohol). Using field descriptions here will help users understand why this kind of information is needed.

    On e-commerce websites, you might want to ask for the user’s phone number in case the delivery person needs to contact them. This is a legitimate reason. So, again, use descriptions to explain to e-commerce users why you need their phone number.

    Sometimes you need information for legal or practical reasons. Again, tell the user why. Sometimes you need information for legal or practical reasons. Again, tell the user why. (Large preview)
  • “Where Do I Find the Information?”
    If your users need to find certain information somewhere else in order to fill a form, tell them where to find it. I worked on a mobile app that lets user track their house. Users needed to pair the app to the monitoring device using a serial number. It’s not very easy to find this serial number on the device; it requires some instruction. We added a little ? button next to the serial number field. The button opens a modal that shows a picture and some indication to help the user understand where to find the serial number on the monitoring device. E-commerce websites do the same with promo codes: They give indicators that tell users where to find the codes. Users can tap to open a pop-up in which they can find extra information to help them fill in the field Users can tap on the link (left) or the question mark (right) to open a popup where they can find extra information to help them fill in the field. (Large preview)
  • “How Should I Format The Information?”
    Some fields need a particular format. In this case, use descriptions to let users know the formatting rules up front. Here are a few examples:
    • Phone number: do I need to put the international dialing code (+xx) in front of the field?
    • Is there a maximum length? Twitter on mobile does a good job with that one.
    • When dealing with monetary amounts, is the format with comma (like 10,000) or a space (like 10 000)?
    • What format do you expect for dates? I’ll let you check on Wikipedia what a nightmare that is. The difference between DD MM YY and MM DD YY can cause a *lot* of trouble to users when booking online.
    Note that a lot of those formatting issues can be solved by input masks. We will come to that later in the article (or you can jump right in if you are impatient). In the old 180-character days, Twitter used to tell you exactly how many characters you had left. Also, the date format varies from one country to another, so you might want to explain what to expect. In the old 180-character days, Twitter used to tell you exactly how many characters you had left. Also, the date format varies from one country to another, so you might want to explain what to expect. (Large preview)
How To Display Descriptions

In the examples, above, we saw a few ways to display field descriptions. Here is a summary of what to do:

  • Inline descriptions should be directly visible and displayed next to the field.
  • If you need more in-depth descriptions with heavy content, you can use tooltips or modals. Tooltips are generally triggered on hover on desktop and on tap on mobile. The same goes for the modals: Open it when the user taps the help icon or “see more” link, for instance.

Be Careful With Placeholders

I get it: it’s tempting to remove fields on mobile to gain space and use placeholders instead. We’ve all gone down that road. But please don’t. The HML5 specification is clear about this: “The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry”. And here is why:

  • The placeholder disappears when the user starts typing. The user must then rely on short-term memory to remember what they are supposed to put in the field. If they can’t, they will need to empty the field to see the indication.
  • It’s hard for users to double-check fields before submitting because the fields no longer have any label indications.
  • It’s hard to recover from errors once a field has been submitted because, again, there’s no label to help the user.
Placeholders rely on short-term memory Placeholders rely on short-term memory. They make forms hard to check before submission. And recovering from errors is hard, especially when error messages don’t help much. (Large preview)

Even if you use placeholders with labels, you might still have some issues. It’s hard to tell the difference between a filled field and a field with a placeholder. I’m a UX designer who writes about mobile form design and even I got tricked last week by one of those. If it happens to me, it will happen to your users — trust me on that one. Finally, most placeholders have light-gray text, so you might have some contrast issues as well.

It’s easy to mistake some form fields for being filled in It’s easy to mistake some of these fields for being filled in. The right screenshot is something I’ve seen online. I’ll let you guess what is filled in and what is not. (Large preview)

If you want to go deeper in this topic, there’s a great article named “Placeholder Attribute Is Not A Label, and also Joshua Winn and FeedbackGuru go into detail on why this is a bad idea. Nielsen Norman Group also wrote a piece on the topic, named “Placeholders in Form Fields Are Harmful.”

Placeholders are not mandatory in HTML5. From a usability point of view, you most certainly don’t need a placeholder in every field of your form. But with the massive adoption of Bootstrap and other frameworks, it looks like a lot of people just copy and paste components. Those components have placeholders, so I guess people feel kind of obligated to add something to the placeholder in the code? If your form’s placeholders look like “Please fill your — label — here”, you’re doing it wrong.

form example I’m not joking: I’ve actually seen forms with 12 fields, with each placeholder less useful than the last. (Large preview)

Labels inside fields could, nevertheless, work well for short forms in which fields are predictable. Login forms are a good candidate for this. But please don’t use the HTML5 placeholder to code this. Use a real label in the code and move it around with CSS and JavaScript.

Labels inside fields can work on really short forms, like login forms, where users don’t have a lot of information to remember. Labels inside fields can work on really short forms, like login forms, where users don’t have a lot of information to remember. (Large preview)

Since the success of Android’s material design, a pattern has started to emerge: the floating label. This label is inside the field when the field is not filled in, so it takes a bit less vertical space on mobile. When users start interacting with the field, the label moves above the field.

This looks like an interesting way to gain some space, without running into the “placeholders in place of labels” issues cited above. Nevertheless, it does not solve the problem of users possibly mistaking a placeholder for filled-in content.

The floating label, even if not perfect, is an interesting alternative to gaining vertical space on the screen. The floating label, even if not perfect, is an interesting alternative to gaining vertical space on the screen. (Large preview)

Interaction Cost Reduction For Successful Forms

Reducing the interaction cost (i.e. the number of taps, swipes, etc.) of users achieving their task will help you build a seamless form experience. There are different techniques to achieve that. Let’s look at a few of them in detail.

A Magic Study On The Internet Told Me To Reduce The Number Of Fields

More fields mean fewer conversions, right? You might have encountered the “we reduced our subscription form from 11 to 4 fields, and it drove up conversions by 160%” study. It’s a classic. And if you look at their contact form, it kind of makes sense. Why would users want to fill in 11 fields just to contact the company? You can’t ask such a big commitment of people who barely know you, right?

Start by asking only for useful information. Why do you need a person’s gender to create an account for them? Why do you have two lines for the address if your subscription form is for an online service?

Ask only for the information you need. And then ask for the information in context. If you have an e-commerce website, users might be more inclined to give you their address in the shipping section of the checkout process than when they register. It will make your e-commerce registration form so much easier to fill on mobile!

Ask only for the information you need Ask for the user’s address in the shipping section of the checkout, not when they register. (Large preview)

Also, don’t blindly trust every statistic and study you find on the Internet. Remember the 11-fields-to-4 study? Well another more recent study showed that by reducing fields from 9 to 6, conversions dropped by 14%. Shocking, isn’t it? Why? Well, they removed the most engaging fields. Long story short, they then went back to 9 fields, put the most important on the top, and voilà, conversions increased by 19.21%.

The bottom line is that while these studies are interesting, those websites are not your website. Don’t blindly trust the first study you find on the Internet.

So, what can you do? Test. Test. And test!

  • Do some user testing to see the time to completion of your mobile form.
  • Measure drop outs.
  • Measure problems with certain fields.
  • Measure the frustration associated with certain fields. How willing are users to give that information? How personal is that information?

Optimizing Touch Interactions

Making Controls Touch-Friendly

If your fields are too small or hard to reach, users will make errors and will need extra interactions to achieve their goals. Remember Fitt’s law? You could apply it to mobile design as well: Make your labels, fields and form controls easy to tap by increasing the touch target size. For labels on the web, a little more padding can increase the touchable area. Sometimes you will also need to add some margins between elements to avoid missed taps.

Also, don’t forget to link labels with their components by pairing for and ID values. That way, if the user misses a tap on the label, the corresponding field will still get focus.

On mobile, respect mobile touch-optimized best practices, and make sure inputs are big enough to be easily tappable. On mobile, respect mobile touch-optimized best practices, and make sure inputs are big enough to be easily tappable. (Large preview)

Steven Hoober conducted some user research on touch areas. You’ll find a summary in “Designing for Touch”. Based on what he discovered, he built a little plastic ruler tool: the mobile touch template. The tool could help you make sure your touch areas are big enough for mobile forms and more generally for mobile design.

Image from Steven Hoober Image from Steven Hoober’s mobile touch template. (Large preview)

To learn more about designing for touch you can read the following:

Providing Feedback

Mobile users don’t have a mouse (no kidding), so they don’t get the “click” feedback that desktop users get when hitting a button. Mobile form users need clear feedback when interacting with elements:

  • Provide a focus state for the form field that the user is interacting with.
  • Provide visual feedback when the user interacts with a button.

I’m not a big fan of material design’s ripple effect on buttons. But I must admit that the animations on Android provide clear feedback when the user interacts with a button.

Honor The Next And Previous Button Order

Finally, honor the next and previous buttons on mobile keyboards. Users can use them to quickly navigate fields. The tabindex order should match the visual order of fields and components.

iOS has small arrows on the keyboard to go from one field to another. iOS has small arrows on the keyboard to go from one field to another. (Large preview)

Avoid Dropdowns On Mobile If Possible

Dropdowns (the HTML select element) on the web require a lot of tabs and interactions. Therefore, as Luke Wroblewski said, they should be the UI of last resort. Many other UI components work better than dropdowns in many situations.

Segment controls and radio buttons are good alternatives to dropdowns if you have between two and four options. Why hide the options under a dropdown when you can show them all directly on one screen? Note that, like radio buttons, segment controls are mutually exclusive.

Example of segment controls in the iOnic library. Example of segment controls in the iOnic library. (Large preview)

A country list is a good candidate for a component. A dropdown of over a hundred countries is an interaction nightmare on mobile. It’s OK if you are looking for Afghanistan (at the beginning of the list) or Zimbabwe (the end of the list). If you’re looking for Luxembourg, you will end up in a game of scrolling to reach the middle of the list, going too far to the letter M, trying to come back to L, and so on.

Long dropdowns can be replaced by predictive text input fields. When the user starts typing L, the interface would propose nine countries. If they add a U — voilà! — Luxembourg it is. Four interactions instead of two, versus as many as six or seven scrolling interactions with the dropdown.

Long dropdowns are a nightmare when you’re searching for France. Predictive fields work better. Long dropdowns are a nightmare when you’re searching for France. Predictive fields work better. (Large preview)

If you need users to pick a date, forget about splitting it into a day, month and year dropdown like people are used to doing on paper forms. Replace multiple date dropdowns with a date picker. The HTML5 input type=date works in most cases. But you might have some special needs and end up building your own date picker in JavaScript, especially if you are in the booking business (hotels, cars, flights).

A double date-picker built in JavaScript makes it easy to pick arrival and departure dates with a minimum of interaction A double date-picker built in JavaScript makes it easy to pick arrival and departure dates with a minimum of interaction (Large preview)

In his article “Mobile DropDowns Revisited”, Klaus Schaefers explains how using a date-picker for arrival and departure dates made interactions 60% faster.

A date-picker, using HTML5 or JavaScript, instead of dropdowns, via Mobile DropDowns Revisited A date-picker, using HTML5 or JavaScript, instead of dropdowns, via Mobile DropDowns Revisited. (Large preview)

Let’s stick with the booking business. Suppose the user needs to add multiple travellers to their itinerary. You can **replace the dropdown *with a* stepper** to select the number of passengers. A stepper is a control that allows the user to increase and decrease values simply by tapping on + and - buttons. That tends to be faster when fewer than six persons have to be added. It’s also more intuitive. Below is an example of a stepper used in the Android-native Airbnb app to select guests, and on the mobile-optimized website of Kayak to add passengers.

A stepper is used in the Android-native Airbnb app to select guests and on the mobile-optimized website of Kayak to add passengers. A stepper is used in the Android-native Airbnb app to select guests and on the mobile-optimized website of Kayak to add passengers. (Large preview)

A final alternative to dropdowns is the list view. The options would be listed in a specific subview, as radio buttons, for instance. This is mostly how Android settings work.

In our monitoring app, when the user clicks on “notification type 1”, it opens a list view with the options. In our monitoring app, when the user clicks on “notification type 1”, it opens a list view with the options. (Large preview)

Getting Smart With Auto-Completion

If you want to decrease the interaction cost of your form, be smart. Don’t ask for information that you can auto-detect or guess based on other information users have given you. Autocomplete and prefill as much as you can.

Places and Addresses

If the user searches for a place or needs to enter an address, you can offer auto-completion to help them. As they type, an API would fill in the rest of the address for them. This also reduces errors.

You could use:

In the Algolia Place demo, as the user types, it offers suggestions and can autocomplete the field.

In France and many other countries, you can guess the city based on the area code. So, if a French user enters an area code, you could automatically auto-complete or at least propose the city. My country, Luxembourg, is small (don’t make fun of me). My area code is linked to my street. So, if I enter my area code, the form should even be able to suggest my street.

Credit Cards

Another area where auto-detection is easy is credit cards. You don’t need to ask the user what type of credit card they have. You can auto-detect this based on the initial numbers they enter. There’s even a library that can do the job for you.


A demo of the payment script that detects credit card type.
Using HTML5 Autocompletion (Autofill)

The HTML autocomplete attribute can prefill fields based on the user’s earlier inputs. This attribute has an on and off state. Some smart people have started working on a specification to make this more powerful and to extend the autocomplete attribute for form fields. The WHATWG also has an interesting list.

Chrome and other mobile browsers already support some of the extended values for credit cards and names. This means that users can prefill forms with their name and credit card data that they use on other websites.

Helping users check out faster with AutofillHelp users check out faster with Autofill (Source: Google Developers) (Large preview)

In short, when you must choose between different systems, count the number of interactions each is going to require.

Mistakes Happen: Handling Errors In Mobile Forms

The last step on our journey towards better mobile forms is handling errors and mistakes. We can try to reduce mistakes to ease the user’s cognitive load. We can also help them recover from errors, because no matter how great your form design is, mistakes happen.

Avoiding Errors While Filling The Forms

“Prevention is better than a cure,” my mother used to say. That’s also true of form design: Preventing errors will improve your mobile form’s experience.

Explicit Format Limitation

“Be conservative in what you do. Be liberal in what you accept from others.” This robustness principle can be applied to form fields as well. If possible, let the user enter data in any format.

If you think you need to limit what a user can enter in the field, start by asking yourself “why”. In the user experience field, we have a technique called “the three whys”. If the answer is “because blah blah database”, maybe it’s time to change things. For instance, why do you refuse special characters like é, à and ö in the user name field? I wrote an article explaining how rude forms are to me when I try to enter “Stéphanie” as a user name. I’m still trying to figure out a good reason for that (apart from database reasons).

If you have a good reason to require a specific format from users, state this up front. You can use HTML5 placeholders to give users a hint about what the data should look like, but again, be careful with those. You could also use all of the field description techniques explained at the beginning of this article. Finally, input masks can guide users towards the right format.

Marking Mandatory Fields (And Optional Ones)

Don’t wait for users to submit a half-completed form to tell them about required fields. If a field is mandatory, users should know about it. Marking mandatory fields with an asterix (*) and a legend has become a standard pattern for forms. The good part is that it does not take much space. The problem is that it has no semantic value, so it can cause accessibility issues if poorly coded and if you rely on people’s habits with form interaction.

You could instead explicitly mark both mandatory and optional fields with the words “required” (or “mandatory”) and “optional”. Both Baymard Institute and Luke Wroblewski agree on that. This avoids ambiguity with long forms on mobile, such as when using a scroller, proceeding with something else, then coming back and not remembering if mandatory fields were marked with an asterisk or something else.

A form with both mandatory and optional fields marked. A form with both mandatory and optional fields marked. (Large preview)

Eventually, the decision on how to mark those fields will depend on the design and length of the field and on the context. The best way to know whether you’ve made the right decision is, again, to test the form.

Sensible Defaults

Be careful about default selected options in forms. When I applied for my previous job, there was an information form. The marital status was optional. They made the first element in the dropdown, “divorced”, the default field. So, I could either not answer (because it was an optional field) and let the system believe that I was divorced, or correct this and disclose my actual marital status even if I did not want to.

Also, be careful about gender. Again, have an option for people who don’t want to disclose it; make clear why you’re asking for their gender; better yet, ask for pronouns, or don’t ask if you don’t really need to. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don’t auto-check the first choice, otherwise people won’t be able to uncheck that radio button and choose not to answer.

Should I leave the default and lie, or put the right information even I don’t want to? Should I leave the default and lie, or put the right information even I don’t want to? (Large preview)

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you’re in a Dr. Who episode, you’re not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can’t select a date in the past. When you select a return date, the default is the day after the departure date.

Booking.com’s smart defaults help users avoid mistakes. You can’t search in the past or before your arrival date. Booking.com’s smart defaults help users avoid mistakes. You can’t search in the past or before your arrival date. (Large preview)
Less Painful Password Experience

I’ve written about password-less authentication, but you can’t always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

  • When Creating An Account
    I won’t get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don’t let people guess. Tell users your password criteria up front.

    A lot of websites now show you a gauge for password strength telling you in real time what is missing. This is an interesting and excellent pattern. KLM uses it in its sign-in form: KLM sign-in form example KLM sign-in form example (Large preview) But there are still some big problems with this design.
  1. They don’t tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
  2. They limit the password’s length to 12 characters, but they never tell users how many characters are left. Sure, let’s add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
  3. What happens if, like me, you reached the 12-character limit but haven’t met all of the criteria? Well, you would just have to delete the entire password and start over again.
  4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
  5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.


TransferWise doesn’t solve my first problem in the list, but at least I can unmask while typing.
  • When Logging In
    In a login form, a mask/unmask password option would tremendously improve the user experience.
    A button to show and hide the password in a form.

    Amazon has an interesting history of iterating on passwords in its login form. It used to have a version in which you could not see the password. The next iteration allowed users to reveal it. Then, the password was revealed by default, and you could hide it. This is what is looked like in 2015:

    Showing Passwords on Log-In Screens by Luke Wroblewski (2015) Showing Passwords on Log-In Screens, Luke Wroblewski, 2015 (Large preview)

    Amazon tested the last version, and 60% people got suspicious. So, they replaced the “hide password” unchecked checkbox with a “show password” checked box. This would show the password in smaller characters, under the field, while the user typed. This is what it looks like at the time of writing this article:

    Amazon’s show and hide password functionality Amazon’s show and hide password functionality (Large preview)

    As you can see, there’s always room for improvement.

Inline Validation

If you are familiar with usability principles, you might know the Gestalt law of proximity. On mobile, avoid the summary of errors at the top of the page, with no contextual information, after the user has tapped the submit button.

Instead, error messages should be located close to the errors themselves.

An example of inline validation An example of inline validation (Large preview)
Real-Time Validation

You also don’t need to wait until users hit the submit button. You can validate fields and display feedback while the user is filling them in.

A few tips:

  • As mentioned earlier, password fields would benefit from real-time validation and feedback on each keystroke.
  • You might also want to validate user names in real time when accounts are being created, to make sure they’re available. Twitter does a good job of that.
  • Don’t validate every keystroke. Wait until the user has finished typing. (Use JavaScript blur for web forms, or just wait a few seconds to detect inactivity.)

Note: *Mihael Konjević has written a nice article on “Inline Validation in Forms: Designing the Experience.” He explains the concept of “reward early, punish late.”*

“If the user is entering the data in the field that was in a valid state, perform the validation after the data entry.”
“If the user is entering the data in the field that was in an invalid state, perform the validation during the data entry.”

Example from Keechma based on the article.

Color Matters

I’m not saying that color matters just because of my current ginger, pink and purple hair color. Color really matters in form design.

There are some conventions on the web that you don’t want to break. Non-colorblind users know that red is for errors, yellow is for warnings, and green is almost always for confirmation or success. It’s best to stick with these three colors. Red can make people anxious, though. The user might think they’ve made a really serious mistake. Using orange or yellow for error messages could cause less panic. The problem with yellow and orange is that it’s hard to find colorblind-friendly hues of them.

Colors have different connotations across countries and cultures. Be careful with them. Colors have different connotations across countries and cultures. Be careful with them. (Large preview)

Speaking of colorblindness: Color should not be the only way to convey an error message. This is an accessibility criterion.

In the example below on the left, the field with an error is in orange, and the field that has been corrected has turned green. I used a colorblind testing tool to take the screenshot in the middle: You can’t distinguish between the default gray border and the green one anymore. Adding some icons in the last screenshot ensures that the error messages are conveyed to colorblind people.

Color should not be the only way to convey error messages. The colorblind simulation in the middle shows that the green border cannot be seen by a colorblind person. Color should not be the only way to convey error messages. The colorblind simulation in the middle shows that the green border cannot be seen by a colorblind person. (Large preview)

Recovering From Errors: Writing User-Friendly Error Messages

At this point, we’ve done everything we can to help users fill our forms and avoid errors. But sometimes, despite our best effort, mistakes happen. It’s time to figure out how to help users recover from those mistakes.

First, remember: Don’t hijack control of the system. If a problem isn’t critical, the user should be able to continue interacting with as much of the rest of the interface as possible. Avoid those JavaScript alert error message and modals that blocks users whenever possible. Also, if your form needs some permission, request it in the flow of use. If permission is not granted, do not consider this an error because it is not. Be careful about the copy you use here.

You’re Not A Robot, And Neither Are Your Users

Robots are cool, I know. But you’re not a robot, and neither are your users. Yet so many error messages are still so poorly written. Here are a few tips when it comes to human-friendly error messages:

  • Never show a raw error message, like “An error of type 2393 has occurred. Server could not complete the operation.” Instead, explain what happened in human language and why it happened.
  • Never show a dead-end error message, like “An error has occurred.” Instead suggest ways to recover from the error. Write actionable copy.
  • Never show a vague error message, like “A server with the specified hostname could not be found”, with a “Try again” button. Instead, make error messages informative and consistent. Please don’t sound like a robot.
  • Don’t assume that people know the context of a message. Your users are not tech-savvy geeks. Instead, explain to them in plain language, without technical jargon, how to recover from this error.
Examples of non-human-friendly error messages. Eek! Examples of non-human-friendly error messages. Eek! (Large preview)
Beware The Language You Use In Messages

Whatever you write, avoid making people feel stupid about a mistake. If possible, leave out negative words; they tend to scare people and make them even more anxious. Use a courteous, positive, affirming tone instead.

Don’t blame users for mistakes; blame the system instead. The system won’t hold a grudge, I promise. Shift the user’s attention to how the system could not process the action, and explain to them how to find a solution.

A little trick is to read your own message out loud. It will help you hear whether it works or is too harsh or too casual, etc.

You could also get creative with error messages and incorporate imagery and humour to make them less threatening. This will really depend on your brand’s identity and tone, though.

To help you write better error message, I suggest you read the following:

Time To Submit The Form

The user has filled in the form, there are no more errors, and everything looks good. Finally, it’s time to submit the form!

The first rule is, don’t mask the submit button. Seriously! I wonder what twisted mind came up with this idea, but I’ve seen it in some forms. The submit button would be displayed only once all required fields were filled in without any errors. It’s disturbing for the user to wonder whether something is wrong or the form’s button has not loaded or the website is broken and so on.

If you don’t want users to be able to hit the submit button if there’s missing mandatory fields or there are validation errors, use the disabled HTML attribute on the submit input. You will need to re-enable the button using JavaScript once the form is valid and ready for submission.

Do not hide the submit button. Instead, deactivate it until users have filled in the required information. Do not hide the submit button. Instead, deactivate it until users have filled in the required information. (Large preview)

If you have a primary and secondary call to action, use color, size and styling to show the hierarchy.

Example of primary and secondary actions Example of primary and secondary actions (Large preview)

If are wondering whether the confirmation button should come before or after the cancellation button, so am I (and a lot of other people). If you are building a native app, stick to the OS guidelines. It’s become particularly fun since Android changed the button positions in its fourth version. On the web, it’s more complicated because there are no real guidelines. Regardless of the OS, here are some general guidelines for mobile-optimized submit buttons:

  • Give the call to action descriptive, actionable verbs.
  • Provide visual feedback when the user taps it.
  • If you have two buttons, make the primary action stand out.
  • Unless you’re working on a very specific back-office enterprise form (in which case, you’ll have a lot of challenges optimizing for mobile), avoid a reset button. Users might confuse it with the submit button and will lose all of their data by accident.

Conclusion

In this first part, I’ve discussed a lot of little techniques to take your form to the next level and help users fill it in. Some of these general guidelines and mobile best practices might not work 100% of the time — that’s the catch with best practices. So, always test your forms on real users and real devices, and adapt the guidelines to your users’ specific needs and experience.

Also, do some regression and automated functional testing — again, on real devices. Chrome’s mobile emulator won’t be enough to test touch-optimized forms. I say this because I had launched an e-commerce website with a search form that didn’t work on mobile. We only did automated testing using an emulator. Here is what happened. The search form was hidden under a search icon. You could tap on the button, which opened a box with the search field. It worked by emulating a mouse hover as a touch event. We tested tapping on the button, and it opened the box. Nobody tried to launch a search. So, nobody (not even the client) saw that the search field disappeared as soon as users tried to interact with it. What happened? When the input element got focus, the button lost the hover state, so it closed the box with the field. Automated testing was not able to catch this because the input was not losing focus. So, we launched an e-commerce website without search functionality on mobile. Not a super experience.

In the second part of this series, we will see more advanced mobile-specific techniques. We will see how to use cool HTML5 features to format fields and how to use mobile capabilities to take the mobile user experience to the next level.

Smashing Editorial(lf, ra, al, il)

August 17 2018

Designing For Micro-Moments

Designing For Micro-Moments

Designing For Micro-Moments

Suzanna Scacca
2018-08-17T13:50:09+02:002018-08-17T12:41:01+00:00

A couple of years ago, Google announced a new mobile-first initiative it wanted web designers and marketers to pick up on. This was our introduction to micro-moments.

These are not to be confused with micro-interactions, which are miniscule engagements websites have with visitors when they "touch" key points of the interface. A mouse changes its appearance when a user hovers over a clickable element. A display error appears after a field is incorrectly populated. A checkbox briefly enlarges and changes color after it’s been ticked off. These are micro-interactions.

A micro-moment, however, originates with your visitor. In Myriam Jessier’s "Things Designers Should Know About SEO In 2018", she sums up Google’s four micro-moments:

  1. “I want to know.”
  2. “I want to go.”
  3. “I want to do.”
  4. “I want to buy.”

Basically, these are four key moments in every consumer’s life when they decide to pick up their mobile device for a specific purpose. As such, it’s your job to know how to specifically design for these micro-moments.

Recommended reading: What You Need To Know To Increase Mobile Checkout Conversions

How You Should Be Designing For Micro-Moments

When a visitor arrives at a mobile website (or app), they’ve come with a clear motivation:

  1. “I want to know.”
  2. “I want to go.”
  3. “I want to do.”
  4. “I want to buy.”

Seems pretty simple, right? However, as Google launched this initiative a couple of years ago, its had time to quietly observe users in these micro-moments as well as the websites that have most aptly responded to them. As you will soon see, consumers have incredibly high expectations for what the mobile web can do for them. Basically, they want you to be a mind reader and anticipate their every need (and even their location) without them having to say a word.

Is your pattern library up to date today? Alla Kholmatova has just finished a fully fledged book on Design Systems and how to get them right. With common traps, gotchas and the lessons she learned. Hardcover, eBook. Just sayin'.

Table of Contents →

Is that intimidating? It shouldn’t be. You already have all the information you’d ever need to answer that question.

Here is how you should be designing your mobile website to respond to and draw in consumers as they experience these micro-moments:

1. Start With The Data

Google Analytics will help you decipher where they’re spending the most time productively on your website.

Google Analytics Behavior breakdowns An example of Google Analytics’ visitor behavior breakdowns. (Source: Google Analytics) (Large preview)

Google Search Console will tell you which keywords are most effective in driving high-quality leads to the site.

Google Search Console keywords An example listing of keywords and associated clicks and impressions for a website. (Source: Google Search Console) (Large preview)

Once you know where exactly visitors see the greatest value in your product, you can then turn to third-party tools like Answer the Public to give you some insights into what relevant questions your users may be asking about you.

Answer the Public sample answers An example of how Answer the Public provides micro-moment answers. (Source: Answer the Public) (Large preview)

Ultimately, this data needs to tell you all about your customers’ journey before they ever reach you. What exactly was the question that triggered them to pick up their smartphone and do that search? If you can identify those micro-moments, you can start using various design elements to respond to these questions.

2. Respond With Immediacy

According to Google:

People are searching at the exact moment they need something and are looking for places that can meet their immediate need. In other words, when making these on-the-spot decisions, they are more loyal to their need than to any particular place.

Although we’ve heard a lot about customer loyalty to brands in the past, it’s interesting to get Google’s take on this matter.

While consumers may indeed still remain loyal to brands that take very good care of them and produce a high-quality product nearly 100% of the time, this opportunity to steal attention from those customers in one of their micro-moments is real. Do that enough times and your brand and website could realistically win that customer over so long as you are there every time they go searching to fill that need.

One of the ways you can do this is by providing users with instant solutions. Is your business open now? Can you mail out that new product same-day? Will there be an open table at your restaurant tonight? Answer that immediately and you could find conversions increase dramatically.

Take the Delaware State Fair website, for example.

Delaware State Fair gives users what they need to know The top of the Delaware State Fair home page gives users easy access to everything they want to know and do. (Source: Delaware State Fair) (Large preview)

Look at the top of the homepage. There are the dates of the fair, which probably answer one of the most commonly searched questions. There is a link to the concert lineup as well as calendar, which answers anything people would want to know about special events they might want to go to. And then there’s a button to buy tickets right away. It’s all right there.

Office Depot is a company that also explicitly addresses immediate needs:

Office Depot includes time-driven design elements The Office Depot mobile site uses a variety of time-driven design elements to satisfy visitors’ needs. (Source: Office Depot) (Large preview)

As you can see in the example above, Office Depot uses a number of design tactics and elements to play into this need for immediacy.

  • There is a search bar at the very top. Consumers don’t have to even bother with navigation or scrolling through pages if they don’t want to/have the time to.
  • You’ll also see that the closest store’s hours are posted and boldly tell me how quickly I can have any products available in store.
  • Finally, you have the promotional categories for upcoming needs for parents that are about to send kids back to school.

Another website is Universal Studios Orlando; it does a great job sparing mobile users the trouble of sifting through irrelevant information and instead gets them to exactly what they need:

Universal Studios provides immediate research and booking options Universal Studios includes immediate options for research and booking on the home page and navigation. (Source: Universal Studios) (Large preview)

Aside from a single banner at the top of the home page, the Universal Studios website design gives visitors exactly what they want right away. The navigation includes only the most pertinent links to information and booking as does this succinct section on the home page. There’s really no time to waste when the options are so clear.

And here is one final example of a website that deals in immediacy, albeit with a more subtle design technique: Nordstrom:

Nordstrom uses color for immediacy Nordstrom appeals to immediacy with this one subtle trick. (Source: Nordstrom) (Large preview)

As you can see, this is a pretty typical e-commerce product page. However, there’s one key difference: Nordstrom is subtly calling attention to its Anniversary Sale and the main reason why there is a significant price drop for this purchase. Rather than use an obtrusive pop-up to announce the sale and pester users to shop, it’s made the price change directly on the page and drawn attention to it with the highlighted text.

3. Respond With Relevant Content

According to Google:

Not only have mobile searches for ‘best’ grown over 80% in the past two years, but searches for ‘best’ have shown higher growth among ‘low-consideration’ products than ‘high-consideration’ products. In other words, we’re all becoming research-obsessed, even about the small stuff.

We understand that the opinions of family, friends, and colleagues matter greatly in the minds of consumers. But as more and more of them to turn the web to make their purchases, it means being open to trusting other opinions online as well — ones that may be more conveniently expressed from a company’s website, from an influencer’s blog, or from social media.

Wherever those words of wisdom happen to come from, it’s important to take Google’s research to heart. With so many consumers now obsessed with this idea of having the best of everything and being able to get it in a pinch, your website needs to be the answer to that question.

But that’s the tricky part. According to Google, it’s not as simple as being a dog food manufacturer and configuring your site to be the answer to:

“Best Dog Food”

Consumers experience these micro-moments at a granular level. Sure, there may be some who think, “What is the best dog food?” But isn’t it more likely that question would be more specific in nature? For instance:

  • Best puppy food?
  • Best grain-free dog food?
  • Best vegan dog food?

Let's take a look at Google, for example. Here’s a variety of searches for a singular “best of” concept:

Best searches example from Google Example of the variety in “Best” searches in Google. (Source: Google) (Large preview)

As you can see, it goes beyond the basic questions. Through your design and your content, you must be ready to answer the most relevant questions your users have about your product or service.

With content, you’ll be able to answer many of the “I want to know” questions that are related to the brand with things like:

  • Informational pages regarding services and products.
  • Whitepapers, ebooks, case studies, reports, and other long-form content that provide heavily researched answers on related matters.
  • Blog posts, vlogs, podcasts, and other shorter content that can dabble more in appealing to the emotions of consumers.
  • Tutorials and guides that directly answer questions that consumers are asking.

As far as the design piece is concerned, it’s your responsibility to highlight these pages, so visitors don’t have to dig through various parts or layers of the site (like the footer or secondary navigation) to find their answers.

Google told them it was here, so it’s your job to get them right to it.

The navigation will play a big part in this, as evidenced by Globus Journeys:

Globus answers users in the navigation Globus Journeys provides answers to micro-moments in the navigation. (Source: Globus Journeys) (Large preview)

As you can see in this example, Globus Journeys answers many of those micro-moments right within the navigation: tips on touring (Touring 101), tips on travel best practices (Travel Tips), deals available for travel (Deals & Offers), etc.

Another way to use navigational design to inform visitors on what they’ll learn/know from this experience can take place on the blog. Salesforce has an interesting example of this:

Salesforce has informative blog navigation Salesforce includes a navigation menu for the blog. (Source: Salesforce) (Large preview)

There is the standard navigation for the Salesforce website, and then there is the navigation that’s specific to the Salesforce blog. This gives you — as the designer and planner of the site’s layout — a chance to better and more clearly organize content found within it. So, when visitors show up and want to know tips specific to one of those categories, it doesn’t require random searches or (even worse) endless scrolling through a full blog feed.

Another way you can more quickly and thoroughly inform visitors on topics of interest to them is by using strategically placed sections within blog posts.

While you likely won’t have anything to do with the writing of a website’s blog content, you will have control over its layout and formatting. The first thing you can do to expedite the knowledge acquisition process is by using callouts to detail and link to the various sections covered on the page as Be Brain Fit does:

Be Brain Fit has an index of topics Be Brain Fit calls out a linkable index of topics from the blog post. (Source: Be Brain Fit) (Large preview)

Of course, the post itself is easy to scan, so readers could guide themselves to the most relevant parts. However, by placing this towards the top of the piece, you’re enabling them to get right to the information they seek.

I’m also going to suggest that pop-ups would be helpful in this matter.

I know, I know. Mobile pop-ups can be annoying, but not when they’re used properly as Fit Small Business has done here.

Fit Small Business uses a helpful pop-up Fit Small Business not only provides all the information needed, but also offers an alternative solution to what they seek. (Source: Fit Small Business) (Large preview)

I encountered this blog post after doing a search for the best way to create a Facebook page. This was one of the links on the first SERP. I was actually quite pleased with the post as a whole. It broke it up into easy-to-follow steps, attractive and informative visuals, and got me the answer I needed.

However, I was especially pleased to see the bottom banner pop-up after I finished getting through the post. Not only has Fit Small Business attempted to reach its audience by providing helpful content, but it’s also providing an alternative solution to anyone who got here and realized, “Eh, I really don’t want to bother with this on my own."

4. Respond With Geotargeting

According to Google:

Looking for something nearby — a coffee shop, noodle restaurant, shoe store — is one of the most common searches we do. In fact, nearly one-third of all mobile searches are related to location.

Here’s the thing though: users aren’t using “near me” qualifiers as much anymore.

Near me qualifiers dropping in use Google demonstrates how location qualifiers are decreasing in use. (Source: Google) (Large preview)

According to Google, this is because many consumers now assume that search engines, websites, and mobile apps are tracking this sort of information already. They expect that if they search for something like “dog food,” Google will automatically serve them the most relevant results — and that includes taking into account location proximity.

In Google’s research, it found that about two-thirds of mobile consumers are more likely to buy something from a website or app if information is geographically personalized. There are a plethora of ways to communicate this local-friendliness to visitors — through the copy, through various design elements, and even photos.

Google is a pioneer in this space and so I want to give it a special shout-out in this section for what it does with search results:

Google auto-populates search questions. Google’s auto-populated search results aren’t just for Google. (Source: Google) (Large preview)

The biggest thing to take away from here is the fact that Google provides its users with auto-populated search recommendations. These are based on the users’ geography, behavior, history, as well as what Google knows about the query itself. As you can see here, it expands on Baltimore to provide more specific results based on the area of the city in which the user wants to drink.

With AI-assisted search functionality, any website can offer this same level of smart search for its users.

Of course, you first need to get access to visitors’ geographic data before you can provide them with these kinds of smart and geographically relevant results. One way to do this is to require them to sign in and fill out a profile with these details. Another way, however, is by serving them with this geotargeting request as Best Buy has done:

Best Buy asks for geo access Best Buy requests for access to users’ geographic location. (Source: Best Buy) (Large preview)

Once you have access to a visitors’ current location, however, you can start providing them with information that helps them with the “I want to go”, “I want to do”, and the “I want to buy” micro-moments that caused them to reach for the phone in the first place.

Here is what the Best Buy website shows me after I granted it permission:

Best Buy provides geo-specific details Best Buy uses its visitors’ location to provide helpful in-store visit details. (Source: Best Buy) (Large preview)

The top of the page now displays the nearest location to me as well as opening hours. As I peruse the rest of the site, I will receive relevant information regarding in-store product availability, buy-online-pick-up-in-store options, and so on. This is a really great option for businesses with a sales website and brick-and-mortar location that want to merge the two experiences.

You could also benefit from using this on websites that offer services, appointments, and reservations. Here is an example of what The Palm Restaurant does with my information:

The Palm Restaurant geotargeting The Palm Restaurant streamlines the reservation process with geotargeting. (Source: The Palm Restaurant) (Large preview)

To start, it uses my information to let me know right away if there even is a location close to me. Philadelphia isn’t too far, but it’s still nice to have the address fully displayed so I can make up my mind about whether I want to dine there. And, if I do, I can choose the “Reservations” button above it.

What’s especially nice about this is that the reservation form is pre-populated:

The Palm Restaurant streamlines conversion The Palm pre-populates its reservation form based on user information. (Source: The Palm Restaurant) (Large preview)

As you can see, it’s used a mixture of my geographic location along with the most popular reservation types (i.e. two people at 7 p.m.) to pre-populate the form. This saves me, as the user, time in filling it out and making my reservation.

5. Respond With Convenience

According to Google:

Every day, people are becoming more reliant on their smartphones to help make last-minute purchases or spur-of-the-moment decisions. In fact, smartphone users are 50% more likely to expect to purchase something immediately while using their smartphone compared to a year ago.

Recently, I wrote a post about what you need to know to increase mobile checkout conversions. The underlying message was that mobile consumers have certain expectations that need to be met if you intend on converting them there (as opposed to switching back to desktop).

  • Convenience in getting the information they want is one of them.
  • Speed in getting to and through checkout is another.
  • Handling their contact and payment information securely is the final piece.

Clearly, web designers are doing something right as over half of smartphone users reach for their phone to buy something and subsequently do. But it can’t stop with the 10 tips offered in that article. You need to be able to predict what they’re going to purchase and what exactly they want to do when you catch them in those exact micro-moments.

Let’s use UPack as one example.

UPack shows a price quote form first thing UPack includes a price quote form at the very top of the website. (Source: UPack) (Large preview)

At the very top of every page is a short price quote form that asks only the most pertinent details they need in order to provide a quote to interested customers. By anticipating that’s what they’re looking to do when they visit a moving company’s website, UPack likely experiences very high conversion rates.

However, if someone should arrive at this form and wonder, “Should I even bother with a quote from UPack?”, they’ve provided an answer to that on the next step down on the home page:

UPack’s explainer graphic reaches users on the fence UPack uses an explainer graphic to sell the value of its service right away. (Source: UPack) (Large preview)

This explainer graphic is simple. It includes four points and shows how exactly someone uses the UPack service to move their home from one destination to another. When someone arrives there with the intention of getting help with their move, UPack has already made it all the more simple in just one scroll and two panels of the home page.

Then, you have a company like HostGator that doesn’t waste any time at all:

HostGator provides shortcut to purchase HostGator’s home page includes smart design callouts that sum up its services. (Source: HostGator) (Large preview)

If someone shows up on a web hosting company’s website — especially one that is well known as they are — of course they know what they want to do. Now, they could hop into the navigation and dig deeper into the various hosting plans (which some may do). However, HostGator is probably hoping to appeal to two specific audiences with these “Buy Now!” callouts on the home page:

  • The web developer who knows exactly which plan he or she needs, and doesn’t need a full page to explain the benefits to him.
  • The small business owner who doesn’t know a thing about web hosting, but trusts HostGator’s good name and just wants to get their web hosting purchases ASAP.

This is a really good choice of design techniques if you know that a good portion of your audience will be immediately ready to buy upon entering the site. If they don’t have to click through to another site, don’t make them do it.

And, of course, CTAs, in general, are an important element to use when designing for micro-moments. When they’re designed well — colorful, large, well-labeled — you’re essentially giving your users a shortcut to conversion.

BarkBox uses a number of these right on its home page:

BarkBox’s CTA shortcuts BarkBox has a number of CTA shortcuts available on its website. (Source: BarkBox) (Large preview)

Since the brand is particularly well-known among dog owners, this is a good move. While there are some people who enjoy scrolling through the site to see the funny dog pictures and find out more about what’s in this month’s BarkBox, if they’ve arrived here on mobile, they shouldn’t have to wait to subscribe. BarkBox provides those shortcuts in a number of locations, ensuring there’s no friction between its customers and their goals.

Wrapping Up

It’s pretty amazing to watch the web change so quickly as consumers become more trusting of their mobile devices. Now, nearly two years after Google first began recommending that we design with micro-moments in mind, it appears that these suggestions have really paid off.

Designing for micro-moments gives us the opportunity to more effectively reach consumers in their moment of need. This, consequently, means reaching consumers who are in a more purchase-intent mindset as opposed to ones casually browsing the web. If you can use your data and design to actively reach consumers in their micro-moments, you can effectively increase your mobile site’s conversion rate in the years to come.

Smashing Editorial(lf, ra, yk, il)

Monthly Web Development Update 8/2018: The Cost Of JavaScript, Ethics In Open Source, And QUIC

Monthly Web Development Update 8/2018: The Cost Of JavaScript, Ethics In Open Source, And QUIC

Monthly Web Development Update 8/2018: The Cost Of JavaScript, Ethics In Open Source, And QUIC

Anselm Hannemann
2018-08-17T11:57:10+02:002018-08-17T12:41:01+00:00

Building technology and software has become a very responsible job. People trust the products we create, and they can have a significant impact on their lives, too. Considering this, we not only need to think about inclusive solutions, but also stand up and advocate for ethics, reliability, and security. It’s a position that gives us power.

Eric Meyer published an article elaborating the problems which an HTTPS-only web is bringing along. In it, he reveals that developing countries suffer a lot from this development as they often have bad internet connections and, due to the encryption, they now experience more website errors than before. Ben Werdmüller jumped in and published the article “Stop building for San Francisco” in which he points out one of the biggest problems we have as developers: We use privileged hardware and infrastructure. We build experiences using the latest iPhones, Macbooks with Gigabit or fast 4G connections but never consider that most people we’re building for use devices and infrastructures that are far from being that well-equipped. Making the web more secure is a great idea, beyond question, but we should also keep in mind the consequences that the latest tech and our design decisions might have for others.

News

With so much happening on the web, what should we really pay attention to? At SmashingConf New York 2018 🇺🇸 we’ll explore everything from PWAs, font loading best practices, web performance and eCommerce UX optimization, to refactoring CSS, design workflows and convincing your clients. With Sarah Drasner, Dan Mall, Sara Soueidan, Jason Grigsby, and many other speakers. Oct 23–24.

Check the speakers →

General

UI/UX

  • Ethics for Design is a project where twelve designers and researchers from eight European cities discuss the, sometimes harmful, impact of design on our societies and what designers can do to work for the good of all and not just a few.

Tooling

  • Prashant Palikhe wrote a long story about the art of debugging with Chrome’s Developer Tools, which I can highly recommend as it’s a very complete reference to get to know the developer tools of a browser. If you use another browser, that’s not a big problem as most tools are quite similar.
  • WebP is an image format with a couple of nice features and likely one of the best-known new formats besides the common JPEG/PNG ones. However, creating WebP images can still be a challenge, so Jeremy Wagner wrote a guide on how to convert images to WebP.
  • Douglas Creager introduces the new Network Error Logging which allows you to instruct user agents to collect the same set of information that would appear in your server logs.
  • Many of us are addicted to communication tools like Slack. The folks from Wildbit decided to shut down Slack for a week — with a significant effect on how they work. An interesting case study about how we tend to get too comfortable with a useful tool and don’t use it as we should anymore. From time to time, it’s important to reset our minds.
  • Dennis Reimann published the first stable version of UIEngine, a workbench for UI-driven development.

Security

  • A new Observer is around: The ReportingObserver API lets you know when your site uses a deprecated API or runs into a browser intervention. So far, it’s available in Chrome 69. You could easily use this to send errors that previously were only available in the Console to your backend or error handling service.

Web Performance

HTTP request over QUICA QUIC handshake only takes a single round-trip between client and server to complete, whereas TCP and TLS usually need two. (Image source)

HTML & SVG

Accessibility

JavaScript

  • One year after they introduced their Progressive Web App, Zack Argyle from the Pinterest engineering team takes a look back. It’s important to note why they decided to build a PWA: “Our mobile web experience for people in low-bandwidth environments and limited data plans was not good”. But the results for them are amazing to see.
  • Philip Walton introduces the new Page Lifecycle API which helps us determine page states in the browser more easily via events, such as the page being in the background (not visible), active, frozen or even terminated.
  • Whoops, you all know eval() in JavaScript is bad, right? That’s why we usually forbid its usage in Content Security Policies. But Remy Sharp reminds us that there’s a line of code which is equally bad for security.
  • Addy Osmani researched the cost of JavaScript in 2018 and now shares evidence that every byte of JavaScript is still the most expensive resource we can send to mobile phones because it can delay interactivity significantly. This is a problem especially for not so capable phones that are widely used outside the tech industry.
  • Hidde de Vries explains how we can make page titles accessible in JavaScript Single Page Application.
The Cost Of JavaScript In 2018What’s the real cost of JavaScript? One of the findings from Addy Osmani’s research: It takes a low-end 2018 phone 32 seconds longer than an iPhone 8 to process JavaScript for CNN.com. (Image source)

CSS

Work & Life

Going Beyond…

  • Tobias van Schneider wrote about why the Sagmeister-Walsh studio is so successful by staying small and why dreaming big but staying small is so important for creative thinking.
  • Ben Werdmüller shares his thoughts on how different it has become to start a business when you’re, for example, in San Francisco. This is a story where $117,000 are considered a “low income” in San Francisco and how this limits ideas.
  • Jeremy Nagel makes us think about the impact of our open-source code: As developers we tend to believe that making our code freely available is an amazing move but we forget that we make it available to bad players as well — to coal miners, to pollution-contributing companies, to those who use people to get rich while mistreating them, to those who rip you off indirectly. It’s not that you can’t do anything about it; you have to be aware of these issues and apply a better license or add a dedicated statement to your code.
  • India has a big plastic waste problem. Since a couple of months, a couple of fishers don’t ignore the plastic problem anymore but collect all the waste in their nets instead, and bring it back to the shore where it’s used to build roads. A great idea of making use of trash efficiently.
Smashing Editorial(cm)

August 15 2018

Scroll Bouncing On Your Websites

Scroll Bouncing On Your Websites

Scroll Bouncing On Your Websites

William Lim
2018-08-15T14:00:49+02:002018-08-16T10:20:18+00:00

Scroll bouncing (also sometimes referred to as scroll ‘rubber-banding’, or ‘elastic scrolling’) is often used to refer to the effect you see when you scroll to the very top of a page or HTML element, or to the bottom of a page or element, on a device using a touchscreen or a trackpad, and empty space can be seen for a moment before the element or page springs back and aligns itself back to its top/bottom (when you release your touch/fingers). You can see a similar effect happen in CSS scroll-snapping between elements.

However, this article focuses on scroll bouncing when you scroll to the very top or very bottom of a web page. In other words, when the scrollport has reached its scroll boundary.

Collecting Data, The Powerful Way

Did you know that CSS can be used for collecting statistics? Indeed, there's even a CSS-only approach for tracking UI interactions using Google Analytics. Read article →

A good understanding of scroll bouncing is very useful as it will help you to decide how you build your websites and how you want the page to scroll.

Scroll bouncing is undesirable if you don’t want to see fixed elements on a page move. Some examples include: when you want a header or footer to be fixed in a certain position, or if you want any other element such as a menu to be fixed, or if you want the page to scroll-snap at certain positions on scroll and you do not want any additional scrolling to occur at the very top or bottom of the page which will confuse visitors to your website. This article will propose some solutions to the problems faced when dealing with scroll bouncing at the very top or bottom of a web page.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features →

My First Encounter With The Effect

I first noticed this effect when I was updating a website that I built a long time ago. You can view the website here. The footer at the bottom of the page was supposed to be fixed in its position at the bottom of the page and not move at all. At the same time, you were supposed to be able to scroll up and down through the main contents of the page. Ideally, it would work like this:

Scroll bouncing in Firefox on macOSScroll bouncing in Firefox on macOS. (Large preview)

It currently works this way in Firefox or on any browser on a device without a touchscreen or trackpad. However, at that time, I was using Chrome on a MacBook. I was scrolling to the bottom of the page using a trackpad when I discovered that my website was not working correctly. You can see what happened here:

Scroll bouncing in Chrome on macOSScroll bouncing in Chrome on macOS. (Large preview)

Oh no! This was not what was supposed to happen! I had set the footer's position to be at the bottom of the page by setting its CSS position property to have a value of fixed. This is also a good time to revisit what position: fixed; is. According to the CSS 2.1 Specification, when a “box” (in this case, the dark blue footer) is fixed, it is “fixed with respect to the viewport and does not move when scrolled.” What this means is that the footer was not supposed to move when you scroll up and down the page. This was what worried me when I saw what was happening on Chrome.

To make this article more complete, I’ll show you how the page scrolls on both Mobile Edge, Mobile Safari and Desktop Safari below. This is different to what happens in scrolling on Firefox and Chrome. I hope this gives you a better understanding of how the exact same code currently works in different ways. It is currently a challenge to develop scrolling that works in the same way across different web browsers.

Scroll bouncing in Safari on macOS. A similar effect can be seen for Edge and Safari on iOSScroll bouncing in Safari on macOS. A similar effect can be seen for Edge and Safari on iOS. (Large preview)

Searching For A Solution

One of my first thoughts was that there would be an easy and a quick way to fix this issue on all browsers. What this means is that I thought that I could find a solution that would take a few lines of CSS code and that no JavaScript would be involved. Therefore, one of the first things I did, was to try to achieve this. The browsers I used for testing included Chrome, Firefox and Safari on macOS and Windows 10, and Edge and Safari on iOS. The versions of these browsers were the latest at the time of writing this article (2018).

HTML And CSS Only Solutions

Absolute And Relative Positioning

One of the first things I tried, was to use absolute and relative positioning to position the footer because I was used to building footers like this. The idea would be to set my web page to 100% height so that the footer is always at the bottom of the page with a fixed height, whilst the content takes up 100% minus the height of the footer and you can scroll through that. Alternatively, you can set a padding-bottom instead of using calc and set the body-container height to 100% so that the contents of the application do not overlap with the footer. The CSS code looked something like this:

html {
  width: 100%;
  height: 100%;
  overflow: hidden;
  position: relative;
}

body {
  width: 100%;
  margin: 0;
  font-family: sans-serif;
  height: 100%;
  overflow: hidden;
}

.body-container {
  height: calc(100% - 100px);
  overflow: auto;
}

.color-picker-main-container {
  width: 100%;
  font-size: 22px;
  padding-bottom: 10px;
}

footer {
  position: absolute;
  bottom: 0;
  height: 100px;
  width: 100%;
}

This solution works in almost the same way as the original solution (which was just position: fixed;). One advantage of this solution compared to that is that the scroll is not for the entire page, but for just the contents of the page without the footer. The biggest problem with this method is that on Mobile Safari, both the footer and the contents of the application move at the same time. This makes this approach very problematic when scrolling quickly:

Absolute and Relative PositioningAbsolute and Relative Positioning.

Another effect that I did not want was difficult to notice at first, and I only realized that it was happening after trying out more solutions. This was that it was slightly slower to scroll through the contents of my application. Because we are setting our scroll container’s height to 100% of itself, this hinders flick/momentum-based scrolling on iOS. If that 100% height is shorter (for example, when a 100% height of 2000px becomes a 100% height of 900px), the momentum-based scrolling gets worse. Flick/momentum-based scrolling happens when you flick on the surface of a touchscreen with your fingers and the page scrolls by itself. In my case, I wanted momentum-based scrolling to occur so that users could scroll quickly, so I stayed away from solutions that set a height of 100%.

Other Attempts

One of the solutions suggested on the web, and that I tried to use on my code, is shown below as an example.

html {
  width: 100%;
  position: fixed;
  overflow: hidden;
}

body {
  width: 100%;
  margin: 0;
  font-family: sans-serif;
  position: fixed;
  overflow: hidden;
}

.body-container {
  width: 100vw;
  height: calc(100vh - 100px);
  overflow-y: auto;
  -webkit-overflow-scrolling: touch;
}

.color-picker-main-container {
  width: 100%;
  font-size: 22px;
  padding-bottom: 10px;
}

footer {
  position: fixed;
  bottom: 0;
  height: 100px;
  width: 100%;
}

This code works on Chrome and Firefox on macOS the same way as the previous solution. An advantage of this method is that scroll is not restricted to 100% height, so momentum-based scrolling works properly. On Safari, however, the footer disappears:

Missing Footer on macOS SafariMissing Footer on macOS Safari. (Large preview)

On iOS Safari, the footer becomes shorter, and there is an extra transparent (or white) gap at the bottom. Also, the ability to scroll through the page is lost after you scroll to the very bottom. You can see the white gap below the footer here:

Shorter Footer on iOS SafariShorter Footer on iOS Safari.

One interesting line of code you might see a lot is: -webkit-overflow-scrolling: touch;. The idea behind this is that it allows momentum-based scrolling for a given element. This property is described as “non-standard” and as “not on a standard track” in MDN documentation. It shows up as an “Invalid property value” under inspection in Firefox and Chrome, and it doesn’t appear as a property on Desktop Safari. I didn’t use this CSS property in the end.

To show another example of a solution you may encounter and a different outcome I found, I also tried the code below:

html {
  position: fixed;
  height: 100%;
  overflow: hidden;
}

body {
  font-family: sans-serif;
  margin: 0;
  width: 100vw; 
  height: 100vh;
  overflow-y: auto;
  overflow-x: hidden;
  -webkit-overflow-scrolling: touch;
}

.color-picker-main-container {
  width: 100%;
  font-size: 22px;
  padding-bottom: 110px;
}

footer {
  position: fixed;
}

This actually works well across the different desktop browsers, momentum-based scrolling still works, and the footer is fixed at the bottom and does not move on desktop web browsers. Perhaps the most problematic part of this solution (and what makes it unique) is that, on iOS Safari the footer always shakes and distorts very slightly and you can see the content below it whenever you scroll.

Solutions With JavaScript

After trying out some initial solutions using just HTML and CSS, I gave some JavaScript solutions a try. I would like to add that this is something that I do not recommend you to do and would be better to avoid doing. From my experience, there are usually more elegant and concise solutions using just HTML and CSS. However, I had already spent a lot of time trying out the other solutions, I thought that it wouldn’t hurt to quickly see if there were some alternative solutions that used JavaScript.

Touch Events

One approach of solving the issue of scroll bouncing is by preventing the touchmove or touchstart events on the window or document. The idea behind this is that the touch events on the overall window are prevented, whilst the touch events on the content you want to scroll through are allowed. An example of code like this is shown below:

// Prevents window from moving on touch on older browsers.
window.addEventListener('touchmove', function (event) {
  event.preventDefault()
}, false)

// Allows content to move on touch.
document.querySelector('.body-container').addEventListener('touchmove', function (event) {
  event.stopPropagation()
}, false)

I tried many variations of this code to try to get the scroll to work properly. Preventing touchmove on the window made no difference. Using document made no difference. I also tried to use both touchstart and touchmove to control the scrolling, but these two methods also made no difference. I learned that you can no longer call event.preventDefault() this way for performance reasons. You have to set the passive option to false in the event listener:

// Prevents window from moving on touch on newer browsers.
window.addEventListener('touchmove', function (event) {
  event.preventDefault()
}, {passive: false})

Libraries

You may come across a library called “iNoBounce” that was built to “stop your iOS webapp from bouncing around when scrolling.” One thing to note when using this library right now to solve the problem I’ve described in this article is that it needs you to use -webkit-overflow-scrolling. Another thing to note is that the more concise solution I ended up with (which is described later) does a similar thing as it on iOS. You can test this yourself by looking at the examples in its GitHub Repository, and comparing that to the solution I ended up with.

Overscroll Behavior

After trying out all of these solutions, I found out about the CSS property overscroll-behavior. The overscroll-behavior CSS property was implemented in Chrome 63 on December 2017, and in Firefox 59 on March 2018. This property, as described in MDN documentation, “allows you to control the browser's scroll overflow behavior — what happens when the boundary of a scrolling area is reached.” This was the solution that I ended up using.

All I had to do was set overscroll-behavior to none in the body of my website and I could leave the footer’s position as fixed. Even though momentum-based scrolling applied to the whole page, rather than the contents without the footer, this solution was good enough for me and fulfilled all of my requirements at that point in time, and my footer no longer bounced unexpectedly on Chrome. It is perhaps useful to note that Edge has this property flagged as under development now. overscroll-behavior can be seen as an enhancement if browsers do not support it yet.

Conclusion

If you don’t want your fixed headers or footers to bounce around on your web pages, you can now use the overscroll-behavior CSS property.

Despite the fact that this solution works differently in different browsers (bouncing of the page content still happens on Safari and Edge, whereas on Firefox and Chrome it doesn’t), it will keep the header or footer fixed when you scroll to the very top or bottom of a website. It is a concise solution and on all the browsers tested, momentum-based scrolling still works, so you can scroll through a lot of page content very quickly. If you are building a fixed header or footer on your web page, you can begin to use this solution.

Smashing Editorial(rb, ra, yk, il)

August 14 2018

The Complete Anatomy Of The Gutenberg WordPress Editor

The Complete Anatomy Of The Gutenberg WordPress Editor

The Complete Anatomy Of The Gutenberg WordPress Editor

Manish Dudharejia
2018-08-14T14:00:22+02:002018-08-16T10:20:18+00:00

It seems that Gutenberg has been a term of controversy in the world of WordPress lately. Hailed as the most significant change to WordPress 5.0 this year, the Gutenberg editor has received a mixed response from web developers and regular folk alike. All of this chaos is making it difficult to see Gutenberg for what it really is. So, I’ll try to put some of the confusion to rest once and for all.

In this article, I will cover the following:

  1. What is Gutenberg?
  2. More Than Just An Editor
  3. What Does Gutenberg Change In WordPress?
  4. Installing Gutenberg
  5. Exploring Gutenberg At Length
  6. Pros And Cons
  7. Understanding Compatibility Issues
  8. Gutenberg Is The Future
  9. Latest News And Further Resources

1. What Is Gutenberg?

Named after Johannes Gutenberg, who invented the mechanical printing press, Gutenberg was introduced to the world by Matt Mullenweg at WordCamp Europe in 2017. In essence, Gutenberg is a new WordPress editor, with dozens of cutting-edge features. It simplifies website creation and editing for the average non-technical user.

It has earned several accolades, from “WordPress’s new publishing experience” to “the future of website creation”. Some skeptics think it is the nail in the coffin for WordPress. All this babble aside, Gutenberg is going to be way more than just an editor for WordPress (which I will discuss next).

It allows website creators to build a website using blocks, which are small drag-and-drop units. Thus, it replaces the current inconsistent and distracting customization process. It also enables HTML tags such as section and figure, outputting solid HTML. At the time of writing, Gutenberg is still a plugin. However, the community is planning to merge it with WordPress 5.0 this year.

Getting workflow just right ain’t an easy task. So are proper estimates. Or alignment among different departments. That’s why we’ve set up “this-is-how-I-work”-sessions — with smart cookies sharing what works well for them. A part of the Smashing Membership, of course.

Explore features →

2. More Than Just An Editor

Gutenberg is more than just an editor because it allow