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.  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?  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.  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.  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?  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.  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.  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?  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.  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.


We're heading into where we're headed now and where this is to set you up for tomorrow's session. So now, Dad, I got to call on you. We're a little bit over time, so we're going to have to sort of synthesize many thoughts into about a half an hour. I didn't bring my synthesizer. And as I mentioned, we're going to, immediately after, we can go down the stairs to a restaurant called Joyce. If that interests you, we're just facilitating that. It's not required. It's not part of the opportunity for you that you can take advantage of.  We reinforce sort of the different threads that we've seen introduced before we get into a more regulatory approach to work. Great. Thank you. All right. So the title that I noticed on the program involved sovereignty and, specifically, it was some fireside chat sovereignty in a blockchain world. And then I think we added in integration of the use case, so just to use that again to have something that we can, that's familiar that we can apply. So when I think of the word sovereignty in a blockchain context, the first thing that comes to mind is identity as Amy foreshadowed. So just a quick show of hands. Who here has heard the phrase self sovereign identity, but a small minority. So who here has heard people talk about or you read something to the effect that blockchain can be used not only as a ledger, a distributed ledger for cryptocurrency, but also for digital identity for identity somehow. That's more a little bit under half. So I want to talk about that a little bit to take the sovereignty box. The basic thinking here is that the fact that blockchains are built upon addresses for all the participants that contain public keys for a key pair that the participant has themselves generated like on their own software. And that the participant, let's say owns and controls, so they only control that private key that's part of the gestalt of his vision that the Satoshi vision of self organizing. They're free people in free markets that can self organize and govern themselves. Part of the technical expression of that is the key generation occurs on your phone or on your laptop, for example, as opposed to say something like maybe in other financial services like home banking or other encrypted sessions on the web. So if cryptography isn't involved, public key cryptography is involved, but it's happening really kind of server to server or business to business layer and keys are sort of allocated session by session and frequently. Maybe there's a server certificate, but individuals are not expected to or not even enable to generate their own public private key pair, manage their private key and be known by that as an address or be able to sign things on their own behalf. Like a contract or to a consent. It's a different paradigm and you can use services online like we can use DocuSign. It's a perfectly good way to generate a digital signature or an electronic signature. We can do other things, but in a sense the highest bar of individual user centered identity is when the state of the art of technology today is when an individual has generated their own public private key bear and has made the public keep public in some ways so that people can communicate with them and can authenticate that they're the party at the other side of a transaction. So, based on that starting point, a number of people realize that the key pairs that anybody can generate and manage using a blockchain wallet for cryptocurrency like Bitcoin or Ethereum can also serve not just to identify them as the equivalent of an account holder conducting a financial transaction, but also as an individual person. And so, part of applying that idea to see how far you can go with that was that prototype I showed with a mock trial of seeing what could we sign a run of the day contract for sale of a car. Could I sign a papers with my local city council, I wanted to run for city council as my signature, you know, on my own behalf. Could I provide a consent to some kind. I think the answer fundamentally is yes, it's technically an elegant solution. It's there we have this sort of globally accessible, massively distributed research that acts almost like a meta enterprise layer to do key management distribution. That's one of the core capabilities. Some of the core functionality of the blockchain. We never had that before. The worst technology for cryptography that individuals could use has been for decades. Remember in the 90s, we use PGP a lot at MIT PGP pretty good privacy. And it's uses some you can generate a key pair. We had wallets, which we call key chains and the way we exchange keys with one another is we went to parties, not the Hollywood kind. No, no. I'd say even in some ways even more fun because we super get down and it was great and we could securely authenticate with each other the next morning if we wanted to. I shouldn't push that. Anyway, and at the key party, the big thing we would do what we have fun and just be ridiculous, but then we would also exchange keys. So I would know that Sally, that's John, that's David, that's Jane, I bought his or her key and I put it in my address book. I am quite certain that this key corresponds to the private key by that person because we did an in-person key exchange. It's a really good way to do it. And then thereafter they could be on all sorts of very insecure networks on the internet or worse yet the MIT network were just hacked to bits by freshmen every year. And I know whatever else happened if I got a message from that person and I could verify it with their corresponding public key, it came from that person. And conversely, if I wanted to make sure something got to that person, I could encrypt it with their public key and only they could decrypt it. Only the corresponding key can decrypt something encrypted with one key. That's the whole stick with public key cryptography. So that doesn't scale. And number one, PGP and other things. No one has figured out how to make that easy. PGP was hard. There's been any number of other startups and open source projects that have tried to make it possible for individuals to generate key pairs and to manage them. No one's figured it out.  They just click a couple of buttons and whiz bang, I've generated a key pair and it works pretty well. You know, it's not like they're the most secure things in the world, but you know, by the current information security standards for mobile phones and for laptops, it's pretty good to protect the private key material. We call it, like, you have to, someone has to concentrate some resources to go after you in order to get that. And so it's purport, I would call it purport, way better than anything that came before. Let me put it like that. And really usable, which is the most important thing for key management. It can be very complicated to make things secure, very costly. This stuff was neither costly nor complicated. So fast forward a little bit in another year or two. And now people with more philosophical and political agendas, maybe, and that may not be a bad way necessarily, who were more kind of libertarian or something like that felt that we could really lean upon blockchains and their key management capability to be a source of identity of free people, fundamental. I don't think I'm overstating that. So then in the digital world, we could create and maintain our own identities. In the fiscal world, you know, thinking back some of the border to revolutionary times in the United States, you know, we would use paper signatures. So if I think about the Declaration of Independence and I think about my own town, I grew up mostly in Lexington, Massachusetts, outside of Boston. We've had a continuous town meeting where if you pay taxes, excuse me, if you live in the town and are registered to vote, you can show up to like the gymnasium or the city hall, the town hall once a year and have an equal vote for how we'll be allocating local taxes and fire police and what are we doing with the reservoir, roads, that kind of thing. It's an open town meeting, not so different from how it's been done for a long time. It relies upon identity, but it's implied. So if a person shows up and you can look them in the eye and if they've signed something and we can sort of eyeball the signatures, is it similar to the tax assessment or similar to the voter registration? These are the ways that we've done authentication in the past, impliedly. You can, you know, push it in terms of like signature and forgery and like, there's deeper science to it, but fundamentally society-wide. What I'm saying probably rings true for people that are not very, very young where some of this is actually not, you may not be familiar with when talking about where everything's been digital, born digital, younger people. But we don't have a way to express our own individual identities in this born digital world. You know, we have identity, but they're not ours. I have an identity when I go to MIT. It's an Athena account. I log into the network. I have an identity at General Electric. I've got an identity at various governments and various terminals and I kind of sit down and I log in. The identity was allocated to me. Or sometimes I'm on the other side of the transaction. I'm not getting an X500 directory or a Windows Active Directory or something like that and I create an account for the first day of a new hire or for a partner or whatever. We give people identity and we receive identity from others. We receive it from Google. We receive it from Facebook. We receive it from government agencies. We receive it from banks. We receive it from our employers. But where I ask you is our own identity in the digital world. On the one hand, everything we do is going digital. We're paying our taxes online. We're being educated online.  Where's the camera? Wherever you are in internet land. Oh, there you are. You are online. So you're getting educated online. Oh, and there you are. You're everywhere. And we are doing commerce online. We're doing healthcare, increasingly medical online. Every facet of the economy, banking, every aspect of our lives are increasingly occurring online, like the authoritative actions and behaviors are occurring online. I don't have any problem with that. I like that for many things. But it does where it should trigger some questions. Like how about our identity? Are we also kind of transcoding that online in a way that supports and reflects the basic social compact of what we could expect from our own identities up to now in history, up to this point in history. So here's going to give a couple of specific examples of things that might be possible with an identity that's digital that people own and control, which could be afforded by blockchain, that could be legitimate, people own and control them, but may be insufficient if the identity is allocated to us by others. So the basic social compact, I think, kind of post-enlightenment, actually, this is a little funny because you still sort of have the Queen as a sovereign if I'm not mistaken. So adjusting for that, if you'll go with me that far for a moment, is that people consent to be governed. And it is from that consent that the legitimacy of the government derives that's kind of the cromwell, the enlightenment to just block those kind of people. And we say in the United States, at least, that the sovereignty derives from people, from the individuals in the aggregate are the sovereign, and the government is not just born with the right to govern. And we can change the government. This is explicit. But how do you provide consent? So that's the big case, but you could have smaller cases. Like the government really has a need to check some new drugs out. You know, it's important public health.  Okay, so do we need a consent for human subject experimentation? Yeah, we do. You know, post-Nuremberg and some fourth, human rights. So when you have a consent based on human rights, from whence are you consenting? There's something a little funny when you go to a doctor and they provide you the mechanism to provide consent back to them. You go to a government and they provide you the mechanism to provide consent back to them. You go to a commercial merchant, they provide you the mechanism of the identity mechanism and authorization service to provide consent back to them. This is actually a little bit weird when you think of it. Consent, fundamentally, I'm speaking like putting my lawyer hat on now, just imagine, and I'm sure I brought two hats, is a two-party transaction. One cannot consent to oneself. It's a different kind of thing. You can decide something for yourself, but consent requires two or more parties. Does that make sense? So there's something hinky about one party holding all the cards and being able to basically, for all intents and purposes, generate or in the bad day concoct what had happened after the fact about with consents and server logs. When it's supposed to be, when the consent's supposed to be coming at an arm's length, they're away from an external party. Somehow we need to have a meeting between parties and each party needs to be responsible and accountable for, but also have the right to utilize their own method to come to that party and their own method to provide consent. You could agree, you know, what flavor. We're going to do this with digital signatures or maybe we're going to do it with biometrics. Like, that's fine. But what I'm talking about fundamentally is having a capability individually to sign something on your own behalf and that you completely own and control. This is kind of core to the post-enlightenment age. There's a big gaping hole in technology where that, I would say, those design requirements are supposed to be fulfilled as we're doing more and more important stuff online. Maybe some people think that blockchain could be utilized like the key pair of blockchain could be utilized as a mechanism for people to express their identity in a way that's usable for online transactions and for other times when you need to express an identity and you need to log in, you need to authorize an integration between the service and that service like my Dropbox to my Outlook or what have you or when you need to provide consent up in the ante a little bit. So that's the idea of so-called self-sovereign identity. In the media lab, at least in the research group that I'm in in the last couple-ish years, we've been using a less charged, almost political slogan from the self-sovereign identity and we're calling it self-sourced identity and just trying to keep it a little more, you know, a little less hyperbolic, I guess, and talk about identity that sources from the person identified. I think that's more accurate, I think, and less dramatic way to talk about it. But self-sovereign identity, if you Google that and encourage it, go all to Google that at some point.  It's a good thing to be looking at. You know, I think we're generations of a way of maturity model, sort of grand-arc technology adoption in the sky from having this stuff really ready for things like I signed my affidavit and I attested this tax statement or I, you know, consent to medical procedures or to be governed. Like, we're going to have to, this stuff will have to be even better than the blockchain one. Good, though, that may be. But that's the vision of sovereignty from blockchain. I want to show you one other thing. Can I click? I don't know why I can't click links here. I'm great at computers. Oh, it's on time. Let's have a moment of reflection to quiet contemplation of our own identities and the nature of sovereignty. Maybe two moments. Cleansing breath. Identity is very complicated. It's been processing right now. Anywho, what you're about to see, I think, is a notepad document where some friends are starting to put together a bit of an article on the nature of sovereignty. Woo, this is something. Sovereignty is like a blank slate in many ways. I'm talking to Larasa. You know, it comes from nothingness and we assert it into existence one fine day. See, I'm worried if I start talking about it and then it shows up and it's different, it'll catch me. So I feel like I really need to have this rendered before I start pretending. Okay, here we go. Thank you. Okay, so this is something that some of you will be familiar with. Kings and queens. Okay, that's the way we typically did. And also, you know, emperors and warlords. So that's the typical model of sovereignty. No surprises there. Fast forward a little bit and sprinkle some of the enlightenment on and we've got a new kind of a concept. What is this thing of a person? We have some links to just some of the basics of the enlightenment there and there's some interesting cases. So I remember when I was a government lawyer way back in early 90s, mid 90s, there was something I really depended on and I loved with sovereign immunity a lot. It was my good, good friend. So every time a government worker ran someone over in a government car in a government errand or blew something up or did some amazing thing that caused harm. In the fullness of dispute resolution, being able to lean back on an absolute limit of our damages was real handy, especially when I was still formulating my legal skills. Just, you know, having sovereign immunity is terrific. Why do we have sovereign immunity? Well, actually, okay, so who here, who knows about sovereign immunity? Has anyone else depended on it like me or has anyone been on the other side? Why do we have it? Mike, this is from a policing background. The Police Service Act and other immunity that the police have for certain actions. It's a policy depended on white hats trying to do good and can't have certain things thrown in their way to impede their ability. It's the balancing of public versus private interests. Got it. So basically the victim just said, it's basically public policy. The white hats are trying to do their job, they want them to do their job, and in order to make it work, an allocation of loss is necessary. You can think of good Samaritan statutes, not so very different. In the big scheme of things, if you balance everything out, it's not that no harm is done, and could it sound negligence or something like that? It could. Is that the result we want? There's a basic concept that we like to live in civilization, and we like to overall have government, and we don't want to bankrupt the government, and we don't want to drain its coffers 100%, and the certain public functions. I mean, one of the big things that comes to my mind is, at least around here, government has an exclusive monopoly on the use of lethal force and on the use of violence. Police, you mentioned, military, paramilitary. So, that means that none of us should have to go to war against the other province, or to defend our households against the siege, like the old days before modern governance. And so, in order to provide these kinds of capabilities, sovereignty is a mechanism to make sure that we keep having the government and that they can plan and manage what the reserve fund for litigation should be next year. I mean, having no clue whatsoever is difficult for a slow-moving government. There's other reasons as well. But when you kind of go a little bit deeper... I can't really click this. I'll give you the link to this, and we're actually doing a public drafting process on this sovereignty article. When you go a little bit deeper, one of the things you discover is that there's people who have been trying to extend and even bend concepts of sovereignty to see whether they might adhere outside of a classic national government. In the United States, it's somewhat radical when I think about it, freshly, sovereignty is explicitly recognized as something that the states have and the equivalence of the provinces or the people, respectively, unless it's related to an explicit power that's been allocated to the federal government in the Constitution, which was originally a small list and we couldn't interpret that rather broadly now. So we've actually said that it's going to sub-national governments or to people, respectively. There's other cases where vessels under maritime law have been held to have a morsel of sovereignty. There's some interesting cases there that we're digging up. And there's cases where there's new sovereign nations sometimes come into existence based on the agreement of a lot of people. There's been a great example of an oil platform that was abandoned, which a bunch of techie people kind of populated and put a bunch of servers on and wanted to turn it into basically a sovereign entity on its own right. And so now with blockchain, there's a lot of interest in this very niche, all but forgotten corner of the law, injurious prudence. And people are wondering about the possibility of creating organizations that have sovereignty and that literally exist and conduct themselves solely on blockchains. You heard earlier today this weird acronym DAO, Distributed Autonomous Organization. This is a real good example of what I'm talking about. So I'm going to say you put two building blocks together and people think maybe there's an opportunity to start exploring sovereign entities on a blockchain. One of those building blocks is identity that I just somewhat belabor at some point, the individuals that have their own identity. The other one is smart contracts. The ability to write some code that does some things like in escrow funds and release them upon a certain condition can listen for certain triggers and take certain actions to basically write a smart contract that people consent to using their blockchain identities that doesn't just do an escrow fund or maintain and preserve the books of a corporation or other types of things that these dApps are doing. But there's actually a full organization that fills out all of the functions and the flows that we'd expect from an organization. So we have membership lists and roles of parties and maybe types of things that the organization can do, can hold property and it can absorb other organizations. It can split parts of itself off. These are the types of things that people have coded into fairly complicated, like solid and smart contracts and other contract languages. I'm sorry, I just stopped here for a particular reason, probably because I couldn't control that they built into these so-called autonomous organizations where the Constitution and the functions of the organization are instantiated or inscribed in the smart contract code. So this so far I'm going to say is way over the horizon. It was somewhat surprising to think about it because I thought, well, do people need to know this for their jobs now? Absolutely not. You totally don't need to know this in my view, but do you need to know it just to be aware of what's happening and what are the conversations people are having and what's bubbling up? I agree with Amy. I'm glad you did ask me to talk about this because there is something happening for sure. There's a fair amount of money and there's a lot of effort and there's a lot of smart people and autonomous, I'm going to call it a DAC, actually Distributed Autonomous Corporation is much more modest than the big goal of almost like a nation state is how it sounds to me when some people talk about it, the dows, but creating an autonomous maybe like a shoe store that just kind of does one or two transactions online that can keep track of everything, can keep track of its tax requirements, can keep track of the annual filing to maintain its corporate status, can keep track of its inventory, can keep track of its website, can keep track of its customer segmentation list and kind of roll it together with a single authoritative source of data that would be not bad at all. Don't necessarily block chain for that. I mean, you could just decide to have your company utilize in a single authoritative source of data, but the truth is when I've been involved in startups which is quite a few of them sometimes if it's a bunch of geeks that are starting up we swear solemn oaths to each other that we're going to have a single authoritative source of data for a company and then you know, it starts expanding or there's pressure and then we're like except for this we'll put in sales for except for that it's going to be quick books obviously because we make all these compromises and before you know it's a raptured mess and we don't know our own organization we can't track things all the way through and we're just, you know, like everybody else just trying to survive day by day and quarter by quarter so there's something interesting about this idea of using block chains where a lot of assumptions are questions to start with and it is an opportunity to have a fresh start to maybe take one more whack at a very prudent vision for the management of business with technology and that is just specifically encoding all the things that it does and all the data that it has in a single architecture and with a single authoritative source of truth not totally fractured across a bunch of systems it's not unreasonable so there's actually a start up that I don't have to mention this to you say it now there's a new project that we're I'm going to do in January and February in Tel Aviv with a couple of start ups and some US people that were calling CorpBot corpbot.com CorpBot.com don't bother looking yet because they need to maybe end the plane right back to finish the website but it's a it's a concept to basically create a completely integrated simplest possible corporation the USA would probably be like an S corp it might be a one-member LLC something like that and to run it through a corporation with a secretary of state maybe Kansas because it has an API for that maybe maybe another state and to create a website basically like unpack itself to do a few simple transactions and to maintain its legal operations and that everything that occurs be on a single log and make sure the log is auditable and be able to look at all the activity and then the idea is to basically use some simple data analytics like eigenvectors and Markov chains and there are various ways to measure the behaviors of the company and to see the deep patterns of it and to basically be able to manage our own organization all the way through by having everything that it ever does capable of being computationally addressed let me put it like that because we have all the data and we have all the activities and all the state changes that have ever happened so that's emerging and that's maybe one day in the future like a township or a county or an entity like that will express itself not across 275 different systems that can never it's like empty-dumpty you can never put it back together again start to see unified data processes of entities that already are sovereign that's one way you can get there or of new types of entities that may be emerging as we move into the digital age what was the other topic was sovereignty in a blockchain world okay well those are some ruminations on sovereignty in a blockchain world was there anything else you wanted me to address in there okay so similar time okay it's almost time should we take a few moments to yeah for discussion yeah for discussion okay and that's great five minutes of anything goes time so anybody who's put in an SAP system or an Oracle system there's always that promise of one version of the truth which you're talking about it's a lie it never happens and whether it's because of the laws of entropy anybody who's ever put in an SAP system or an Oracle system knows that there's always the promise of one version of the truth and it never happens whether it's the laws of entropy or something invariably human element or great forces of the universe conspired to make that not happen and it sounds like just what you were just talking about runs hard against that and I'm just curious if those if those human elements or those factors that are somehow intervening in all these practical expressions we've historically seen that run against one version of the truth with one system of of of record it's like the matrix doesn't it at some point fall apart for reasons and how do you address that in the things that you're developing what a great question did everybody kind of get the question did you get it so the short answer is I don't know that's partly why I want to spend time this January and February actually creating something that has for real a single source of truth for everything in the entity and then let it run in lab conditions first and do that however many times it's necessary before it is in the total failure working and then eventually kind of let it off the leash a little bit and be able to measure and see how it does doing some low cost not sensitive hard to the mission critical kind of trivial things and kind of see how it goes and then I think I'll have a better idea speculation right now about some of the problems with this are included number one the main issue so you mentioned SAP and other so called DRP systems the main thing with those my experience it can create a single source of truth within its scope and domain so it's like human resources and compensation management DRP system you can pretty much force everything you know it didn't happen if it doesn't appear in the system if it's like a supply chain or a purchasing system like you can kind of force things there to operate a check unless it shows up here even if you have to go back and do it again but the issue that we're trying to solve is a little bit different even what I just said is herculean to get everything to actually happen in the system when there's a really urgent deal and the CEO or the governor or someone is like saying just make it happen it's really hard to not just kind of make it happen but you can do that like I think MIT has done a great job at making all our purchasing and some of our other stuff happen in a system and it took a long time a lot of cultural change to make that happen some of it falls down is how do you know how many systems there are that when you add them all up there's nothing else that is here entity well is it my email is it my visitor log book is it my every change on every website is it I don't know every network state and every server like is it I don't know and then all the back office stuff is it every memo that every you know what attorney ever did and is it every web search they did so just knowing like what is what does everything even mean is one sort of existential question that we're going to try to tackle in an honest way and make everything that's a that's important somehow to that company exist in a unified data structure and then I think the other thing and you know I think honestly like the way these things go I'll probably be dead if I live a long time before this ever happens but if we could do it and then you kind of look way into the future some people worry already that we'll have another problem which is over reliance on this did you mention the matrix so it's very savvy some people are very up in arms already including our collaborators here we're our partners for Corkbop that you know this is a bad idea because the malevolent robot overwords will crush us obviously immediately as soon as you know we write the first line of code I don't really foresee that happening anytime soon but it does it's a legit human instinct question about it goes back to what we were talking about earlier it's been a theme throughout the day which is what is appropriate for human review with judgments and what's appropriate to happen in an automated way or on a chain or even an AWS and some service that you made and you know I think these questions might be seen part of the reason we're doing this through MIT this Corkbot exercise is in order to try to get a little bit more real about what the possibilities and capabilities are but also perhaps the risks and dangers we can kind of take a clear eye view of them and you know add to the knowledge of that you know so going forward maybe we can make better decisions and target investment better I believe and I suspect that there is a lot of good value on the table to be had for people running businesses they want to manage them more efficiently and be more agile and be able to adapt to the environment and change their own organization faster for government for sure for regulators for partners and supply chain for everybody you can the whole value chain if we could just agree to not make that you know original sin compromise is fracturing the systems of a single entity and just try to play it through all the way with all the official important data if not a single authoritative source like an identified and manageable set of sources so that proper data management and application and like infrastructure management that is unified so that we can know what's happening and get real time monitoring and we can go back and do historical analysis better predictive analytics and roll out changes in a rational way as opposed to the painful ways to change everything now and even wonder what the implications would be for changing things or how much it would cost or how long it would take to evolve what connections would be breaking and all those kind of things so anyway there's some ruminations on sovereignty okay and that's probably way more time than you said I had so I want to just say it's been great being here I always loved doing things with Amy but it's been terrific talking to the few of you that I've had a chance to connect with and I appreciate the questions I really like the other speakers I just want to thank you all for being so thank you so much Dada for being here and supporting the whole initiative and being a real voice of wisdom and like in every way so thank you three things, your journal