Google Hackathon on AIR – Great travel experiences on small screens

Google Hackathon on AIR – Great travel experiences on small screens


DOM HEYBERG: Hi, everyone. It’s Dom and Dennis
again, and welcome to our last and final
Hackathon on Air for this year. We thought we’d do it a
little bit special this time, and we invited two experts
from the US, Cheney and Erica, who are going to
talk about travel UX. Most of you know
that travel UX is kind of like a special
case on the mobile web. It’s a long customer
journey, and we want to discuss
the topic and see how can we optimize
each step of the funnel so that we can provide
a good UX experience on the mobile device. Today we have a lot of
people in the stream. So it’s myself, it’s
Dennis in Dublin, it’s Cheney and Erica in the US. So we have to switch
back and forth a lot, so if not everything
goes according to plan, we apologize already. As always, towards the
end, we will answer any questions you might have. So type away any
questions, and at the end, if we have like 10 minutes
left, we’ll pick them all up and try to answer them
as good as we can. So that’s it for me
for now, and I’ll give over to Dublin to Dennis. DENNIS RASPOTNIG: Hello,
everybody, and thanks, Dom. Just a quick hello from Dublin. Also to add on Dom’s
intro, please let us know if the audio is all
right and everything. So just type into chat if
something is not working, and we’ll fix it as
quickly as possible. Well, yeah, I think that’s
already everything from me today, because I want
to to introduce you to our mobile
experts from the US. So first up, I want
to introduce you to Cheney, who lives, if I’m
not incorrect, in New York. So let’s send it over to Cheney. Hi, Cheney. CHENEY TSAI: All
right, thank you. So my name’s Cheney. I used to sit in New York,
so you’re partially correct. Usually based in Mountain
View in the Bay Area, and right now, I’m
dialing in live from the Washington, DC office. But nice to meet
everyone on stream. I am a technical consultant here
at Google working on all things mobile web, from
progressive web apps to our awesome web APIs,
accelerated mobile pages. And I work a lot
with travel partners, and that’s why we’re here, to
kind of dive deep into some of the common
optimizations and issues that has come up in some
of our past conversations. ERICA TRITTSCHUH:
And hi, everyone. I’m Erica Trittschuh. I’ve been working at Google
for 11 years, all in the travel industry. I am Mobile Strategy
Lead, which means that I help travel sites think
about their overall mobile strategy and also how they can
improve their mobile experience for their users. And we haven’t had
a Hackathon on Air that was dedicated to a
specific industry in the past. And so why are we doing that? We think travel–
well, I personally think travel is pretty special. As I said, I’ve been
in it for a long time. But travel has a few unique
things that set it apart. And we’ll move on, go
ahead and start us off here on the slides. But one thing that’s
distinctive about travelers is that they want to
accomplish a task quickly. It’s not just about the booking,
it’s also heavy on research. Even when they’re researching,
they’re really task-oriented. You can see on
here that over 90% of travelers using
mobile devices will switch to
another site or app if their needs
are not being met. They’re very picky. They want the experience to
be very good and seamless. So when thinking about
that, as a brand and a site, and it’s important to
reduce that friction, to assist the traveler whenever
they’re accomplishing a task, and it’s whichever
task they want to do. And another thing
to think about is that travelers are on the go. They are going from having
mobile as one of their devices to having it be
their only device. Travelers have a clear
time when they’re 100% dependent on
their mobile phones. And over 65% of travelers
across a group of countries that we researched
agreed that they always use their smart phones
when they’re traveling. And thinking about what
this means as a site, it means that they could
be in flaky networks. So when you’re traveling,
you’re often in airports, and at least here in the US,
airport Wi-Fi is terrible. If you’ve ever had
to try to do research when you’re at an airport,
you will agree with me, that you need to make
sure that your site is working on these flaky
or very slow networks. And they have higher
expectations, travelers do, because they’re not always
in relaxed settings. They’re not always at home. They could be, like I
said, at the airport or in a rental
car moving around. So it’s important to think
about that when designing your mobile web experience. Travelers expect– when thinking
about that experience, what brands are you needing to
think about that they might be comparing themselves to? So if we look at the
next slide, you’re not just comparing yourselves
to your peer set within travel. You really need to think about
what other sites are travelers visiting. Because you’re, in
truth, competing with all brands that a
traveler is visiting. So you’re competing
with the best experience that a traveler has
had online, whether it be when they’re buying
coffee, buying pizza, it’s not just within
the travel industry. And so when thinking about
e-commerce interactions on the phone, we’re thinking
about a few different phases. We’re thinking
about the discovery phase, engagement phase,
conversion and retention. And we can move on to the
next bit, Cheney, there. Great. And you know, as a site or a
brand, we need to think about, are we making those
phases as efficient as possible or as pleasant
as possible for our users? How can we reduce friction
in each of these steps so that the user has
a seamless experience? And moving away from
the simple linear line, if you know travel, you know
that the pathway is not simple. It’s not a linear journey. It’s actually quite complex. So it’s important to consider
this specific travel journey and how the
experience can impact a user that’s jumping in
and out of the journey throughout the whole way. And so if we look
at this next slide, you can see that users are
discovering in the beginning, and then they’re
doing research, then they might be bouncing out
to discover another site and doing more research. And research is happening
throughout the whole thing. And they’re bouncing
back in between sites. So I’d like to have Cheney,
who, as he introduced himself, a mobile solutions
consultant engineer, to walk us through what
components would really help this holiday planning
experience be frictionless. And then we’ll go through and
dive into the technical side of what certain feature
implementation might look like to help guide this journey. Cheney, over to you. CHENEY TSAI: Cool,
thanks, Erica. So I like to kind
of like, before we dive into the nitty
gritty details, JavaScript and all
that kind of stuff, try to figure out what’s
different about travel. I think travel is
really interesting. It really exists on one
complete side of the spectrum. It’s one of the most complex
experiences, user journeys, to Erica’s point, that
any user can probably go. You’re probably coming in like
you’re reading an article, you’re looking at a top 10 list. For many sites out there,
like a news publisher, that’s kind of where
the journey ends. You might direct them
to a different place. So it’s kind of like– I like to use this house
analogy, where you’re just kind of window shopping,
looking at a house, and saying, you know, that looks
great from the outside. But if you’re a travel
user, a lot of that is– it doesn’t stop at the front door. You need to go through the
house or some sort of task completion, right, because you
left your keys in the kitchen when you’re about to check out
of your Airbnb or something like that. So you have to walk through
this probably somewhat unfamiliar house that you’ve
only visited once before, go all the way through
different rooms, and figure out where
you left your things. And so I think the
quality of that web site, or in this case, the metaphor of
the house, is super important. Oftentimes we kind of approach
building a travel site, building any website really,
kind of so focused on features. We’re just going to need to
build the sharing feature, we need to add this
image carousel. We need to add a way for
users to do xy and z. Well, all those things are
great and really provide value to the users. They really don’t
function the way you want to unless they’re
on a very stable foundation. Very similar to the way
you build a nice house. For a lot of travel
sites, it’s not a simple cottage in the
woods where you don’t need a very strong foundation. It’s much like a
skyscraper, where you need to dig something
that’s like, I don’t know, however many meters
deep, at strong, steel structural footprints
and things like that. And in many ways, all
the engineering efforts you do to allow your
nice user-facing features that function well,
it really requires an external foundation. So I like to use this
kind of analogy here. Now if I refer back to
this in a little bit, where, you know, the
house you envisioned, when the designer
gives you a mock, this is this beautiful, new
web application or native application. This is what it looks
like, it looks great. But when implemented, oftentimes
you get the left side, where, oh, I tried to
click on this link, the page flashed white,
things were moving around. I was click– I was trying
to swipe this carousel, and for some reason,
the animation wasn’t quite tracked
with my finger. What happens when you come
to a website like that? You’re probably
distracted as a user. You probably forgot
what you’re looking for. You might have come in
for a great marketing campaign, because it’s
a great deal to Bermuda. You land in, and
suddenly, maybe 30% of the user’s cognitive
ability is now spent trying to figure
out where they are. And that’s a chance
that you’re taking away from them actually converting. So going back to
the user journey, you want to deliver a
great first experience, and we’ll keep going down
the journey about how to continue delivering
that great experience. Because at the end of the
day, a good travel experience isn’t a series of
interconnected pages. It’s one, continuous,
analog flow. So step one is
something that you guys, for those who joined on
previous Hackathons on Air, you’re probably
used to the idea of, you want your page to load fast. Site speed is something that
we could go up and talk about for a very long time. And so a lot of
the things I just mentioned, you know, things
like elements on the page moving around, things
sliding up and down, things being loaded
really slowly but then popping up suddenly,
like an interstitial to sign up for a newsletter or
add your application that kind of takes over the
entire screen, those are all things that can
affect what the users perceive the page for being slow. Obviously, there’s a
lot of technical issues here, too, about just sending
maybe gigantic images, sending gigantic
JavaScript files, sending things that you don’t
even need, because maybe you did a one month test with an
A/B testing third party partner, and you decided to
not use them anymore. So many sites we see
out there, they just naively leave that
script tag at the top of the page bringing
in that resource for the initial first experience
even if they may not even be using that service anymore. So you’ve heard
the stats before. 53% of users will
abandon a page that takes more than three
seconds to load. And in truth to
this, if you look into the data from [INAUDIBLE]
and things like that, you’ll find that a lot
of these speed things actually even happen way
below that five second mark. It’s not improving from
10 seconds to 5 seconds. We see that the
effect on abandonment, on engagement really
accelerates as you move faster towards that one second piece. So again, shout out to– you can click the
Google link here to check out the previous
Hackathons on Air about how to make your site
show up as fast as you can. What we’re going to be
talking about complete today, because travel, again,
like getting from point A to point B, it’s not
about just point A. It’s about actually getting
through maybe that six taps, three swipes, one
scroll experience, all the way to actually
booking a stay, looking up a train schedule
or something like that. Of course, you want to
prioritize content that matters to the user, great. Like you can’t bet on your
page being the only thing that the user is going to see. Most likely, they’re
going to land on the page, because they clicked on
the search results or maybe something from a
Twitter share saying, check out these three awesome
things to do in this city. They’ll click in. You want what their
intent is to actually show up as fast as possible. So many times we
see websites where, because travel tends to be very
marketing-forward, in terms, like, you want to
showcase a city. You want to show awesome
images about some activity. A lot of times the page
is very rich in media. And so you start seeing
things where, like, well on a mobile page,
obviously, you can keep scrolling down and down. But what if you load images at
the very bottom of the page? If you spend time
loading things there, that’s going to affect that
very, very first metric. So you can spend all the
time in the world making sure everything is
compressed, making sure everything is
minified, making sure that your JavaScript file
is all concatenated together so you’re not trying
to pool things from six different servers,
but at the end of the day, we see teams having to
struggle with prioritization. We have too many
parts of the company want to make sure that their
feature, their subcategory, maybe it’s because you split out
your business towards flights, hotels, cars, deals, and each
of these are equally important, and they need equal
space on the page. A lot of times, that’s going
to hurt your user experience. They’re going to
land on the page, they’re going to see about
maybe 10 calls to actions before they even
start scrolling, and that’s going to hurt the
chances of them moving down the funnel. So let’s think about
enabling repeated searching and exploration. At the end of the day, we want
them to find something quickly, using maybe two to three
main calls to action, allow them to scroll, maybe
open up a hamburger menu, maybe have a form search
with a date picker, with a city search,
autocomplete something at the top of the page
and tell them to refine. But after they’ve refined,
what are they going to do? They’re probably
going to click Search. They’re probably going
to click on a tab or something like that. And a lot of times,
what happens there is, from a technical
perspective, you say, OK, let’s
talk to the server. Please send me the
contents required to get to this other page. And then we start
back at the beginning, where, OK, the page is
going to flash white and then we’re going to
start building in JavaScript, start building in more
images and CSS, right? You could optimize that to be
loading as fast as, like, two seconds, one second. But what happens
when we really see, though, is that this
adds up over time. Again, going back to
the whole user journey here, how many clicks
do you think your users are going to do before they
get to some point of value to your business, to
booking something, to finding that train schedule,
to do anything, any of that? It’s very well, like,
at least, four clicks, not even counting the
things that they had to type into any sort of form field. So you potentially
want to make sure that everything that
happens after load still stays fast for the user. This is what is a big
difference maker between some of the best native
apps out there and a lot of the web
sites out there trying to achieve the same
sort of engagement, the same sort of session
time as native applications. So that brings us to a topic
that comes up very often and I think will
become a theme in 2018. This is the cost of JavaScript. This title here, “The
Cost Of JavaScript,” is actually named after a
article written by Addy Osmani from our Chrome DevRel team. So feel free to Google that. It’s an article about
this topic a little bit. Because we don’t
have a lot of time, we won’t cover this
to an extreme detail. But long story short,
for travel sites, they’re very interactive, right? So most likely, you’re
bringing in JavaScript, ones that you found online because
it’s a package that you rely on, because it’s helping
you manage state, it’s helping you build
applications like features. A lot of times,
it’s your own code, because you have
custom logic you need to do to talk to
some flight search API, talk to your own APIs,
because you have some sort of data stored on your server. You want to bring it into
your web application. And then what happens when you
get data into a typical site? You probably need to massage
it, creating DOM elements, move things around,
react to user input. So when the user
clicks something, you don’t want to, necessarily,
do a full page load. So a lot of times, you’re
sending all this code to your website. And what we start to see is that
the site speed story suddenly isn’t just about what you’re
sending to a mobile phone. Typical mobile phones
are going to be not as powerful as your
MacBook Pro or your latest Windows laptop or
anything like that. And you’re probably– it’s
not going to be quite as– the user expectation, you’re
not comparing it to a website. You’re comparing
this to native apps, where a lot of the code that can
already be executed on a device once it’s been free downloaded. So what happens is, we
look at the bottom here, you wait for the
JavaScript to be requested. It arrives, it
probably executes, which is the yellow bar here. Then after that execution
time, then it fetches content that you might need, a lot
of this is dynamic content, like pricing data or
anything like that. It arrives, and then you’re
probably doing even more things after it arrives, because that
user is swiping, activating things that you’ve
created, a event handler to really react to. So a lot of times when
we talk about speed, we don’t actually consider
the yellow portions. We just think about requesting
everything, is content loaded. And at this point, at
the end of this blue bar, we typically say, oh, OK, the
user should– the site speed, it’s done. Everything’s loaded. The user should be
able to use everything. And for a news website,
that might be true. But for travel, especially
on very small screens, there’s users going to
try to do something. They always scroll. They’re always going to tap
something, because they’re so purpose driven. The problem is there’s all
this time before JavaScript has actually been evaluated
and parsed to actually react to that user input. And you know, one of the things
that I like to kind of point out is optimizations usually
say, OK, gzip your JavaScript. And then you get
that down to maybe, like, 200 kilobytes, which
is still pretty gigantic, to send to a mobile
device to execute. But that 200 kilobytes,
once uncompressed, could be maybe one
full megabyte of code that needs to be parsed,
evaluated, and then executed before your page can actually
do anything and respond to any sort of touch. So that fancy animation,
that sidebar sliding out, might not actually work,
creating sort of uncanny valley where the user really isn’t
looking at the web application anymore. Your website, at
that point, really is just a glorified flyer. It’s something that you
printed out, put an image up, and left it on the screen. You can create
discontent with the user. And you can imagine this
compounds over time, going back to the user journey. Some JavaScript compilation
is obviously saved and can actually be reused,
but your own executing code might still be creating
jank on the page. So that you go to
the next page, you’re waiting for that
JavaScript to run, and it just creates a really,
really slow and cumbersome experience. A lot of things
that you don’t see, it’s not that a font’s
slightly different, it’s not that an
element looks broken. It’s just they’re
trying to use what is a otherwise probably
pretty beautiful site, but they can’t
actually do anything. And this isn’t an issue just for
low end devices, it’s not just the a Moto G. Even
something like an iPhone 8, for a lot of script
times, this data was– thanks to Pat Meenan for
pulling some of this. But a lot of the script times,
it’s because it’s non-trivial. A megabyte of
JavaScript might even take up to 500
milliseconds to actually be fully parsed,
evaled and executed on an iPhone 7, iPhone 8. And that’s going to be time
where the user is probably trying to tap on something. You can’t quite respond
with the same expectations that they’re used to using
your native applications. And that’s going to be the
reason why they bounce, why they stop engaging. And they create
this mental model over time about, OK,
every single thing I do has a cost
associated with it. And if I click on
something incorrectly, because you tap
on something, you thought it was going
to work, and it feels like everything’s broken,
what do people usually do? They probably
touch other things, and then they probably
end up somewhere where they don’t want to be. They have to pay the full cost
of loading the page again. So in the future,
they’re probably going be more careful and less
likely to engage with the page. And so there’s a lot
of different ways to deal with this,
right, in this whole, how can we optimize for a
UX where users are going to do a lot of things,
where you want to, instead of moving from page to page, you
want to build around user flux. So one of the
things that we talk about when we talk about
progressive web apps, about modern web, is to think
about whether a single page app makes sense for your brand. There’s a lot more complexity,
potentially, to doing this, because it requires you to think
about all different page states that you have. No longer is it
that you go to a URL and it’s always going to
be that exact set of data. Potentially, you’re going to
have client side JavaScript that’s actually
reacting to user input, bringing in data from some API,
from some other third party data source, and then
updating search results, updating views if you’re
moving between an identity page, a login page, to a browse
page, to a payments flow. That can all live inside of
a single page application. And one of the common
patterns that we generally encourage you to
think about is trying to separate your dynamic content
from your application shell. And you can kind of see
this idea spread out right here, where, well,
there’s a lot of things that native apps do well. One of the poor things
about a native app, obviously, is that you have
to download everything. And that’s a cost you pay. But what if you can leverage
the things that they do well, which is, well, after
you download something, that static content should
just live on your device? So when you’re clicking
over to a different page, you’re only needing to update
that part of the web page that requires
change, without going through the entire previous
process of loading everything, of writing, parsing,
more JavaScript, downloading more things. So this is one of the
common ways in which we see kind of patterns that
help travel sites really build really fast,
engaging experiences that is reactive to all
sorts of user interactions. And so one of the key advantages
of doing that, really, is you don’t want users to feel like
you’re waiting on the network. And this is one of the
key differences, too, I think that normal web sites
have to native applications. When you do a site search,
there’s an expectation that there’s some work being
done in the background. Or you can click on, I
want to look at more. Like in this draft
[INAUDIBLE] sample here, I want to look at more of this– I’m not sure if that’s
a hotel or Airbnb, but I want to see more of it. Typically, a website would
say, I got you user input, I’m going to do nothing. I’m just going to hang here. You can keep
scrolling this page. You might see this blue bar
at the top that’s slowly moving, until suddenly, maybe
like an arbitrary 3 to 10 seconds later, depending
on your network connection, we’re going to flash
that screen white and we’re going to take
you to someplace different. It’s basically as if
you teleported the user. If you get teleported somewhere
completely different, let’s say to some random town in
Germany, what’s your reaction? You’re probably
going to be like, what just happened, where was I? I thought I was– well,
what was I doing again? Those thoughts, again, are
getting in the way between you and completing that transaction. The Flipkart is a progressive
web app here that kind of tries to think about the user
journey a little bit more. Well, there’s going to be
parts that you click on where there is going to be delay. But some things don’t change. You want some visual anchor
elements that load fast and stay on screen,
such as the app shell, the logo, the search bar,
so that the user can always bail out if they feel like,
well, this search is taking too long, that wasn’t
what I was trying to do in the first place. And when you click on that
Back or that hamburger menu, they go back to exactly
where they were. So you can encourage
playfulness, right? They can browse, they
can not know exactly what they want, look around,
dive into the detail, come back to a generic
search results page before going any deeper. So this one kind of way
that single page apps, as well as new technologies
like service workers, can really help
you kind of build these types of
interesting experiences. This takes organizational
changes, potentially. A lot of the design
teams that we see, they design page by page mocks. So you’re looking at the final
mock of the results page, final mock, the item page. So we encourage really everyone
to work with their design teams, to think
about, are there ways to look at the transitions
between something, to figure out the null states. If there are no results, how
does that evolve potentially as results come in? And then think about how that
can help a user understand going from point A to
point B. Because again, going back to the journey,
it’s an analog line, not a discrete line, with a
bunch of individual points. That being said, I think at
this point a lot of people– I can’t see the live chat. But sometimes some
people say, well, we can’t do a single
page application, because it’s complicated. It’s going to– it might hurt
SEO, or something like that. And you don’t have
to necessarily create a single page application
to recreate this effect. A lot of multi-page
applications– so in this case this is [INAUDIBLE],, sorry
if I’m butchering that name, over in China, and they were
able to build a user interface where, again, by separating
the static content from the dynamic content, and
being able to cache that very basic skeleton screen. So that you can see,
on the right side, it’s a much slower CPU that
requires a full page load, it requires pulling in
data from the network. But they are able to get that
instantaneous kind of feel for a user so that
they don’t even perceive the load
less processing power that their mobile
device might have, because of fixed elements,
because of the smart loading screen, because of skeleton
screens that shows you what information should be
there, an icon, lines of text, things like that. All these small
little affordances really help a user figure
out and keep their bearings as they move through
your travel application. And so one last point before I
turn it back over it to Erica to talk a little bit more
about what the user journey is, I think another kind
of best practice is– here is, on the
right side, what’s wrong with this travel site? I think a lot of you
guys on the screen are probably thinking
of, well, OK, the fonts are probably different, and
it looks like things are just not consistent. What do I actually click on
if I want to select a flight? What happens if I click– is that a button, is
that a text field? We don’t know. And I think a lot of
these questions you don’t have to solve yourself. We don’t want to spend
time, especially, if you’re a small
company in this space, reinventing the wheel. And that’s something that you
can learn from native apps. So when you create
native apps, a lot of times you can just
use a native component for the sidebar, for the
menu, for a tab structure. You don’t want to
reinvent the wheel, because it wastes
engineering effort. And your users are probably
not used to this sort of tab structure, because
they’re probably used to a little bit more padding. They’re probably used
to larger tap targets and those kind of affordances. So I always refer
people building websites that might work
on a mobile phone to always turn back to
the Android user interface guideline, the iOS, Human– HCI guidelines, too. Because at the end of the day,
users who use a mobile phone is going to interact
with some application. They’re not going
to really– ideally, they’re not going to think
about what kind of technology is beyond the application. Why should the general user
experience expectations be different between native
application and their website? And I’ve seen sites where they
create a native application with a hamburger menu
on the left side. Their mobile web site
has a hamburger menu on the right side. And the typography’s different,
the padding might be different, and sometimes the call to
action sizes are different. Why is that different? You don’t want a
user, especially for sites that are trying to
actively drive the native app installs, to have to relearn a
completely new set of physics of your website when
they move over there. You should try to
do the same things so that when you do
innovate, the user only has to learn the things
that you want them to learn that matters to engaging
and converting on your site and not learning a new image– learning how to navigate
a new image carousel. So I think this is a good
point to talk a little bit more about users and
users expectations from a product level, and so
I’ll turn it back to Erica to talk a little bit more about
things like information input. ERICA TRITTSCHUH: Thanks Cheney. So when you’re thinking
about your site– I think we’ve said
it several times, but I will keep saying it– think like your traveler,
think like your user. Think about what will make
that research and engagement phase a lot faster and easier. So having a site
recognize where I am saves time, especially
when looking for flights. I am, you know, almost
99% of the time going to be looking for a flight
out of my home city, so being able to
pre-populate the From field so I don’t have to fill that
out is really important. The auto-suggest in search,
when I lived in London, I wanted to do a
trip to Reykjavik. I’m not such a good
speller for Reykjavik, but having the
auto-suggest and being able to autofill cities as long
as I started is a huge help. Another time saver here
that Cheney is showing is surfacing recent searches. So as we saw in that
customer journey for travel, people are bouncing back and
forth between different sites trying to price comparison,
trying to understand where they want to go. The research comes back
into play several times throughout that complex journey. So something a traveler
would find really useful is being able to come
back to your site. If they have made
several searches, come back to their
site and be able to see what they have
searched for previously and continue with
those searches. So you can see
that left example, maybe I want to come back to
a few of my hotel searches that I’ve already done. Or maybe I’ve made a
few flight searches, and I want to come back
to one of those easily. And this isn’t me
being signed in and having favorites
or anything like that, this is just cookie-based. And this will help
users save time. And another example is– you know, it’s great that
sites have– or often say, we have hundreds of thousands
of search results or hotels. Well, travelers don’t want
to sift through hundreds of thousands of results. We want to find what is relevant
to us at that specific time. Having really good search
and filter functionality is critical to travelers. So doing things that save
time like avoiding dropdowns. Don’t make me have
to push a dropdown in order to select two bedrooms,
like you saw right there. Just make it an easy
plus-minus button. It’s important to keep
the number of taps to a minimum to
complete an action. You don’t want to
make the traveler have to do 10 different taps in order
to get the results that they want. And then another thing
when thinking about travel, travel is very visual. It’s a very visual experience. Users want to see what they’re
getting before they commit. How many times do you want
to dig into that hotel room and really make sure that
their room looks exactly like you think it does? Allowing users to
zoom and expand images can really help with
engagement, as you see from the stat we’ve listed
from Expedia UK right there. However, as developers, you
know that beautiful imagery for travel can come at a cost. Cheney, can you maybe
share a few recommendations for how to think about
images as a developer? CHENEY TSAI: Yeah,
so I think you want to make sure that
images are always compressed. We find that a lot
of times you’re development team probably
has the best intentions. They don’t want to send
gigantic images to your website. But there’s often times
you’re passing along images from your graphic
design team, maybe they came from the marketing
team, they probably make a last minute edit
before they upload it somewhere through some
CMS, and that shows up on the page somewhere. They can’t go to the
developer every time to say, oh, we have a new
image, and so please upload it. Most likely, it’s probably being
done automatically in some way. These are areas where you
start seeing images that are just simply way too large. Because you’re sending
it down like 1,000 by 2000 pixels
for something that exists on a mobile device,
where you simply don’t even need that much data
for image fidelity. Situations where
you don’t want to– sometimes, it’s
better to send down a thumbnail, a
much smaller image, as well as a chance for
the user to click through to see the higher resolution
image after a click, instead of saying, well,
let’s just send down this large image. So let’s take this
example as something to talk through, where you can
probably send down a smaller sized image, because you don’t
know if the user is necessarily going to click through and
actually expand and zoom. So then you can lazy load
some of those things. So try to load image
sizes on demand, because you will find that,
from a technical perspective, if you take something that’s
500 times 1,000 pixels, you try to size it down to
something that’s like a third the size, well, the
browser is still having to calculate and work
through all of those pixels. And that’s going to make
your page feel slower, suddenly your site slows
down, your carousel doesn’t swipe to user gestures
and things like that. And I think that’s
a great point there. So that takes us to kind of
like the end of the conversion flow, which is, OK, the
user kind of has researched, they’ve made a decision
about what to do. I think a lot of times this is
an area where you might pass it to a different team. Maybe there’s a legacy
checkout system, maybe there’s a whole
other team that’s actually working on checkout. And we see that as a
really lost opportunity for a lot of travel
sites, and really any sort of e-commerce
site, where maybe you have a great experience
getting the users, one, used to your user interface. They know where things are, and
now you want them to convert. And suddenly they’re
taken, potentially, to a different site. Maybe you’re going from
www.mytravelsite.com to payments.mytravelsite.com,
or in this case secure.mytravelsite.com. You’ll find that
on some browsers, there are slight animations
that show to the user, oh, you’re actually going to
a completely different site. Or potentially, if you had a
single page app beforehand, and then you click
over to checking out, well, now you’re potentially– the user is seeing that,
wait, I’m leaving your site, I’m going somewhere else, to
have to recheck and reaffirm that they trust this
new destination. And those are all
situations where you’re now distracting the
users from completing whatever task you want to do. And the second thing that
everyone’s probably aware of is form fill. And I think Erica
talked a little bit more about early on, when you’re
doing searching and filtering, there’s a lot of best
practices you can do there to make that easier for a user. You want it to be fast, you want
to encourage filling in things and relying on recent searches. Well, same thing,
you probably typed in your payment information
before, maybe on this same site or maybe on a previous site. So think about leveraging
different signals. Maybe it’s the normal Chrome
or any other browser space autofill selection
to fill in addresses. Let the user be able
to select those things. So basically, tag your
input fields correctly so that Chrome can match up form
fields to other common forms that have been saved. But a lot times, if
it’s a return user, well make sure
that you’re reusing a lot of their previously
entered responses. If they told you as a
brand what their name is, what their addresses, other
information, have them confirm with one tab. Never get into a situation
where you’re asking again, if at all possible. And so we do have, on
the other side of things, about the other form field
based UX that’s really, really annoying, which is identity. Every travel site we talked to
loves the user to be signed in. But other than maybe your
most frequented travel site, you’re probably not going to
be signed in in a lot of times on– for maybe like, I’m
traveling to Europe. I need to get like
a Eurorail pass or something like that, that’s
probably the first I’m there. But maybe I did some
research on the desktop, and I’m signed in in Chrome. The problem is,
a lot of times is the expectation is
that, well, I now have a relationship with your brand. I’ve used you on
the desktop device, I’ve moved over to
the mobile phone, and you don’t know who I am? I need a sign in again? I need to type my password,
what was that again? How do I go type a pound
sign on my keyboard. That’s potentially areas where
you really confuse a user. So at Chrome Dev
Summit this year, we did start talking about this
one tap sign up, sign in flow. You can learn more about it at
our Google Developers web site. But the idea is we can use
Google to help the user sign into your site. Maybe it’s because they’ve
signed in and created an account with
you already and we know that, because they’ve
done so on desktops. And when they come to you,
in this case, wego.com, on your mobile phone, we
need to simply say, hey, do you want to sign in using
your previous credentials? And you can just click through,
Continue, and you’re done. And the best part
about this is– one of the big
problems about identity is that, when do you actually
ask users to sign in, early on, so that you
can tie it together, so you can do recent
search results. But that might be
a blocker for them. Maybe much later, when
they’re about to convert, but maybe that means that you’re
adding a complete other step to the checkout funnel, and
they’re not checking out. Or maybe that they
get to the point where they don’t remember
their credentials, and they just click
Continue as Guest, and then suddenly it just looks
like a complete new user, which you can’t personalize for. So this is a great
way of, one, allowing them to remember
their credentials, but two, also without
having to move them to a complete
different sign in page, allowing them to sign in right
on whatever context they are. So if you already have
them about wanting to engage somewhere, wanting
to make a stay at this hotel, they don’t need to leave. They don’t need to stop
seeing whatever made them want to sign up in the first place. And you need to sign up,
sign them up, or sign them in at that moment. And the other side obviously,
payment, just as a quick shout out here to some of
the web payments work that’s been going on across the web. And what you see here is
a Payment Request sheet that browsers can implement. And so a lot of times
as web developers, we spend time creating
our own form fields, and these potentially break. And from site to site,
these checkout forms are probably different. The user is probably really– they get in the situation
where they’re not quite sure how
this is different, am I clicking on
the right thing. There’s an error, then they’re
scrolling back and forth. Or you have JavaScript that’s
making the page unresponsive, so they can’t even fill it out. The Payment Request
here allows the browser to basically say, well, we
know a lot of the information already, so why don’t we
help the user by showing the native render sheet from the
bottom of the page that allows you to quickly get that payment
method, get that address, and make a quick checkout. And you just get the– you get to do a checkout
normally as you normally would, but this is just a layer
that sits on top of that. And so there’s a lot
of different ways of kind of like walking through
some of the common things that a user might react to
as they’re going from landing on your page, going all the
way through being signed in, to checking out. And then I think after
that is, well, what if they didn’t purchase immediately? What if they were watching
the cost of the flight, and they need to come back
in a couple of hours, a week, something like that? So then you want
to set up your site to make sure that the second
experience, third experience is still great. And so I think, one,
some of the work with the purpose of web
apps, things like that, is to make those
previously features that you associate with native
apps possible on the web. The things like
active home screen, things like push
notifications are all now becoming more and more
accessible on the modern web. And you can start thinking
about how this might change how you build your product. You can start building really
interesting ways of re-engaging the user, because they
looked at a flight before, they didn’t
purchase immediately, and you know that
the price dropped or there’s a deal you want
to specifically target to the user. So this way you can
have a way for them to basically be enticed
to come back to the site or encourage them to add
your site to the home screen on Android
devices, and then have them be able to
see that and come back in on their own will. Erica, do you have any
other comments on kind of like different
ways that brands might be able to build more
interesting experiences to re-egage users? ERICA TRITTSCHUH:
Thanks, Cheney. I was thinking pretty much
exactly what you said. I mean, all of these
experiences that we talked about up until now,
the discovery, the research, the conversion, all
of these phases, they all are helping lead to whether
the user has a good experience or not. Did you give that traveler
an experience that makes them want to come back? And I think we all in travel
want to have loyal users. But it’s really
up to you and how you deliver that experience
for whether the user wants to come back and become
loyal to your brand. And exactly as Cheney said, when
I speak to travel companies, they say, oh, we need
our loyal customers. We want to really push this
from our native application. And that’s where we can
really engage with our users. But with these great, new
modern web technologies, such as progressive web
apps that Cheney mentioned, you really can do a
lot of this engagement with your mobile web
application that you previously couldn’t, so getting
this push notification. And there’s a great case
study if you haven’t seen it from Trivago that shows
the great success they’ve had in using a
progressive web app from this engagement standpoint. So they have utilized
the push notifications and seen, you know, that
their push notifications subscriptions have eclipsed
email subscriptions. That’s pretty big,
and that they’re able to get users to
add to the home screen. So there are ways to get that
same great engagement that you used to only get from
your native application now on your MWeb application. And I’ll hand it out to you,
Cheney, to wrap this up. CHENEY TSAI: Yeah,
so obviously we didn’t cover a lot
of, I guess, answers. There’s no quick tricks
to really kind of take your site to the next level. A lot of this requires
prioritization through having good hypotheses
about what to actually build. You can test A, and
test B, and both can be poor hypotheses,
because they are built on poor assumptions. And one might convert
better than the other, but it might not
actually be something that’s actually meeting your
business’s overall goals. Another thing to think about is,
you’ll spend time prioritizing performance, right? You want to prioritize– as your
site grows, because you went from that house over
to a skyscraper, you can’t use the same
foundation as the old house. But a lot of times, from
a product perspective, we get so caught up in building
the new features that we don’t go back and think about,
well, how can we actually make this feel great, make the
user journey consistent, so that this doesn’t feel like
a Frankenstein sort of product, that we don’t have a bunch
of new modern pages stitched to legacy pages that feel like
a completely different site. Those are all going
to be things that count against you, which might
not be completely evident. So we have a couple tools
and just quick tips. One of the common tools,
that if you use Chrome, inside the Audit panel
inside Chrome DevTools, there is a tool
called Lighthouse. This is a relatively
new tool that gives you a report that goes through
a lot of the best practices from accessibility, to
speed, from whether you’re taking advantage of
modern technologies, like service worker. And you can think of
this as a checklist of going through and
making sure if your site is meeting user expectations. We don’t see it here, but one
of the things that does come up very often is you can
actually look at your Time to Interactive score
using this report. It tells you on
a average device, is your page
actually interactive. And for a lot of sites, you’re
going to see 10,000 and higher. So basically, 10 seconds where
the site was not actually usable by any user. So track that and try to
make your releases improve on those measures if possible. And from a product
perspective, the things you actually change
on the page, again, don’t try to cram
everything into the page. The user– you don’t want your
site to be a glorified flyer. You want it to be an
application, something the user can engage with. So that means that
you’re going to need to make hard choices about
what to actually include, how to show those things. We don’t have the answers in
terms of what to actually do, so you can do A/B testing. We obviously have Optimize as
a Google-based tool to do that, to test those hypotheses. And you can quickly see how
that can help your bounce rates drop, your engagements go up,
and conversions potentially go up also. So that leaves us
with about 12 minutes or so for questions
and discussions. Hopefully this was a whirlwind
tour over some of the concepts that we do face quite
often in the travel space. And I think we have
some time for questions. So I will kick it
back over to Dennis and Dom really quickly to see
if there’s anything out there. DOM HEYBERG: Well, cool. First of all, thanks
Cheney, and thanks Erica for taking the time to
provide such great content to the viewers. I know it’s early over in
the US, so thanks a lot. I had a look at the
questions of the live chat. There doesn’t seem to be
a lot of questions, which is hopefully a good thing. There were some
questions about links to the Android UI guidelines,
the iOS guidelines. And also we posted a Medium link
that apparently returned a 44. So to everyone, we’re
making sure to post these links now
or in the comments so that they’re
available to you. We’ll probably do
it in the comments, because the live
chat will disappear when the launch is finished. So we’ll give you guys
another five minutes, if you have anything
that’s on your mind, please type it away right now. We still have Cheney
and Erica in the stream, so definitely make use of that. Other than that, I will
give it over to Dennis and see what Dublin has to say. DENNIS RASPOTNIG:
Well thanks, Dom. First of all, thank you, Cheney
and Erica, great presentation, great insights from
mobile, travel UX, and, well, UX in general. So thank you for that. Yeah, I don’t have
anything to add. You’re the specialists here. I think you covered
a lot of stuff. If there are no
questions in chat, it would be great if you
sign up at our event page. This is where you
can give us feedback. This is where you can
potentially reach out to us and where we can
also post links. As Dom said, we also
try and post them in the comments below. And in the comments,
you will also find already our event page. So it would be great if you
guys could sign up there. And I think that’s– CHENEY TSAI: And feel free
to reach out on Twitter if you have any
questions afterwards, and we will try to respond. DENNIS RASPOTNIG:
Yes, excellent point. Yeah, with that, I
think we’re pretty much done for this session. Again, thank you very much,
wishing you a nice holiday season, a nice Christmas
or whatever your celebrate, or just a nice time off
from work hopefully. And we’ll see you
in the new year with our next Hackathon
on Air live stream, probably around the
23rd of January. But again, if you
sign up at our page, you’ll get a nice
confirmation email. We’ll send you one
or two reminders. OK, I think that’s it. Thank you very much. Thank you guys, and
see you soon, bye-bye. CHENEY TSAI: Thanks, bye-bye. DOM HEYBERG: Merry
Christmas, everyone.

One thought on “Google Hackathon on AIR – Great travel experiences on small screens”

Leave a Reply

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