Using Autocomplete for Optimal Form UX – Designer vs. Developer #24


ADRIENNE PORTER
FELT: You’ve probably tried to buy something
online or had to fill out some form
for your kid’s school, and it’s really
hard on your phone. It’s really hard. MUSTAFA: There seems
to be a dark art when it comes to native
applications, and they’re such small details that
you’re actually working on. [MUSIC PLAYING] Quite often, developers will
just throw on input fields onto a page and not really
think about the UX that’s attributed to that. So they’ll think of
a flow of a form, but they won’t necessarily
feel that individual input, so how a user struggles. And we know that
autocomplete really helps speed up the
user experience and makes filling
forms quite nice. What are your feelings
and experiences on autocomplete and
Autofill as a thing? ADRIENNE PORTER FELT:
From the user experience, you’ve probably tried
to buy something online or had to fill out some
form for your kid’s school. And it’s really
hard on your phone. It’s really hard. It’s even hard on desktop. You don’t want to get up
and get your credit card out of your purse,
which is downstairs. And these browser
features just really improve the user
experience of using a form. In fact, we find that people
fill out or submit the form 30% faster if the form
works with Autofill. So we very much suggest that
web developers think about this. You want people to be
submitting your forms. Right? So if you really want your
forms to be submitted quickly, easily, work with Autofill. MUSTAFA: And why do you think
developers don’t do that? Is it very difficult to do? I’m assuming it’s just a few
attributes you add to inputs. Right? ADRIENNE PORTER FELT: Yeah. It’s actually not that hard. So you basically need to set
up autocomplete attributes, and you need to make
sure that you’re not doing any fancy things that
replace the normal select and input elements with
other types of elements. I think most of these developers
just don’t think about it, don’t realize,
that you just need to put a little
bit of extra effort in to make sure that your
form works well with Autofill and to test it out. MUSTAFA: Is that one
of the challenges, I suppose, like people making
these custom UI things, which are not native but just
like divs or whatever and replacing that? Is that where things
fall down with Autofill? ADRIENNE PORTER FELT:
Honestly, there’s a few things that can go wrong,
but that’s one of the big ones. Yeah, so someone wants this
really beautiful custom form where the dropdown is
all fancy and custom. And as a result of that,
they’re using all divs. And the browser can’t
figure out, oh, this is supposed to be a form. And then in that case,
Autofill isn’t going to work. MUSTAFA: And I
suppose there’s a lot of accessibility
issues connected to that as well, it looks like. But from your point
of view, you’ve got designers and
developers, they want to do something custom,
like unique experience. But then as someone who
works on the browser, you want to say, now let
the browser do the work. Do you think there’s
a middle point there? How can developers at least
have a custom experience that’s unique to their
product, but at the same time without breaking standards? Because this is one of the
biggest challenges on the web. ADRIENNE PORTER FELT:
So there’s a lot of things you can do to
change the look of the form on the page while still
using the select and input elements that HTML provides. Right? You can customize
them in many ways. I have to admit, there is one
thing you can’t customize, and it’s the look
of the dropdown, like in a select element. But everything else, the way
it statically looks on a page, you can customize. And the browser will still
know that they’re fields. MUSTAFA: Yeah. What you see is the
biggest challenge then, for Autofill
or implementation, from your point of view? ADRIENNE PORTER FELT:
I think it’s honestly that developers don’t think
about it, that people don’t think to themselves that they
really need to be testing their forms in this way. When you’ve made it yourself,
you’ve filled it out 100 times. You tested it yourself. And you don’t think
about the fact that a user is going
to be coming to it in a different state of mind. They’re tired. They are trying
to fill it out as fast as they can on the phone. So I think developers
just aren’t really thinking about the fact
that they need to take these extra small steps. MUSTAFA: So in terms of
browser compatibility, the things you’re using will
be Chrome-specific stuff? Or is that open source– not open source, but
it’s cross-platform. ADRIENNE PORTER FELT: Yeah,
that’s a good question. So specifically autocomplete
attributes for Autofill, that’s standardized. All the browsers respect them. With that being said, there
is one part, turning Autofill off– that’s the autocomplete
off attribute– is not respected by all browsers. But if you say,
this form should be a credit card, that
will be respected by all the major browsers. MUSTAFA: But each
experience, is there slight quirks per browser? Because obviously, that’s going
to be a browser-specific thing. ADRIENNE PORTER FELT: Some are– they have very
slightly different UIs. For example, maybe they’ll
be integrated with a keyboard widget versus a dropdown. But I think they’re pretty
similar across browsers. MUSTAFA: You work on the
actual Chrome UI itself. ADRIENNE PORTER FELT: Yes. MUSTAFA: So are you actually
building that design and code yourself, or are you
working with UX designers in that process? ADRIENNE PORTER FELT: So
we have a design team. And the design team helps
us figure out what those UI elements should look like. We actually have a big
redesign coming up this year that I think is going to
make those substantially more beautiful and also help clean up
the code, which I know that it won’t affect most people because
it won’t look any different. But from our perspective– MUSTAFA: It’s much cleaner. ADRIENNE PORTER FELT: Man,
the code’s so much cleaner. MUSTAFA: What’s the actual
process of you actually creating UI? Because for me, I do front-end
development and code. But it’s like there seems
to be a dark art when it comes to native applications. And they’re such small
details that you’re actually working on, which the user may
not notice because it works. But if it’s broken,
they will see it. What is the actual
process that you go through with your Chrome
designers to actually making the UI or testing it? I’m asking lots of
questions all at once. ADRIENNE PORTER
FELT: Yeah, it’s OK. It’s OK. So I’ll talk about the
process a little bit. So usually at the beginning,
Product, Eng, and the designer will get together
and talk about what they hope for from the feature. Often, the design
will then come up with some conceptual
mocks of what they feel the feature could look like. They’ll get feedback
from Product. They’ll get feedback from
the engineers, like can we actually build this, what
are the corner cases we need? And then we’ll
iteratively get closer to what we actually can ship. So I work on a
cross-platform team, which means that what
we build has to ship on all of Chrome’s platforms. People think of Chrome
as one platform. But actually, it’s
Windows and Mac– which previously
had different UIs, but we’re coming to
one single standard– Android, iOS. And so we have to have
different mocks that relate to the specific platforms. So some things may be
possible for some subset. Anyway, the designers get all
this feedback from engineers, like, we can do this
here and not there. And then we iteratively
come through to red lines, which is
our final set of designs. And that’s what we implement. MUSTAFA: So in terms
of do the designers work with the actual W3C? Because you’re
designing something which has to be
considered cross-platform at the same [? time. ?] So like
when the payment request API, like I was working with
some of the team there, there seems to be things
where you have to really be seeing what
everyone else is doing so that the experience
that you’re creating is not so widely different. And that can be quite
challenging for the designer and developer because you
instinctively want to make it, I don’t know, “better.” But you don’t want to make
it so vastly different, because then you stick out. ADRIENNE PORTER FELT: That’s
an interesting question. The challenge here is
that with specs, we try not to specify what
the UI has to look like. We try to talk about what the
user experience should be so that we can have the appropriate
callbacks, et cetera, to build that experience. But we don’t like to
standardize the UI itself, which is a fine balance because
you have to have a UI in mind when you’re designing the API. But we try to make it
as general as possible so that we can build different
UI experiences on top of it. MUSTAFA: Are you working
with the browsers as well at the same
time to do that, or is it you do things independently? Because there’s the thing. It’s like if you do it
[INAUDIBLE] the browsers, then you may be led
down a path that’s not the best for everyone. That it’s, OK, it’s
like a compromise. But at the same time, you don’t
want that complete disparity. ADRIENNE PORTER FELT: It
depends a lot on the standard, honestly. Some of them will
be heavily driven by Chrome or some other browser. They really want this API. They’ll drive it, and then
get a little bit of feedback along the way from
other vendors. Whereas others,
from the beginning, there’s several
different browser vendors working together. So honestly, it differs
from standard to standard. MUSTAFA: And we’re coming to the
10-year anniversary of Chrome. What do you think
the future of say, Autofill, or just working
with the other browsers? Because it seems like things
are getting much better. I was speaking to
Darren, and it was like, the implementation
of Flexbox was a nightmare because
the standard kept changing. But with CSS grid, it’s
amazing that there’s so much cross-collaboration
between the browsers, which is great for the users and the
developers working across this. What do you think the future
is for Chrome as a platform and, I suppose, Autofill
as well as a specific? ADRIENNE PORTER FELT: So
for Autofill specifically, it’s hard to say
because I don’t think the limitation there really
is the lack of browser vendors cooperating. I feel like actually, there’s
been a lot of discussion, for example, around
payment request. There’s a lot of collaboration
between Safari and Chrome. I think that the
real problem we have is that Autofill depends
on developer adoption. Right? If it’s hard for the
browser to figure out what form’s in the
page, we’re not going to be able to Autofill it. And so I think the
thing we really care about is whether
we can get developers interested in and
using the tools that we have provided for them to
try to improve the Autofill experience. MUSTAFA: Yeah. Do you ever have to
remove a feature when you see there’s not wide adoption? Because I can see
from an engineer, you’re working on Chrome. You spent your heart and
soul working on this feature. And then you know it’s
great for user experience. You know from the
research that Autofill will help transactions,
and it’s just nicer. But if adoption doesn’t
happen, how do you [INAUDIBLE]?? It’s the biggest– ADRIENNE PORTER FELT: Yeah,
that’s a really hard one. I’ve been through
a few deprecations. They can be really challenging. It’s very hard. So there are a few ways
you can look at it. One is how many users
interact with websites that are using such a feature. And obviously, that
number is large, you don’t want to create a
pain point for a lot of users. But even if the
number is very small, it might be that there are a
few websites, a few companies, whose entire business
model depends on having access to this API. And so that can make it
very difficult, where OK, even if it’s this
really a niche thing, it still can be
hard to deprecate. So I think there have been
lots of ongoing discussions in general about how
to make that trade-off. Some of the ones
I’ve been involved in relate specifically
to security and TLS, where if something is making
the web as a whole as safe, we may have to break
some connections in order to deprecate it. And it can be a
really painful thing when you’ve got old servers
on the internet that aren’t being upgraded. And maybe it’s only a small
percentage of overall page loads, but it’s
still frustrating when a user is trying to get
to a website and it’s broken. MUSTAFA: Yeah. But ultimately, from
Chrome’s perspective, it’s the user’s experience
that’s paramount. Right? ADRIENNE PORTER FELT: Yes. MUSTAFA: And their
safety and security. So it’s like HTTPS, you could
probably explain it better, but there’s a cutoff point
where if your site is not loaded on HTTPS, you’re going
to get a message saying, this isn’t secure. That’s true. Right? ADRIENNE PORTER FELT: For
a long time in Chrome, we showed HTTP as neutral, HTTP
as just plain text and no TLS. MUSTAFA: Sorry, what’s TLS,
just for my non-designer– ADRIENNE PORTER FELT: Oh, TLS
is the underlying protocol that makes HTTPS HTTPS. It’s why it’s secure. So there is HTTP,
which doesn’t have any of the end-to-end
security bits on it. And HTTP websites
were just shown as a neutral standard thing. Right? Most websites on the web were
HTTP, but that’s changed. We went from a few years
ago, we were at 25% HTTPS. And now, it’s the opposite where
we’re at more like 75% HTTPS. So made changes in the
UI to back that up. So now when you go to a
website that says HTTP, it’s going to also say
“not secure” next to it so people really
understand what that means. MUSTAFA: That decision must
be quite tough, though. In some respects, you need to
force the developers to say users’ security is paramount. But at the same
time, does it feel like you’re breaking the web? ADRIENNE PORTER FELT:
It doesn’t really feel like we’re
breaking the web. First of all, I
think people have seen this a long time coming. We’ve been talking about
it for a long time. We’ve rolled it out in phases. So first, we started showing
“not secure” specifically for pages with passwords
and credit card form fields. And then it was for all
form fields and web pages when viewed in incognito. And now we’re rolling it
out for all HTTP websites. And as you can see, because
HTTPS adoption has really increased, it’s only
impacting less than a quarter of page loads at this point. MUSTAFA: So really,
we’re just talking about protecting the user. ADRIENNE PORTER
FELT: Yeah, and I think users have a right to know
that their information isn’t secure when they’re
going to this website and help them make a
decision about whether or not they want to keep using that
service or go to another one. MUSTAFA: And do you
think users are quite savvy now to see those things? Or is this part of the
education for the user as well to say, look,
there are certain things on the web which are
not secure that you have to take into consideration. ADRIENNE PORTER
FELT: I’ll be honest. We have literally billions of
active users, so it’s hard to– MUSTAFA: Make a
general [INAUDIBLE] ADRIENNE PORTER
FELT: –say generally whether people are going
to understand it or not. We think enough
people understand it that they have a reaction
and that they can reach out to sites saying, hey, I
really like this site, but I wish it were secure. And we see people doing that
as we’ve been rolling out these warnings. SPEAKER 1: The way that
cellular networks are set up is that there’s always
these fringe areas, and there’s always
these breakdowns. And higher latency
is always there.

Add a Comment

Your email address will not be published. Required fields are marked *