 Hi everyone, it's Tom and Dennis again and welcome to our last and final hack thumbnail for this year. We thought we'd do a little bit special this time and we invited two experts from the US, Chaney and Erika, 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 user experience on the mobile device. Today we have a lot of people in the stream, so it's myself, it's Dennis and Dublin, it's Chaney and Erika in the US, so we have to switch back and forth from one. 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 from me for now and I'll give over to Dublin to Dennis. Hello everybody and thanks Tom, just a quick hello from Dublin also to add on Tom's intro. Please let us know if the audience is alright and everything, so just type in the 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 like introduce you to our mobile experts from the US. So first up I want to introduce you to Chaney who it hits if I'm not incorrect in New York. So let's send it over to Chaney. Hi, Chaney. Alright, thank you. So my name is Chaney. I used to sit in New York, so you're partially correct, usually based in Mountain View by 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 kind of has come up in some of our past conversations. And hi, everyone. I'm Erica Trichu. I've been working at Google for 11 years all in the travel industry. I am a 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, you know, 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 in a site, and it's important to reduce that friction, to assist the traveler whenever they're, you know, accomplishing a task. And it's whichever task they want to do. And another thing to think about is the travelers are on the go. They are, you know, 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 agree that they always use their smartphones 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 U.S., 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, you know, 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 there 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, you know, 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 this 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, you know, 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, you know, 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. Cool. Thanks, Erica. So I like to kind of like, before we dive into kind of nitty gritty details, JavaScript and all that kind of stuff, kind of 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, you know, any user can probably go through. You're probably coming in, like, you know, 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, you know, a different place. So it's kind of like, I like to use this house analogy where you're just kind of window shopping, you're looking at a house or the thing, you know, that looks great from the outside. But for a travel user, a lot of that is, it doesn't stop at the front door. You kind of need to go through the house or some sort of task completion, right? Because you, you know, left your keys in, you know, 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 website, 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 KSL. We need to add a wafer users to X, Y and Z. While 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, you know, a nice house. And for a lot of travel sites, it's not a simple college in the woods where you don't need a very strong foundation. It's much like a skyscraper where you need to dig, you know, something that's like, I don't know, however many meters deep at, you know, 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 to function well, really requires a nice ground foundation. So I like to use this kind of like analogy here. Now I'll probably refer back to this in a little bit where, you know, the house you envision when the designer gives you a mug. 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 with the left side where, oh, I tried to click on this link, the page flashed white, things were moving around. I was trying to swipe this carousel and for some reason the animation wasn't quite trapped 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 into 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, right, 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've joined on previous hackers on air, you're probably used to the idea of you want your page to load fast. Sightspeed 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, things like elements on the page moving around, things sliding up and down, things being loaded really slowly, but then popping up suddenly like interstitial to sign up for a newsletter or add your application that kind of takes over the entire screen. There's all things that kind of 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 AB testing third party partner and you decided not to use them anymore. So many sites we see out there, they just naively kind of 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 these stats before, 53% of users will be on a page that takes more than three seconds to load. And the truth of this, if you look into the data from like so-so and things like that, you'll find that a lot of these speaking actually even happened way below that five second mark. It's not improving from 10 seconds to five seconds. We see that, you know, the effect on abandonment, on engagement really accelerates as you move faster towards that one second piece. So again, shout out to, you know, you can click the Google link here to check out the previous hackathons on errors about how to make your site show up as fast as you can. We're going to be talking about the 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, you know, 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, right? 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 a search results or maybe something from a Twitter share saying, check out these three awesome things to do in the 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 of 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? That, if you spend time loading things there, that's going to affect that very, very first metric. 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 pull things from like six different servers. But at the end of the day, we see teams having to struggle with prioritization. Too many parts of the company want to make sure that their feature, their subcategory maybe is 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 of actions before they even start scrolling and that's going to hurt the chances of someone moving down a funnel. So, let's think about enabling repeated searching and exploration, right? Because 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, auto-complete something at the top of the page, help them refine, but after they refine, 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, you know, from a technical perspective, you say, well, okay, 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, okay, the page is going to flash white and then we're going to start loading in JavaScript, start loading in more images than CSS, right? You could optimize that to be loading as fast as, you know, 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 user is going to do before they get to some point of value to your business, to booking something to, finding that strain schedule to do any of that? It's very well, like, at least four clicks, not even counting the things that they have to type into any sort of form fields. 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, you know, websites 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 Adios Monty for Mark Krim dev role team. So you feel free to Google that. It's a great 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've found online because it's a package that you rely on because it's helping you manage state, it's helping you build application-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 your 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 is 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 because it's been free downloaded. So what happens is if you look at the bottom here, you wait for the JavaScript to be requested, it arrives, it probably executes which is the yellow bar here. After that execution time, then it fetches content that you might need a lot. 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 the user is swiping, activating things that you've created an event handler to really react to. So a lot of times when we talk about speed, we don't actually consider the yellow portions here. We just think about requesting everything is content loaded. And at this point, at the end of this blue bar we typically say, oh, okay, the user should, the site speed it's done, it's everything's loaded, the user should be able to use everything. And for new websites that might be true. But for travel, especially on very small screens, the user's going to try to do something. They always scroll, they're always gonna tap something because they're so purpose driven. The problem is there's all this time before JavaScript has actually been evaluated in parts to actually react to that user input. And one of the things that I like to kind of point out is optimizations usually say, okay, do you zip 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 before and then executed before your page can actually do anything in response 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 gore fly flyer. It's something that you print it out, put an image up and left it on the screen and you create this content 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 as 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, you know, a font slightly different. It's not that an element field looks broken. It's just they're trying to use with 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 a model G, even something like an iPhone 8, you know, for a lot of script times this data was thanks to the hat meaning for pulling some of this. But a lot of the script times is because it's non-trivial. You know, a megabyte of JavaScript might even take up to 500 milliseconds to actually be fully parsed and executed on an iPhone 7 and iPhone 8. And that's gonna be a time where the user is probably trying to tap on something and you can't quite respond with the same expectations that they're used to using their native applications. And that's gonna be reason why they bounce, why they stop engaging and they create this mental model over time about, okay, every single thing I do has a cost associated with it. And, you know, if I click on something incorrectly because you tap on something, you thought it was gonna 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 costs of loading the page again. So in the future, they're probably gonna 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? And this whole, you know, well, how can we optimize for a UX where users are gonna do a lot of things where they, you want to kind of move, instead of moving from page to page, you want to build around user flips. 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 gonna be that exact set of data. Potentially you're gonna 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 a identity page, a login page, to a browse page, to a payment flow. That could all live inside a single page application. And one of the common patterns that we generally encourage people 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 four things about native app, obviously, is that you have to download everything, and that's the 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 it's part of the webpage that requires change without going through the entire previous process of loading everything, writing parsing more JavaScript, downloading more things. So this is one of the common ways in which we see 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 kind of 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 to, as I said, I think that normal websites have to native applications. When you do a site search, there's an expectation that the, there's some work being done in the background, or you could click on, I wanna look at more, like in this Japanese example here, I wanna look at more of this, I'm not sure if that's a hotel or Airbnb, but I wanna see more of it. Typically, a website would say, I got your user input, I'm gonna do nothing. I'm just gonna 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 three to 10 seconds later, depending on your network connection, we're gonna flash that screen white and we're gonna take you someplace different. It's basically as if you teleport 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 gonna be like, what just happened? Where was I? I thought, well, what was I doing again? Those thoughts, again, are getting in the way between you and completing that transaction. I think Flipkart's a progress web app here that kind of tries to think about the user journey a little bit more. Well, there's gonna be parts that you click on where there is gonna 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, it could go back to exactly where they were. So you can encourage playfulness. 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 is 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. And 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 of the item page. So we encourage really everyone to work with your designs 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 it live chat, but sometimes some people say, well, we can't do a single page application because it's complicated, it might hurt SEO, or something like that. And you don't have to consistently create a single page application to recreate this effect. A lot of multi-page applications, so in this case, this is Ella, me, sorry if I'm butchering that name, over in China. And they were able to build a user interface where, again, by just 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, requires pulling in data from the network, but they're able to get that instantaneous feel for a user so that they don't even perceive the less processing power that their mobile device might have because of fixed elements, because of a smart loading screen, because of skeleton screens that shows you what information should be there, an icon, lines of text or 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 to kind of Eric and to talk a little bit more about the user journey is, I think another comment in the best practices, here's 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, okay, the fonts are probably different. It looks like things are just not consistent. A lot, what do I actually click on if I want to select the flight? Like 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 the space, reinventing the wheel. Take advantage, 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, right? You don't want to reinvent a 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 kinds of affordances. So I always refer people building websites that might work on their mobile phone to always turn back to the Android UI, user interface guidelines, the iOS human HCI guidelines too. Just because at the end of the day, users who use a mobile phone is going to interact with some application. They're not gonna really, ideally they're not gonna think about what kind of technology is behind the application. Why should the general user experience expectations be different between a native application and their website? And I've seen sites where they create a native application with a hamburger menu on the website. Their mobile website has a hamburger menu on the right side. And the typography is different. The padding might be different. And sometimes the call to action sizes are different, but 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. Or you should try to do the same thing so that when you do innovate, the user only has to learn the things that you want them to learn that it matters to engaging and converting on your site and not learning how to navigate a new image carousel. So I think this is a good point to talk a little bit more about kind of users and users' expectations from a product level. And so I'll turn it back to Eric. I'll talk a little bit more about things like information input. Thanks, Janie. 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 almost 99% of the time I'm 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 and 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 auto fill cities as long as I start is a huge help. Another time saver here that Janie 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 do price comparison, trying to understand where they want to go. The research comes back into place 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 my favorites or anything like that. This is just cookie based and this will help users save time. And another example is, 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 save 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 making 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 the 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 Xpia 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? Yeah, so I think, you know, you want to make sure that images are always compressed. We find that a lot of times, your development team probably has the best intention. They don't want to send gigantic images to your website, but there's oftentimes you're passing along images from your graphic design team. Maybe it came from the marketing team and probably make a last minute edit before they upload it somewhere through some CMS that shows up on the page somewhere. They can't go to a 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 kind of are areas where you start seeing images that are just simply way too large because you're sending it down like 1,000 by 2,000 pixels for something that exists in a mobile device where you simply don't even need that much data for image fidelity. Situations where you don't want to, you know, 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'll 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 of the size, well, the browser is still having to calculate and work through all of those pixels and that's gonna 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, okay, 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 another 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 site animations that show to the user, you're actually going to a completely different site. Or potentially if you had a single page app beforehand, well then you click over to checking out. Well now you're potentially, the user is seeing that way, I'm leaving your site, I'm going somewhere else, they 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, Eric, I 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. If you want that 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, or maybe on the same site or maybe on the previous site. And so think about leveraging different signals. Maybe it's the normal Chrome or any other browser space, all the fill selection to fill in addresses, let the user be able to select those things. So it basically tagged your input fields correctly so that Chrome can match up form fields to other common forms that have been saved. But a lot of times it's, 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 address is, the other information, have them confirm with one tap, but never get into a situation where you're asking again if at all possible. And so we do have another side of things about the other form field-based UX that's really, really annoying, which is identity. Every travel site we talk to loves the user to be signed in. But for other than maybe your most frequented travel site, you're probably not going to be signed in a lot of times 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 time 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've now had 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 to sign in again and 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're really confusing a user. So I chromed up some of this here. We did kind of start talking about this one tap, sign up, sign in flow. We can learn more about it at our Google Developers website. But the idea is, we can help you use Google to help the user sign into your site. Maybe it's because they've signed in and created an account with you or writing, 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 another 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 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 that. They don't need to see, to stop seeing whatever made them want to sign up in the first place. And you can just sign up, sign them up or sign them in at that moment. On 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 begin the situation where they're not quite sure how this is different and my click on the right thing. Oh, there's an error where 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. So 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 a native rendered 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. This is just a layer that sits on top of that. And so there's all different ways of kind of like a walking through some of the common things that a user might react to as they're going from landing on your page we'll 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 washing the cost of the flight and they need to come back in a couple hours, a week or something like that? So then you want to set up your site to make sure that the second experience, the third experience is still great. And so I think, well, some of the work with the progress of web apps and 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 a user because they look at a flight before they didn't purchase immediately and you know that the price dropped or there's a deal you want 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 for re-engaged users? Thanks, Janie. I was thinking pretty much exactly what you said. I mean, all of these experiences that we talked about up until now in 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 Janie 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 Janie 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 Travago that shows the great success they've had using a progressive web app. From this engagement standpoint. So they have utilized the push notifications and seen that their push notification 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 M web application. And I'll hand it out to you, Janie, to wrap us up. Yeah, so obviously we didn't cover a lot of, I guess, answers. There's no quick tricks to really kind of like take your site to the next level. A lot of this requires prioritization for having good hypotheses about what to actually build. You know, you can test A and test B and both could be poor hypotheses because they're built on poor assumptions and one might convert better than the other but it might now actually be something that's actually meeting your business's overall goals. And another thing to kind of think about is 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 gonna be things that count against you which might not be completely evident. So, we have a couple of tools and just quick tips is 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, from speed, from where 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. One of the, 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 that tells you on a average device, is your page actually interactive? And for a lot of sites, you're gonna 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 metrics as possible. And then 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 so that the user can engage with. So, that means that you're gonna 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 optimized as a Google-based tool to do that and test those hypotheses and you can quickly see how that can help your bounce rates drop, your engagement go up, and conversions potentially go up also. So, that leaves up with about 12 minutes or so for questions and discussions. Hopefully, this was a whirlwind tour over some of the concepts that we do space 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. Well, cool. First of all, thanks, Cheney, and thanks, Erika, 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 at 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 the medium link that apparently returned a four-four. 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 last room 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 them, Cheney and Erika, in the stream, so definitely make use of that. Other than that, I will give it over to Dennis and see what Dom has to say. Well, thanks, Dom, and first of all, thank you, Cheney and Erika. Great presentation, great insights from Mobile, TravelUX 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've covered a lot of stuff. If there are no questions in the 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'll 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... And feel free to reach out on Twitter if you have any questions afterwards and we will try to respond. Yeah, excellent point. Yeah, with that, I think we're pretty much done for the session. Again, thank you very much. Wishing you a nice holiday season, a nice Christmas or whatever you celebrate or just a nice time off from work, hopefully. And we'll see you in a new year of our next Techathon on Air Livestream, probably around the 23rd of January. But again, if you sign up at our page, you'll get a nice confirmation mail and we'll send you one or two reminders. Okay, I think that's it. Thank you very much. Thank you guys and see you soon. Bye-bye. Thanks, bye-bye. Merry Christmas, everyone.