[MUSIC PLAYING] SAM DUTTON: If users ever
need to sign into your site, good sign-in form
design is critical. This is especially true for
people on poor connections, on mobile, in a hurry,
or under stress. Now more than ever, you need
to ensure that sign-in isn't a barrier to using your site. Poorly designed sign-in
forms get high bounce rate, and, you know, each bounce
means a disgruntled user who's likely to exit
your site, not just a missed sign-in opportunity. But first, a
disclaimer-- this video is about best practice
for simple sign-in forms that use an email
address and password. It doesn't explain how to use
federated log-in with identity providers like
Google or Facebook or how to integrate
with back-end services. You can find out more about
those topics from the links at the end of the article
that goes with this video. So in this video,
I'm going to talk about straightforward
front-end coding best practice, mostly HTML with a little bit
of CSS and some JavaScript. I asked the Identity
Team at Chrome what I should talk
about, and they said, get the basics
of sign-in forms right. So be warned. This is simple stuff. It's not rocket science. And before we start, a
quick reality check-- do you actually really need
users to sign into your site? People don't like being
forced to hand over identity information. And all that personal data
and the code that goes with it becomes a cost and
a liability for you. If people can use your site
without signing in, all the better. The best sign-in form is
no sign-in form at all. Anyway, with all that out of
the way, let's get on with it. First up, well formed
HTML is the backbone of a good sign-in experience. Use the elements
built for the job. They've been around for years-- form, section,
label, and button. And as I'll show you, using
these elements as intended enables built-in
browser functionality, improves accessibility, and
adds meaning to your markup. Your basic HTML might start
out something like this. So let's break that down. Now, you might be tempted
to just wrap inputs in a div and handle input data submission
purely with JavaScript. Well, don't do it. You know, it's just
generally better to use a plain old form element. This makes your site more
accessible to screen readers and other assistive devices
and helps browsers understand the intention of
your code to enable a whole lot of cross-platform,
standardized, built-in form features that I'll
show you later. An HTML form also
makes it simpler to build basic functional
sign-in for older browsers and to enable sign-in
even if JavaScript fails. So first things first-- to label an input, use a label. There are two reasons for that. First reason-- a tap
or a click on a label moves focus to the input
it's associated with. Second reason-- screen
readers announce label text when the label or the
label's input gets focus. COMPUTER VOICE: Sign-in,
heading one, email with hint. SAM DUTTON: You associate
a label with an input by giving the label's for
attribute the same value as the input's ID. Now, placeholders can be
useful, but don't use them as input labels. People are liable to
forget what the input was for once they've
started entering text, especially if they
get distracted. You know, was I entering an
email address, a phone number, or an account ID? I can't remember. There are other potential
problems with placeholders, and you can see the article
that goes with this video if you're unconvinced. Now, it's probably best to put
your labels above your inputs. This enables consistent design
across mobile and desktop, and, according to
Google AI research, enables quicker
scanning by users. You get full width
labels and inputs, and you don't need to
adjust label and input width to fit the label text. Some sites force users to enter
emails or passwords twice. That might reduce
errors for a few users, but it causes extra
work for all users and can increase
abandonment rates. I think it's better to enable
users to confirm their email address-- you'll need to do that anyway-- and make it easy for them
to reset their password. Next, use buttons for buttons. Button elements provide
accessible behavior and built-in form
submission functionality, and they can easily be styled. There's no point in using
a div or some other element pretending to be a button. Give the Submit button in a
sign-up or sign-in form a value that says what it does such
as Create Account or Sign In, not Submit or Start or whatever. Consider disabling
the sign-in button once the user has
tapped or clicked it. Many users click
buttons multiple times even on sites that are
fast and responsive. That slows down interactions
and can add to server load. Conversely, don't disable form
submission awaiting user input. For example, like, don't just
disable the sign-in button if something's missing
or in the wrong format. Explain to the user
what they need to do. Now, this is a real example. I was urgently trying
to sign into a site, and there was no way of
knowing what I was doing wrong. Now, that HTML code
I showed you before is all valid and correct, but
the default browser styling means it looks terrible. And it's hard to use,
especially on mobile. The default browser size
for just about everything to do with forms is too
small, especially on mobile. This might seem
obvious, but it's a common problem with sign-in
forms on lots of sites. In particular, the
default size and padding for inputs and buttons
is too small on desktop and even worse on mobile. Here you can see the
various minimum guidelines for target sizes. On that basis, I
reckon you should add at least about
15 pixels of padding to input elements and
buttons for mobile and around 10 px on desktop. But, you know, don't
take my word for it. Try this out with real
devices and real humans And also make sure to provide
enough space between inputs. Add enough margin to make inputs
work well as touch targets. As a rough guide, that's about
a finger width of margin. You should comfortably
be able to tap each of your inputs and
buttons without bumping into something else. You also need to make sure your
inputs are clearly visible. The default border styling for
inputs makes them hard to see. They're almost invisible
on some platforms such as Chrome for Android. So add a border on
a white background. A good general rule is to
use, say, #CCC or darker or change the background
color instead. I mean, whatever you do,
make it blindingly obvious where to tap or click. And remember, design for thumbs. If you search for
touch target, you'll see lots of pictures
of forefingers. However, in the real
world, most people, many people use their thumbs
to interact with phones. Thumbs are bigger
than forefingers, and control is less precise. All the more reason for
adequately sized touch targets. Now, as with form control
dimensions and padding, the default browser font size
for input elements and buttons is too small,
particularly on mobile. Browsers on different
platforms size fonts somewhat differently, so
it's difficult to specify a particular font size
that works well everywhere. A quick survey of
popular websites shows sizes of around
13 to 16 px on desktop. Well, matching
that physical size is a good minimum
for text on mobile. And that means you need to use
larger pixel sizes on mobile generally. 16 px on Chrome on
desktop is quite legible, but even if you have
pretty good vision, it's difficult to read 16 px
text on Chrome on Android. Lighthouse can help you automate
the process of detecting text that's too small. Now let's talk about visual
indicators for validation. Browsers have built-in features
to do basic form validation for inputs with
a type attribute. Browsers warm when you submit
a form with an input value and set focus on the
problematic input. You don't need to
use JavaScript. Use the invalid CSS selector
to highlight invalid data. This is really widely
supported by browsers. And for more recent
browsers, you can use not(:placeholder-shown) to
avoid selecting inputs with no content. OK, we've touched on
elements and a bit of CSS. Now I want to talk
about attributes. This is where the
magic really happens. Browsers have multiple
helpful built-in features that use input element attributes. So let's take a look. Add an autofocus attribute
to the first input in your sign-in form. That makes it clear where to
start and on desktop at least means users don't have to select
the input to start typing. Password inputs should, of
course, have type="password" to hide password text and help
browsers understand the meaning of the input. Using input type
password also means that browsers, such
as Firefox, offer to save your password
when a form is submitted. As I'll show you,
browsers also use the name and ID
attributes to work out the role of form inputs. Use input type="email" to give
mobile users an appropriate keyboard and enable basic
built-in email address validation by the browser. Again, no JavaScript required. If you need to use a telephone
number instead of an email address, input type="tel"
enables a telephone keypad on mobile. You can also use the inputmode
attribute where necessary. inputmode="numeric" is
ideal for pin numbers. But watch out. Using type="number" adds an
up/down arrow to increment numbers. So don't use it for
numbers that aren't meant to be incremented such
as telephone or pin numbers. And while we're talking
about keyboards, unfortunately, if
you're not careful, mobile keyboards
may cover your form or, worse, partially
obscure the sign-in button. Uses may get confused
and just give up before realizing
what has happened. Avoid this where you can by
displaying only the email, phone, and password inputs
and the sign-in button at the top of your sign-in page. Put other content below. Now, I know this won't be
possible for every site. But whatever you
do, test on a range of devices for your
target audience and adjust accordingly. Some sites, including
Amazon and eBay, avoid the problem by
asking for email, phone, and password in two stages. Now, this approach also
simplifies the experience. The user is only tasked
with one thing at a time. So next up, the name and
order complete attributes. These are a really
powerful way for you to help browsers
help users by storing data and auto-filling inputs. There are two parts to this. The input name attribute
enables browsers to work out the role of various
inputs so that they can store email addresses
and other data for use with autocomplete. So don't make the browser guess. Some browsers,
including Firefox, also take note of the
ID and type attributes. When the user later accesses a
sign-in form on the same site, the autocomplete attribute
enables the browser to autofill inputs
using the data it stored using the name attribute. Now, you need different
behavior for password inputs in sign-up and sign-in forms. Don't add autofill to a password
input in a sign-up form. The browser may already have a
password stored for the site, and auto-filling a password just
doesn't make sense on sign-up, for example, if two people share
the same device and one wants to create a new account. Use the appropriate
password input name to help the browser
differentiate between new and
current passwords. Use name="new-password" for
the password input in a sign-up form and also for the new
password in a change password form. This tells the browser
that you want it to store a new password for the site. Use name="current-password" for
the password input in a sign-in form or the input for the
user's old password in a change password form. This tells the
browser that you want it to use the current
password that it has stored for the site. Different browsers handle
email autofill and password suggestions somewhat
differently, but the effect is much the same. On Safari 11 and above
on desktop, for example, the Password Manager
is displayed. And then biometric
authentication, fingerprint or
facial recognition, is used if available. Chrome on desktop
displays email suggestions depending on what you type,
shows the Password Manager, and then autofills the password. Now, here's another
reason to use autocomplete="new-password". Modern browsers suggest
a strong password if that's included
for the password input in a sign-up form. Use built-in browser
password generators. That means users and developers
don't need to work out what a strong password is. Since browsers can securely
store passwords and autofill them as necessary,
there's no need for users to remember or
enter passwords and, you know, leave them on sticky notes
attached to their computer. Add the required attribute to
both email and password fields. Modern browsers automatically
prompt and set focus for missing data. And I'll say it again. No JavaScript required. So I've talked about the basics
of getting HTML and CSS right, but you're also going
to need some JavaScript. Make sure to add a Show
Password icon or text button to enable users to
check the text they've entered. And don't forget to add
a Forgot Password link. Here's how Gmail does it. It's really straightforward. You add a listener to your
button, and in the handle, toggle the password input
type to text or password. Make sure to include
an aria label to warn that the password
will be displayed. Otherwise users may
inadvertently reveal passwords. Speaking of accessibility,
use aria-describedby to explain password
constraints using the element you use to describe your
password requirements. Screen readers read the
label text, the input type, and then the description. Now, you'll also want
to validate data entry in real time and
before submission. HTML form elements
and attributes have built-in features
for basic validation, but you should
also use JavaScript to do more robust validation
while users are entering data and when they attempt
to submit the form. Just bear in mind
that this does not obviate the need to validate and
sanitize data on the back end. The sign-in form Codelab that
goes with this video uses the constraint validation
API, which is widely supported to add custom validation using
built-in browser UI to set focus and display prompts. OK, one really
important extra thing-- what you cannot measure, you
cannot improve is particularly true for sign-up
and sign-in forms. You need to set goals, measure
success, improve your site, and repeat. Usability and lab
testing are really helpful for trying out changes. But you'll also
need real-world data to really understand how
your users experience your sign-up and sign-in forms
with analytics and real user measurement, or monitoring. And you'll need to monitor
page analytics, including sign-up and sign-in page
views, bounce rates, and exits. Make sure to add interaction
analytics, such as goal funnels, where do users abandon
your sign-up or sign-in flow, and events-- you know, what
actions do users take when interacting with your forms. And lastly, track
website performance. Use user-centric field
metrics to understand the real experience
of real users. Are your sign-up and
sign-in forms slow to load? And if so, what is the cause? And finally, some general
guidelines to help reduce sign-in form abandonment. Number one, don't make
users hunt for the sign-in. Put a link to the sign-in form
at the top of the page using well understood wording like
Sign In, Create Account, or Register. And keep it focused. Sign-in forms are not the
place to distract people with offers and features. Minimize complexity. Ask for other user data, such
as addresses or credit card details only when users
see a clear benefit from providing that data. Before users start
on your sign-up form, make clear what the
value proposition is-- you know, how they
benefit from signing in. Give users concrete incentives
to complete sign-up. If possible, allow users
to identify themselves with a mobile phone number
instead of an email address, since that's the way
some users want to do it. They may not want
to use their email. Make it easy for users
to reset their password, and make the Forgot Your
Password link obvious. Make sure to link to your terms
of service and privacy policy documents. Make it clear to
users from the start how you safeguard their data. And finally-- finally,
include branding for your company or organization
on your sign-up and sign-in pages. Make sure your fonts,
styles, and tone of voice match the rest of your site. Some forms just-- you
know, they just feel like they don't belong to the
same site as other content, especially if they have a
significantly different URL. So there you go. That's the basics of
sign-in form best practice. And you can find out more
from the web.dev article that goes with this video
and the Codelab that goes with that. I hope that's given
you a few items to add to your next sprint to
improve your website's forms. Of course, sign-up
and sign-in, it's not the only place that
involves a lot of form filling that could be improved. So stay tuned for
Eiji, who's going to talk through some of the
new options for payments on the web. Thanks for watching. [MUSIC PLAYING]
