All right. Good afternoon, everybody. My name is Taylor Savage. I'm the product manager here at Google on the Polymer project. So before we get started, how many people here are familiar with or have used Polymer or web components before to build a web? Wow, OK, awesome. So I don't have to do the talk anymore. It's great. So I've got a lot of exciting new features, a lot of exciting new products to talk about. But before we get started, I really want to begin at the beginning. We have one overarching goal on the Polymer project, which is to build the tools and libraries using the latest web platform features so that you, the developers, can build the next generation of web apps. And if you've been following web development, or if you were at the talk that came right before mine, you know that the next generation of web apps are here, and they're called progressive web apps. So the Polymer project's mission is to provide tools and libraries to make it easy to use these latest web platform features to build progressive web apps. But that's a little bit wordy for a mission statement. So let's make it a lot more concise. The Polymer project's mission is to use the platform to deliver great user experiences. And the key part here is to use the platform. On the Polymer project, we're not trying to build massive abstractions. We're not trying to build meta platforms. We're not trying to build mega frameworks. We're trying to let you, the developer, use what's cutting edge in the web platform itself so that you can focus instead of building massive tool chains, you can focus on just delivering great experiences to your users on the web. Now, as I'm sure you know, traditionally, the web platform hasn't been a great developer platform for delivering these kinds of immersive app-like experiences. The lowest level visual primitive that you get as a web developer is an HTML tag. And these HTML tags that you're provided from the browser for things like headings and paragraphs and lists were great for document markup. But they're not so great for constructing immersive app-like experiences. And over the last 20-plus years that HTML has existed, the language itself hasn't really evolved much. And user expectations have evolved significantly. What has evolved and what has gotten significantly more powerful is JavaScript. And so to create these app-like experiences on the mobile web, we've used JavaScript as an escape patch. We've built meta platforms completely separate from the web platform. We built JavaScript runtimes, mega frameworks, tool chains, all in JavaScript to allow us the developers to be able to deliver app-like experiences. And this might have been fine on desktop where we have big beefy machines connected by cables or Wi-Fi. But there's been a major change in the web, which is the mobile web. And the mobile web is incredibly powerful. You don't have to ask permission from anyone to publish your application to the web. And then nearly every single device out there is going to have a browser, and that user can access your application. That's awesome. But the mobile web has incredible reach, and it reaches into places where data connections are limited, where device hardware is limited.  And so building these towering meta-platforms all in JavaScript to deliver an app-like experience just doesn't fly on the mobile web. When flaky 3G connections are the norm, when slow CPUs are the norm, you need minimal overhead. You need minimal redundancy. You need maximal efficiency to be able to deliver that great experience. So what do we do? What do we do as web developers? How do we solve this new challenge of the mobile web? Well, the answer so far has been more JavaScript. We keep piling on more and more JavaScript to get this to the work, to the point where now we're running JavaScript on our servers so that we can render our application. We can get it in a state where we can send it down to the device so at least it can paint, and then we download more JavaScript so that it can rehydrate and boot up, and then finally it's interactive. And this is frustrating for users, and as I'm sure you're aware, it's frustrating for developers as well. We think there is a better solution, which is less JavaScript. Use the platform to build modern mobile web apps, use what's already there on your user's device, the browser.  Use it. And thanks to powerful new features baked into the web platform, this is increasingly possible. It's increasingly possible to, as a developer, construct these engaging immersive app-like experiences using what's baked into the browser. So again, on the Polymer project, we want to make it easy by building tools and libraries to leverage these new powerful features to build less lower overhead, higher quality applications. And so, so far, we've focused on two things on the Polymer project, using web components and building web components. So let's start with using web components. We want the browser itself to be more capable by introducing the notion of a standardized encapsulated component into the platform itself. The hardest part of building a web application today is just knowing where to start. And for just about any large application of any meaningful size, chances are the place to start is to pick a JavaScript framework. And by my last count, there are approximately 1 million JavaScript frameworks out there to choose from. And this is a really critical decision.  And then every single line of code that you write from that point forward is gonna likely be directly tied to that decision, to that JavaScript framework that you picked. Now, JavaScript frameworks can be really, really powerful. They can give you very useful features for structuring large-scale applications, features like internationalization, make routing easier. And they can also provide a really convenient mental model to think about how you're building this application, make it easier as a developer to create that large-scale app. But there are a couple of very high costs to using a JavaScript framework or a meta-platform to build your application on the web. The first cost is a cost that your users pay. When you use a meta-platform, when you use this big-towering abstraction JavaScript, not only do you have to send down the code to actually run your application, but you need to send down all this JavaScript code to provide this meta-platform. And then you need to execute that platform code on the device before your actual application code can execute and make your app interactive. And again, this might have been fine on desktop with big, beefy machines, with cable connections, with Wi-Fi connections. But on mobile, slow, flaky, 3G connections of the norm, slow devices are the norm. And using these abstractions, your users pay the cost both in time that it takes to download the meta-platform onto their device and boot it up. And also, very literally, they pay the cost in their data plan of the extra hundreds of kilobytes or megabytes of JavaScript that has to be downloaded just so you can run your application on the web. And the second cost of these abstractions is a cost that you, the developer, pay. When you build a component in your web app, it's directly tied to the framework you chose. So no work you do for those components are useful in alternate frameworks. So if your next project, you're gonna choose a different JavaScript framework because a new one's come out, you have to throw away all that old component code that you've written. And if you're at a company with multiple teams and they all have slightly different stacks, slightly different framework stacks, you can't share components across teams using different stacks. So though there are many benefits to using a large meta-platform mega-framework, your users pay the cost of that abstraction and you, the developer, also pay the cost of that abstraction in terms of framework lock-in. What if there was a better way? Every single framework has a notion of an encapsulated component. What if rather than a framework having to provide that encapsulated component, the browser itself let you define your own components? And those components could work with any JavaScript framework that you might wanna use. And you could pick components off a shelf that other developers have built and open sourced that solve a problem that you're faced with to use in your own application. And the components would be compatible no matter what JavaScript stack you're using. This is the promise of web components. Web components are a new set of W3C standards, web-platform standards, that extend a native component model in the web platform itself. Because the web already has a component model baked in, the DOM, the DOM has DOM nodes, which you can call methods on, which have properties and can send DOM events. And they have a declarative way to construct that DOM with the HTML language. But the problem is HTML is fixed. And with web components, you can extend the language of HTML itself by creating new elements that you can then use in your application encapsulated reusable components without the cost of this framework overhead. And what's great is with web components, HTML becomes your interoperability layer. Every single framework, if it has to have an application run on the web platform, at the end of the day, has to speak HTML. It's the lowest level of visual primitive of the web. And a web component essentially becomes another HTML tag, just like your divs, your P's, your LIs. And so now that we can extend HTML, now that we can create our own HTML tags, we can then reuse them, regardless of what JavaScript stack we're using. So one challenge is, as many of you know, if you've been following the web component standards, it's taken a long time. So the very first version of this web component spec came out in 2012, almost four years ago, to the day. And these specs have gone through many changes, and this is just the nature of standards work. It's the nature of spec work. But I'm extremely excited that today, thanks to broad cross-browser collaboration, we are in the home stretch for web component support. So web components is really an umbrella term for these four lower-level primitives, template, HTML imports, custom elements, and Shadow DOM. Template elements are broadly shipped cross-browser. HTML imports are shipped in Chrome, and others are pending ES6 module shipping. But custom elements and Shadow DOM, these are really the two most powerful primitives to let you extend HTML, let you create your own web components. And again, thanks to broad cross-browser collaboration from all the major browser vendors, custom elements and Shadow DOM specs just hit a major milestone with V1. So V1 is the latest iteration of these two specs. Why V1? We like to index by zero in spec land. I'm not really sure. But most importantly, all major browser vendors are on board with driving implementations of these V1 specs. Firefox, Edge, Safari, Chrome, were all the table all involved with the spec discussions to get to this point with these V1 versions. It's a high priority roadmap item for the Edge team to implement. Firefox and Chrome implementations of V1 are already well underway, and Safari already has working versions of V1, Shadow DOM and custom elements in their nightly builds. So with web components right around the corner and using the polyfills that already exist today to use these features, many major companies are already using web components in production. GitHub today uses custom elements for all of its timestamps and emoji across the site. And Twitter just announced that they'll be using Shadow DOM for all of their embedded tweets rather than the much heavier weight iFrames, because Shadow DOM provides a very nice encapsulation for these embedded tweets. And the ecosystem around building these web components is already starting to accelerate and take off. Custom elements.io, which is a major aggregator, a community-driven aggregator of web components built by developers all across the world, already has 2,000 components on it, written by over 800 authors and more are being added every single day. So browsers are actively building support for web components. Major sites are already using web components in production. The ecosystem is already beginning to flourish. Broad native web component browser support is no longer a matter of if, but a matter of when. And when could be as soon as later this year? So in the past, when we've talked about, yeah. In the past when we've talked about web components here at I.O., they certainly have been on the bleeding edge of web development. And now web components are just on the leading edge of web development. So as you saw, web components are actually four lower-level specs, and they're great and they're great to use, but they can be a little hard to figure out how to actually build and encapsulate a web component. So we built the Polymer Library to make it easier to use these four specs together to create your own web components. We first announced the developer preview of the Polymer Library two years ago at Google I.O., and this was very much an experiment. We were trying to see we were working off early versions of the web component specs. Would it be possible to tie these four low-level specs together to make it easy for developers to create reusable components? And the answer was yes, but it needs to be faster. So last year at Google I.O., we announced Polymer 1.0. And this was a huge step forward. It was a ground-up rewrite of the library focused on making it fast, making it lean, making it ready to use in production. And it was significantly faster, three to four times faster than the developer preview version for element construction. And with 1.0, we wanted to show the web component promise was not just theoretical, but you could actually use web components in production today. Since this 1.0 launch, the library has seen many, many new features and enhancements, and it's gotten even faster. So since this 1.0 release, which itself was three to four times faster than the original developer preview, the latest version of Polymer is now another 10% faster on Safari and another 25% faster on Chrome for element construction. So everything we do with Polymer, we build it open source first on GitHub out in the open, and then we pull the latest releases into Google's internal version control system so Google teams can use Polymer for their applications. And despite this hurdle, Google is, I mean, Polymer is one of the fastest growing front-end technologies within Google. Over 400 Google projects today are using Polymer with over 4,000 unique components built by Google teams to use in their products. And Polymer is already launched in production across major Google properties, including Chrome, Translate, Play Music, YouTube Gaming, Google Fi, and of course, the Google IOW web app, which I'm sure you're all familiar with. So you can see how serious a strategic initiative Polymer is for Google and that it's already being served in production to over a billion users on Google products. And not only that, Polymer's being used outside of Google by companies big and small. In fact, Polymer adoption in the wild has quietly skyrocketed. There are over four million web pages now using Polymer on the open web. And many large companies are investing heavily in Polymer and web components for the future of their front-end stacks. And I wanna talk about a couple of these companies today. The first is Netaporte. And Netaporte is a global leader in online luxury fashion. The Netaporte engineering team actually first discovered Polymer at Google IOW a year ago. And since then started replacing individual pieces of their products with Polymer elements. And now today, they have a complete life cycle, an end-to-end life cycle for all the components that they use across all their different sites and pages. They have their own custom Yeoman generator for generating Netaporte flavored Polymer components. They generate documentation for all of these components to make it really easy for engineers across the team to reuse components that other engineers have built. They run integration tests, end-to-end tests for every commit to every component across all the different browsers that they support. And then they use these components across all these different pages across the Netaporte site, which allows them both to have visual consistency because it's the very same components and functional consistency. And this has made it much easier for the Netaporte team to scale this very large multifaceted site by reusing the very same components. The second company I wanna talk about that's using Polymer is BBVA. And BBVA is a multinational banking group operates in 35 countries, 130,000 employees, 66 million customers. And you can imagine that with such a massive operation in so many different countries, they're gonna have many, many different types of applications to build. And so rather than building a native app, a unique one-off native app every single time, they switched to using all web technology based on Polymer, based on web components. And so they have this internal catalog of all the different components that all their different teams use and build so that they can, instead of building one-off applications, can take components from this catalog to assemble applications. And when I say assemble, I really mean assemble. Web components lend themselves extremely nicely to drag and drop whizzy-wig-type construction experiences. And so they've built these sorts of tools to visually create and construct and assemble applications out of the components that they've built. And this ease of application creation has had a very tangible benefit on their business. For the first project that they switched to Polymer web components, they saved 70% budget and 50% time, and their engineering efforts are significantly more scalable and easier to manage. So in short, since 1.0, Polymer has become faster, more feature-rich. It's seeing exponential growth here within Google, served to over a billion users, and major companies are investing in Polymer and web components. So the Polymer library is for building components. Major companies, major Google products are adopting these components in building components. But they're not just building components. They're building applications out of these components. And so we get this question asked a lot, okay, web components are great, but how do I take these web components and then construct an actual application? And our answer has always been, well, you know, components can be arbitrarily complex. You can build a component out of other components, out of other components, out of components, out of components in yada, yada, yada, and you've got an app. But of course, that's not a very satisfying answer. Developers wanted more guidance on how to put these components together in a platform idiomatic way. And so recently, as the team has been growing, as the project has been growing, we've expanded our focus a bit to think not just about how to build web components, but then also how to take these web components and build full-fledged, cutting-edge mobile web applications. And of course, not just any kind of web application, but progressive web applications, applications that took all the right vitamins. And of course, we don't just want to help build progressive web applications. We want to help build great progressive web applications, great user experiences. So how do you do this? How do you build a great progressive web app on the mobile web with all of the challenges that that entails? And of course, our answer is to use the platform. Use the platform to build great apps. Use what the browser gives you to achieve minimal payload, minimal overhead, design offline first. And this is a hard challenge. And so we wanted to make this easier to use the platform to build cutting-edge progressive web applications. So I'm really excited today to announce the Polymer App Toolbox. And the toolbox is just a set of components and tools based around web platform primitives that make it easy to build cutting-edge progressive web applications. So what's in the toolbox? Well, all the things you'd expect to build a large-scale progressive web app. Components for layout, for routing, for localization, for storage, and then a command-line tool to tie it all together. So let's go through each of these one at a time. The first is layout. All UI design begins with layout. It's the visual structure that makes up your application and a high-quality immersive mobile app requires high-quality app structure. It requires that app-like look and feel that users have come to expect on their mobile devices.  There are no HTML tags for a responsive drawer. So we built it using the Polymer Library, the app layout elements. An app layout has a number of UI components to make it easier to structure these mobile app-like experiences. And they're designed to be flexible, responsive, and fast. So app layout elements contain components for things like toolbars, and drawers, and headers. They're flexible, they're not visually opinionated, so you can use them regardless of what your application looks like. They're responsive by default, so they work across all different screen sizes. They make easy, they make hard things easy, things like these fancy scroll behaviors that users have come to expect on their mobile devices. And they also critically help ensure accessibility, which is a crucial feature for any application that you're gonna build. So let's take a look at a couple of these components. So here's a really simple example of using the app layout components. This is a basic app drawer layout. You have a drawer to the left and then you have this middle section content that scrolls. The drawer opens and closes with momentum, you can swipe it closed. And then you've got this header layout section, which is this main content section that the user can scroll through. And this is all done declaratively in markup, but you're just writing HTML using these web components. And I wanna draw your attention to these two properties, these two attributes, on the app header, fixed and effects. Fix says, I want this toolbar across the top to remain fixed as the user scrolls. And the waterfall effect says, I want a little shadow to appear underneath the toolbar when the user scrolls down and when they get back to the top, make that shadow disappear. So it looks like the content is water falling out from under the toolbar. Really nice, just little subtle user experiences that make it feel like a top quality application. But you can get more complicated with the app layout components. Here's a very similar example, a little more markup. And we have a few more attributes on the app header here. The first is condenses. So as you can see, when you get to the top, the header is expanded and large and it condenses as the user scrolls down. Reveal says, when the user scrolls down below the header, hide that header and then if they scroll up slightly, show that header again. And then the waterfall effect of the same one makes it feel like the content is water falling out. So really subtle polish that makes it just look and feel like a first class progressive mobile web app. And as you can imagine, there are lots of different combinations for these different attributes. And so we built a demo called Test Drive that lets you try out these combinations, literally tick off the boxes and then experience what that would feel like in an application right there. And of course, the app layout components are totally pluggable. So any animation that we provide, if you don't like it, you can easily build your own and plug it in to the app layout components and get a completely custom looking feel. Okay, great. We can layout our application. What if we want multiple views? How do we route between multiple views? This is a very common question that we've gotten. What router should I use? And we've always said, they're just web components. Use whatever router you want. There are tons of JavaScript routers out there. But we surveyed the router space and we realized that most JavaScript routers have this singular global view of the world, all the different routes that you're gonna have in your application and the corresponding views that those routes are gonna show. And we wanted to build a router that didn't just work with web components, but that worked like web components and that it was modular and composable, that it could route from an entire application all the way down to a single component. So we built the app route component. Let's say you wanted to build a typical application. You've got three routes, slash, slash item, slash cart, and you want a route between these different views. You could use the app route component to have a path that will match on the route. It will provide a property saying whether that path is active or not, and you can very easily toggle on and off different views in your application. But it can get a little more complicated than that. Let's say you wanted to extract data from that URL, from that route. So you have slash, slash detail, slash item, slash detail, slash item ID, and you want to extract that item ID value to then use in your application. App route lets you do that with this colon syntax, and it provides the value of that item ID just as a property on the DOM node. And what's cool about app route is you could have this at the top of your document, you could have it globally like a typical router, or you could compose this app route into the component that's responsible for showing this detail view. And so you can delegate the responsibility of deciding how to use this item ID value to the component that actually is gonna show that view. So the app route, it's flexible, it's modular, it's composable. It doesn't just work with web components, it works like web components. It can know about your entire app, or it can just be responsible for routing one small section of your application. Okay, that's great. We can lay out our application, we can route between different views. What if we want to localize our UI? What if we want to translate it into different languages? Again, very common question, and we've always said, they're just web components. There are a million ways to localize an app. Use whatever one is most appropriate for what you're building. But we wanted to build an idiomatic platform embracing way to localize applications. So we built the app localized behavior. And what's great about the app localized behavior is it uses the platform. It uses the Intel object, which is a standard JavaScript object to provide localization data, and it's broadly cross-browser supported. And where it isn't supported, there's a polyfill. And so to use the app localized behavior, you use it in any Polymer component that's gonna be responsible for translating strings. So if you are familiar with Polymer and building web components using Polymer, you'll, this will be very familiar syntax to you. To use app localized behavior, you add it as a behavior to your component, and then you give it two properties. The first is a language property, which will be the language that you want this component to be translated to. And of course we have it statically defined here, but you could very easily bind to it to dynamically switch it. And then we're gonna give it this resources property, which is gonna be all the different keys and translation strings that we're gonna need for this particular component. And of course here again, it's statically defined, but we could easily fetch this off the network, we could have it globally on our window object, however we wanna provide this resources to the component. And then to use these resources to localize the component, anywhere we have a string, instead of that static string, we're gonna bind to this localize function, we're gonna pass it a key, and any variables, any content that's actually gonna need to be in that string. And so what you can achieve with this, is you can translate simple strings with string replacement, but you can also localize currencies, and numbers, and dates, and it even supports plurals and genders. So a very simple tool that uses the platform to elegantly solve very complex use cases. Okay, we can, yeah. So we're doing great. We can layout our application, we can route between views, we can localize each of those views. Now let's say we wanna store data, and we wanna store data in the cloud or locally on the device to then use in our application. Again, very similar conundrum. How do I connect data to my app? There are a million ways. Well, they're just web components. And again, we wanted to provide a platform idiomatic way to take data from the cloud, from locally on the device, provide it to an application in a platform idiomatic way. So we built app storage. And what app storage is, is it's essentially an interface that allows you, the developer, to create your own web component to connect data from any service, whether it's in the cloud, whether it's on the device, and service that data in a way that your app can use. And the way app storage services the data is in a very platform idiomatic way. That data is serviced just as a property on the DOM node. And any changes to that data are expressed as DOM events. And conveniently, that's exactly how Polymer's own data binding system works. Very much uses the platform. It's what's available there in the platform. And so app storage provides turnkey integration with Polymer's own data binding system. So let's give it an example of how you might use this. Say you're building a note-taking progressive web app. You're gonna wanna launch it from your home screen because of course it's a progressive web app. You can add titles to your notes. You can add information and details to your notes. And all of this data you're gonna store in a REST API that you've built in the cloud. But of course it's a progressive web app. So it needs to be able to work offline. So if we go offline, launch it from our home screen, if we're just relying on getting the data from our REST API, we're not gonna be able to launch the data, launch the application at all. We're not gonna have access to the internet to launch that application. But app storage makes it very easy to architect your app so that you can support this use case very simply. So here's how we're gonna build it.  And then you're gonna use a component app index DB mirror that we've provided as part of the app storage components. And what that does is take any data that's passed through it and it mirrors it into a local index DB instance. And then that's gonna pass data into your application. So here's how it looks when all the data is wired up. When you're online, your cloud API component has no problem interfacing with your API, with your REST API, it's gonna pipe that data through this index DB mirror component, which is then gonna pipe the data to your app. So you're online, all's well and good. When you go offline, your cloud API component can no longer communicate with its REST endpoint. But since we've been piping all of that data through the app index DB mirror component, we have all of that locally stored in an index DB instance on our device. And so we can boot up our application, even when we're offline. But what if you don't wanna build your own component? What if you don't wanna build your own REST API to manage the data? What if you wanted to use, say, a database as a service in the cloud? Well, fortunately, there's an element for that. The app storage element with PolymerFire. So PolymerFire is actually a set of Polymer-based web components that the Firebase team has built that makes it trivial to communicate with a Firebase database instance and to use that data in your application. Okay, we're doing great. We can layout our application. We can route between different views. We can localize those views. We can communicate with a backend and stored data. But we still need to deliver this application to our users. And remember, this is the mobile web. Flakey 3G connections of the norm, slow devices of the norm. We need minimal payload. We need minimal JavaScript. We need maximum among efficiency to be able to minimize the time to first meaningful interaction for our users. And this is the great challenge. How do you minimize that time to first meaningful interaction? So there's the hard way. We can use the same old JavaScript escape hatches. We can build a massive tool chain with heaps of JavaScript. We can server-side render. We can get a fast first paint with our server-side rendered app and then download the meta platform and then boot it up and then make it interactive. But it's frustrating for a user to sit there watching a splash screen. And it's even more frustrating as a developer to jump through all these hoops to server-side render so at the end of the day, only really have generated a splash screen or a spinner. And time to first splash screen, time to first spinner is not the same thing as time to first meaningful interaction.  Your user still has to wait for your abstraction to load before your application is useful. We think there is a better way, which is to use the platform to deliver apps. The tighter the platform, you can build your application the faster it's going to be, especially on slow networks and on slow devices. Let the browser be your application. And thanks to brand new web platform primitives, we can throw out a lot of the old knowledge about how to make an application fast on mobile and embrace new primitives and technologies that the browser provides. So there are really three important primitives for delivering a modern mobile application. Web components, which allow you to construct your application out of these granular dependencies, out of these granular components. HTTP 2 and server push, which allows you to serve these granular dependencies in a granular way to your users without incurring massive round trips and to most efficiently utilize the bandwidth. And then service worker, which lets you reliably cache these granular components on your user's device. So let's take a look at how these three primitives work together really nicely. So let's say we're building an app, we've built this app before. We have three routes slash slash items and slash cart. Each has a view, they share some similar UI between the views. If we built this the old way as an old school single page app, for each of these views, no matter what route the user hit, we'd have this monolithic index HTML, this monolithic app.js, this monolithic framework and a CSS file. We'd send all of them down to the client. And then on the client, the framework would have to boot up, then the application would have to boot up, then it would have to match the route to the view and then it would have to render that view. Obviously very slow, obviously very inefficient. But let's take a step back. We have three views here. Some are independent, some overlap in terms of what they actually show on the screen. Let's use the platform to serve this application as efficiently as possible. So let's split the view down. Let's break it down into individual web components. Some of these components are gonna be shared between views. Some are gonna be unique to a particular view. Let's say the user requests this slash route. The server can know exactly what components are needed in order to render that view and to make it usable on the device. And so the server can use HTTP2 and server push to push down exactly the minimal dependencies, the minimal components that are needed to make that route, to make that view interactive without multiple round trips. And then we have that there on our device that the user can start interacting with with minimal overhead. And not only that, we can take those granular components and we can stick them in the service worker cache. And then in the background, as the user is interacting with that first view, the service worker can start fetching additional granular components from the network and pre-cache those. It can get those from the network and stick those two in its service worker cache so that if the user then navigates to the next view, slash items, there's a good chance that you'll already have every single component that you need to render that view and make it interactive already right there sitting in your cache. You don't have to go to the network at all. But of course, it's not practical to necessarily cache every single dependency for your entire application. So for future views, you can lazily load and lazily instantiate additional components that you need to render those views. And of course, some of those might already be sitting there right in your cache. And for those that aren't, you can use the server to push down only the minimal set of dependencies that the user doesn't already have in their cache. So there's a pattern starting to emerge here. You push components that are needed for your initial route. You render that initial route and make it interactive as soon as possible. You pre-cache in the background using service worker additional components needed for remaining routes.  And we really like acronyms on the Polymer project. So we've been calling this the purple pattern. And the purple pattern is not Polymer specific. It's just a pattern for progressively loading and rendering a modern progressive web app using these new technologies and primitives in the web platform. So with the purple pattern, you get minimal payload, minimal overhead, minimal time to first interaction and an optimal user experience. And the crux of this purple pattern is the ability to break up your application into individual granular components that require minimal overhead themselves to boot up. And that's exactly what web components provides. So now that we're armed with the purple pattern and we've built our app, how do we apply it to our own progressive web app that we're building with the app toolbox? Now there are a lot of different tools for building and optimizing component-based applications. And we wanted a maximally simple tool to make it easy to get started building an application using this pattern to develop and then ultimately to build and deploy it. And so we built the Polymer CLI, the Polymer command line tool. And the goal of the Polymer CLI is to stay focused and simple. It provides just a few set of commands that can help support you throughout the entire development experience, whether you're building a Polymer component or whether you're building an entire application out of web components. So this includes Polymer and NIT, which makes it really easy to scaffold out an initial web component or an entire application built out of these web components. And it'll set up the folder structure that you need for each of these two. And we've also built a set of starter templates to get you started with different types of applications that you might wanna build. Polymer Serve will locally serve your application or your component so that you can play with it as you develop. And what's cool about Polymer Serve is that not only will it serve your component, your application, it will also serve all of the documentation automatically generated from all the components that you're using to build your application. So you can develop, and on a second browser tab, you can have all the documentation for the components you're using to develop. So it's a really great experience. Polymer Lint will lint your code and check for common errors that occur when you're building with web components in Polymer. And then Polymer Build will let us specify a main entry point and then an application shell. And it will generate a bundled and unbundled version of your application that you can then serve. The unbundled version is perfect for serving with the purple pattern. It keeps those dependencies granular so that you can use the purple pattern to send them down efficiently. But we also generate a bundled version for a fallback for browsers that don't yet support HTTP2. And Polymer Build also uses a tool called Service Worker Precache to generate these service workers that do this precaching, prefetching, and sticking these components in the cache for you so that if you don't want to, you don't have to write a line of service worker code. All of this is generated for you based on your application. So that's the toolbox. Layout, routing, localization, storage, and a command line tool to tie it all together. And you might be thinking, didn't we just build another stack? Didn't we just build another monolithic stack? But this stack is different. In fact, it's not a stack at all. It is just a set of loosely-coupled, interoperable web components that can be used piecemeal, individually, or altogether, and it's not a monolith. And each of these components is just a lightweight layer on top of platform primitives that already exist right there in the browser. So with the Polymer app toolbox, we're showing that you don't need a massive meta-platform. You don't need a massive mega-framework. You don't need an alternate platform to build a high-quality mobile web allocation. You don't need tons of JavaScript. You don't need a crazy complex tool chain to serve it. You just need to use the platform and use all the modern primitives that the web platform provides. Now, of course, we didn't want this to just be a theoretical exercise. So we built an app using all of these techniques. We call it shop. It's an e-commerce-type application. It doesn't actually sell Google Gear, so you can't check out and buy anything, so don't expect anything to show up at your door. But it's got all the views for a typical e-commerce app. It's got a main splash page homepage. It's got a product listing view. It's got individual product pages, and it's got a cart and a checkout flow. And it's built and served using all of these components, using all of these patterns. Web Components, Service Worker, HTTP2, and the purple pattern. And it uses Polymer and the app elements and the Polymer CLI to develop and build. So you can check out this demo as well as everything that's in the toolbox and documentation about all the things that are in the toolbox at the brand-new Polymer documentation site, www.polymerproject.org. So in summary, the Polymer project's approach to modern web development is different. It's different than that of a typical JavaScript framework because it uses the platform. It uses what's already there in users' browsers rather than creating massive abstractions on top. And why is it important to use the platform for performance on mobile? And thanks to these new powerful web platform primitives, this is finally possible. This is finally possible as web developers to create these kinds of engaging, immersive app-like experiences on the mobile web. And so the result of using the platform is a first-class progressive web app built out of interoperable web components. So if you'd like to learn more about Polymer or web components or the purple pattern, there are tons more talks here at Google I.O. about exactly this. Progressive Performance Polymer is right after this one and there's another two more tomorrow. And if you have a time machine or a YouTube, you can check out the talks that have already happened earlier. So I'm really excited by this. I hope you are too. And if you'd like to learn more about Polymer, about progressive web apps, about the purple pattern, there's a conference for that. The next Polymer Summit, which will be later this year in London. So you can sign up at this link to be notified when registration opens. If it's anything like last year's Polymer Summit that we held in Amsterdam, it's gonna be awesome. There were 800 developers in a beautiful venue. It was a full day of talks and night of code labs and I'm really excited to do it all again. So that's all for today. I hope to see you at the Polymer Summit and remember, use the platform. Thank you.


We're here at GET 2016, the second global forum on emergency telecommunications in Kuwait. And I'm very pleased to be joined by Timothy Ellum, who is president of the International Amateur Radio Union. Tim, thanks so much for being in the studio with us today. Well, thank you for inviting me. Now, I'd like to start off by talking about this forum. I wanted to find out what's the significance of you being here. And in terms of amateur radio, what role does amateur radio play in emergency telecommunications? Well, amateur radio has had a long history in dealing with emergent situations and disasters. Quite often, amateurs are on the ground. They have their own communications devices. They have their own antennas. They have their own systems. And if an emergency strikes in the critical 24 hours after that emergency, they're there on the ground. They know how to communicate. They know what frequencies to use and can deal with passing health and welfare traffic and dealing with the first responders as necessary. And what is the International Amateur Radio Union known as the IARU? The IARU is a non-governmental organization. It's headquartered in Connecticut in the United States. It represents the over 160 amateur radio societies in various countries around the world. And we represent the interests of the amateur radio services at the international and national level, including with the ITU and other regional telecommunications organizations. And is amateur radio relevant today? Has amateur radio benefited from advancements in technology? It has. Amateur radio is probably more relevant today than it was 25 years ago. We're so dependent now on all kinds of systems of communications. Everyone has a cell phone. Everyone's used to using the internet. But they're not used to what happens when those systems go down. And amateur radio is there. It relies on some odd old-fashioned technology. But there's also advancements in technology that we rely on. Very weak signal propagation, for example. We have where you can use a computer to pass traffic information at very, very low power levels in very bad propagation conditions. And so as we've developed our communications, amateur radio has kept pace. And it's kept pace by developing new ways of being able to communicate. And in terms of challenges, what challenges does the amateur radio service face? There's a number of challenges. One, in some countries it's still very difficult to get a license. And in other countries it is not. You have this very interesting anomaly where a lot of countries where there's a very significant hurdle to get a license, people will write the United States Amateur Exam and then take that amature, the license that they get from the United States and use that to get a reciprocal license from their home country. The second challenge that we have is on the importation of equipment. Amature equipment can be taxed quite heavily in some countries, and that does affect the ability of an average amateur to have the right communications equipment. The third challenge is with antennas. A lot of amateur radio communications is on HF frequencies. And HF frequencies typically do require larger antennas, support structures, perhaps directional antennas. And there are some countries where it's very difficult or there's a lot of hurdles to put up to allow amateurs to use those antennas. So those are the three biggest challenges that the amateur services face right now. And finally, I know you're going to be speaking here at the forum. I wanted to find out what's going to be your key message. What are you going to be trying to convey to participants here? Well, I think that what I want to convey is the value of the amateur radio service today and how it is there on the ground. We talk about bringing in during times of crisis emergency communications equipment, the difficulty of getting it through customs in some countries. What people forget is that there are people on the ground who have the communication skills and the communications equipment. They don't rely on commercial networks. They know how to do things. I'm not an engineer by any means. I don't work in the communications field. But in a time of crisis, I know enough to be able to use a battery to get my radio working to put up a simple wire antenna to make communications with emergency services. So that's the value of the service. I'm speaking at two events and that's the central theme is how the amateur radio service is relevant today and very relevant and important for emergency communications. So Madam, thank you very much indeed. Thank you.


If she smiles at you, it's interest. If she starts asking you for help, that's interest. Requesting help is another great sign of interest, yeah? Like, oh, could you help me out? My purse has come off my wrist or whatever. Oh, my shoelaces need untie.  Whatever they need help with, they are the things. They're the key elements. They're gonna help you out with that. You know, another good, if a girl whispers to you, do you know that's a really good sign? If you're talking to a girl, you know, how many of you guys like, I can't hear what the girl's saying. And so they're like, so you know, so I'm gonna lean in. Like, I much prefer leaning back and then saying to them, dude, I can't hear you, come back closer. And the girl moves into you and she whispers. If she will come close to you and whisper, that's a great sign. You know why whispering feels good? This is another thing when I'm from body language. This is absolutely great. So check this. Your ear has three bones in it, for those of you guys that don't know that. Those bones used to be part of your jaw, right? When you were a reptile, slash fish, slash, never worked, reptile. You had these, these, and what they would use is reptiles sent vibrations in the ground with their jaw. And so these bones would vibrate and let them know what was around. And then it became a lot more efficient to just move them up into our ears, add an amplifier over it or whatever and pick in sound and send sound vibrations instead of ground vibrations. Are you all with me so far? Did I lose anybody in that? I'm not good at teaching anatomy or whatever, but that's basically how it works. So, have you ever noticed that when someone strokes you, it feels good? Thank God for that. And when, because that would freak me out. After the whole, the guy that couldn't tell if a guy was smiling, she was stroking me to irritate me. I'd be like, dude, we're in trouble. Yeah, it feels good. But if someone punches you, it doesn't feel as good. It's a harsh hit. Well, in the ear, if you whisper to somebody, it's a gentle vibration. It feels good. If you scream in someone's ear, that's like a punch, it's the equivalent. So these sound vibrations, it's a big deal. If a girl is willing to whisper, she's triggering that in you. And if you're whispering back to her, she's allowing you to trigger it into her. You know how you'll know that it doesn't work?  No, you'll find that, thank you very much. Keep talking from there, at distance. I can hear you. I can lip read at you. I don't even need to hear what you're saying. I'm not even listening. I don't even care. That's what she'll do if she does not want to talk to you. If she wants to talk, she will accommodate, she will listen. Now here's the fun one. And this is the best. You ever heard that three signs a girl likes you and that's it, you're in or whatever? That's not necessarily so true. When you start to see these things, you'll notice that what happens is they increase in frequency. And so what happens is you can literally, you can almost time it and you can be like, oh, there's a sign. Oh, there's another sign. Oh, there's another sign. And another one, and another one, and another one. And as the pace of these signs increase, the girl is more and more attracted to you. You'll see her knee will move close to you and try to make contact. She'll try and touch you. She'll lean in, she'll listen more. She'll flick her hair behind her ear. She'll smile, she'll laugh at the wrong moment. All of these signs start throwing at you and they speed up. If you do not do anything about it, when they start speeding up, you know what happens? The momentum goes, they slow down again. And you just missed out on that opportunity. Maybe you can build it up again and build it back up. If you don't, you miss out on that opportunity.  I've sat there with one of my instructors analyzing this. We just watch it and I'm like, watch on the clock. She's roughly every 20 seconds at the moment. And you see it, tick, tick, tick. Just ticks over one after the other.  That was like 10 seconds there. This guy better make a move. And then you'll see me. I walk by, I've got like the app blurb. You guys seen the app? So much fun for teaching. It's like a scrolling banner across your phone. And I'm like sneaking behind the girl, trying to get the student to see it.  And I'm like trying. And then the girl looks at me and I'm like, oh my god. Yeah, that picture was so good.  Oh, that's a good picture. What do you think of the picture, man? It's so good. I'm like, dude, stand over there. Let me take a picture of you. Now, now. And of course, the student didn't see it. He doesn't escalate. And then the girl, you see her. She starts losing interest. And you know what happens then?


So I'm so excited to be here speaking at a developer conference because a lot of times lately when I give talks to business people, you guys are kind of my people because I am a developer. I got my start with startups which is kind of what I know and love. I have also done development for some big companies like Oracle and Microsoft and helping them with how to be more lean and agile. But really what gets me excited is working with people who are really pushing the edge on what's possible. And so for the past few years I've managed to work with literally hundreds of early stage tech startups and just really focused on helping hackers and entrepreneurs who are building really innovative disruptive products with how to be successful at market. So that's what I'm going to share with you guys today, whether you're building a new product for a big company that wants to enter a new space or whether you've got your big idea for the next great thing and want to go do your own startup. So in thinking about innovation, the first rule of innovation is there are no rules of innovation because if you're doing it right, then you're breaking more rules than you're following. And if you're going to be innovating, then you're going to be trying a lot of different things. Thomas Edison famously said, I have not failed. I've just found 10,000 ways that won't work. But don't worry, it's not a complete black hole. So what I wanted to do today is share some patterns that I've seen innovators who are successful do time and time again and kind of walk through these and give you some examples of how innovators have done them. So the first one is eliminate waste, which if anybody does anything with lean, this is not going to be anything new to you. There's actually this lean startup methodology which has tried to take the principles of lean and apply them to how to do a startup. And Eric Ries, who's the creator of the lean startup methodology, says the number one most important thing for a startup is learning to tell the difference between value and waste, which is kind of weird, right? Why would you not know the difference between what adds value and what is wasteful? But of course it actually comes from lean from the Japanese term muda, which doesn't just mean something that's never going to add value, but eliminating anything that isn't explicitly adding value today. And when you're innovating, think of Thomas Edison, you're going to be trying a lot of things and finding out what doesn't work. And if you are trying to do this stuff that you think you're going to need tomorrow, you don't know what tomorrow is going to hold yet. And so if you wind up going over here and you build all this stuff over here, then that is wasteful. Or for any XP, Extreme Programming folks in the room, just think Yagney, you ain't going to need it. So the truth is a lot of companies think that they're going to do one thing, and then they want to do things very different. So to give some examples, PayPal started off as a way to beam payments between PDAs. But it turned out that the world was not yet ready for mobile payments in 1999. And Flickr actually started as a massively multiplayer online role-playing game. They actually built out the game, and then it turned out that the most fun feature of the game was sharing photos. And Instagram started as a gamified Foursquare, and again, they built out the entire iPhone app. I don't even know if they put it in front of anybody, though.  They threw the entire thing out and just focused on photos, which they thought was going to be the most effective. So these are examples of companies that are successful today. But when you look at the stats, it's pretty bleak. The stats are that nine out of 10 new products fail, which is pretty abysmal. Specifically, when you look at tech products, they tend to fail not because the technology doesn't work, but because people have created something that there isn't a real market for. A great example of this, or a scary example of this, depending on how you want to look at it, was this company Actuality Systems. They were actually here in Boston, so some of you guys might have heard of them. They created a holographic 3D display. Okay, that's pretty badass, right? They actually created it. They got it working. And then they spent the next 10 years trying to find a customer for it that would let them have a sustainable business.  And all that they could do was really sell off the license for the technology. And so the question is, were they successful? I mean, in innovation, they created this thing that had never been created before that was absolutely amazing. And so from that perspective, absolutely yes. But then they weren't able to actually make a company out of it and they spent 10 years of their life trying and not succeeding. And so I'd like to see technologies like this do a little bit better. So it's kind of interesting, there was a survey done into what is the single biggest predictor of failure amongst startups? And what was found sticking to the initial business plan? So this is kind of scary, right? Because when you're trying, when you're doing any new venture and you're trying to figure out if you're on track or not, even that word on track is like how are you tracking to plan? And so if staying on plan actually means you're going to fail, it gets kind of confusing, right? And so that brings us to pattern number two, which is to start small. Which is usually the exact opposite of what I see people do when they're all excited about they've got this next big thing they wanna go off and build. And so hackers are like, I wanna build this end-all device that's going to do everything, right? And entrepreneurs say, I'm gonna build the next Facebook and get a million users and make a billion gazillion dollars, right?  But the question is, how do you go from this big vision that you've got? We have nothing else. But your big vision to a million billion dollars or users or devices or whatever it is. I mean, Facebook today has over a billion users. How would you even create something that from day one would have enough features to be appealing to a billion different users? And the other thing is that would you guys wanna get on the next Facebook, if nobody else you knew was using it? Most people wanna wait and see, right? And so when I think about kind of this quest for how do we come up with an innovative product that's gonna be successful, I think of it as a search for the intersection between our big vision of what we wanna do and what reality can actually accommodate today. So a lot of companies wind up starting small in order to do some experiments. A great example, Microsoft, not doing so great with their phone, but I think everyone would agree they're pretty big doing okay. They actually started with basic for the Altair. Now, I don't know how many Altair computers were ever made, but I'm thinking like a few thousand, it wasn't very big, right? Or even Facebook, which is sort of our quintessential example of going big. They started at Harvard and there's only 20,000 students at Harvard. And so it feels very unintuitive, but this is the way that you wanna be thinking about things. Start from your big vision, you wanna have that big vision, that's great. But then go small, figure out a way to dominate a small market. And then you can build on that success to go bigger. There's several reasons that you wanna do this. One is, of course, what we already said that if you're innovating, you're gonna find 10,000 ways that won't work. And so you don't want to go big and spend a year or 10 years building something out and then it doesn't work and you're like, okay, that was all the time and money and patience that I have for that. So small experiments are good. But even beyond that, by going small, you can go after this very niche market. And all you have to do then is find these people that really want something bad. And find that one thing that they're dying for, and then just build that one thing. You don't need to build a billion features to be exciting to them. So Altair users really wanted a way to program their computers. I mean, I think all they had were like blink and lights and toggle switches, right? And then Harvard students really wanted a single centralized student directory, so Facebook was able to build that out without building all these features that they have today. So this is how you want to be thinking about things like Microsoft, like Facebook, like actually most successful companies actually start by going small with a very small market and taking that to billion gazillion. So of course, in order to be able to dominate the small market and understand that one thing that they're dying to have, you really need to be able to deeply understand your customers. And I would even go so far as to say, if you're entering a space where there's like a bunch of competitors as there almost always tends to be, this is the number one way to dominate that space. Because if there's a bunch of different people entering the same space at the same time, he who best understands his customers is going to be able to create the solution that best resonates with them and likely going to win. A really great example of this is Dropbox. This is a bit of a conversation that Drew Houston had with some BCs when he was starting Dropbox. And they said, I don't even understand why you're entering this space. There's already a million billion cloud storage startups out there. And Drew said, yeah, but do you use any of them? So what Drew did that all the other competitors that were trying to enter the space didn't, is he actually understood who his customer was. I think because he was one of them, and he built it specifically for them. So he understood that his customer was, or at least his initial customer, that small market, was the hardcore techies who have a bunch of devices that have the problem that you need to transfer files between them. He understood what they wanted so well that he put up this web page, very exciting web page here. You can see this was built in 2007. It looks a little bit like 1990s web page, right? He actually, he built out the tech, he did a proof of concept on the technology because he was doing tech that hadn't existed before. He had to make sure he could get it working. But once he figured that out, he didn't go build the full product. He put together this mock-up prototype, and he did this really scrappy three minute video. I don't know if anyone has seen this, you can still find it on the net. Three minute screencast of him walking through this mock-up with him as a voiceover, nothing flashy, nothing exciting. He posted it to Hacker News, so one place. And overnight, he got 75,000 sign-ups, right? Now you think, okay, well today, if Dropbox put up something and got 75,000 sign-ups, that would be kind of impressive. But they've got like 300 million users, they can do that. When he put this out, nobody knew what Dropbox was because it didn't exist yet. And he put it one place because he knew exactly who his market was. And overnight, 75,000 sign-ups, so it's pretty astounding. So I feel like there is this myth around innovation, especially in the last couple of years with so much hype around startups. Everybody wants to do a startup. And there's this, these stories that get told that make it look like, if we build it, they will come. But when you really dig deep into what's going on, what you find, or these stories of these founders, the founders who are really successful, have actually gone to extraordinary lengths to really understand their customers. So Airbnb, I guess having some legal problems lately, but still doing pretty good. One of their co-founders did not rent or own his own home. He just went around and stayed in Airbnbs. I can't even imagine, I guess he lived out of a suitcase. But how's that for understanding your market? Or Ben Silverman, the founder of Pinterest. He actually personally reached out to the first 5000 users and invited them to coffee and gave him his cell phone number. But can you even imagine?  In fact, a lot of this comes from sort of lean startup if people are familiar with that, but they say for innovation, what you want to be thinking of is, how can you be scientific about this? So I'm not a scientist. I don't know a lot about science, what they do. But as I understand, when they want to prove something, they come up with a hypothesis. And then they do a test to either validate or invalidate the hypotheses.  And so the question is, what can you do to test if your guesses are right or not without going and building the entire product and then possibly failing, right? What are the small tests that you can be doing to be constantly learning what works and what doesn't? So initially, you can do some of these tests by talking to people. You know, the holographic display, I think they would have done really well if they just, I assume that their customers were commercial businesses. If they'd just gone out and talked to people in different industries and understood better, what is your budget? What are some problems that you have today that maybe could be dealt with with a 3D display? Drew Hauston from Dropbox could have, and I'm sure that he did go out and talk to people and say, okay, what devices are you using today? And what are you doing today to transfer files between those devices? And that's really good information to have because carrying around at USB sticks sucks, right? And so all you need to do is come up with a solution that's better than that. It doesn't have to be super elegant. It just has to be better than what people are doing today. But here's the thing, and this is a mistake I see a lot of people make, is talk to people absolutely to understand sort of what problems they're having and what they've done in the past. But don't say, hey, I've got this great idea, isn't it a great idea? Because people get caught up in your excitement, in your passion. And so of course they're going to say, yes, that's a fantastic idea. My god, you're building a holographic display, yes, I want one. And you say, would you buy it? And they want to encourage you. And they say, yes. And then you hand them a device, and I mean, I don't know the details, but say it's $50,000 and you have to actually write this real-time 3D rendering code to get anything to output to it.  So you don't want to your validation for if people will use a product or if they'll buy it, should not be asking them. It should be actually putting something in front of them. So I like this quote from Linus Travals who says, talk is cheap, show me the code. In startup world, we have this phrase which I kind of love and hate because I feel like it's overused like a buzzword. It's called minimum viable product or MVP for short. And the idea here is don't build out the entire product, but figure out what that minimum viable thing is that you can get in front of that user to actually view what their behavior is. And usually you want to put a lot of analytics on that or some things so that you can actually see what they do with it. So we've already seen one example of it. Kind of the quintessential MVP is no code required at all. It's something called a landing page. That's what Dropbox did. So you put up a description of your product or maybe a video on it and then a place for people to enter their email address. And you put some analytics on it so you can see how many people you're able to get to the site and how many people are signing up. To give you kind of walk through a little bit more elaborate of an example of this, there's a company called Buffer. They do social media sharing and so say you like to tweet a lot and you go and you, like I like to read all my news at like 2 AM or something on Sunday night cuz I'm procrastinating. I don't like to go to bed. And so I'll find these ten awesome stories to share and I can tweet them all out right now but like nobody but me is up. And the people who are up are probably like why are you spamming me right now Abby with all of this stuff. So I love them because I can put them in this queue and they'll kind of buffer or post them out over the week, which is really nice. So this is how they look today. When the founder just had an idea for whether this would work or not, he put up a landing page. It was a simple concept, so he didn't need a video. He just described what the initial version would do, which would be just for Twitter. If people are interested, they can click the plans and pricing button. And when they click it, you get a hello, you caught us before we're ready but leave us your email address. Tweeted that out, people clicked through, they left their email address, he said okay, that's pretty good validation. But not enough for me to go build it because I wanna know if I can actually make a sustainable viable business out of this. So I wanna know if people will actually pay for it. So all he did was add a middle page to his landing page. When they clicked plans and pricing, they got three plans. One was free, but two were paid. People kept clicking through, most people clicked free. But a couple clicked paid and he said, you know what, this is good enough not for me to quit my day job and spend six months heads down building it, but good enough for me to put out that first really minimalistic version and see if people actually use it. And so that's what he did and very quickly, it took him a week and a half, I think, to get the initial version. It was very minimal, but very quickly he had 500 users using it. He even had some revenue coming in, so now he was able to actually evolve the product along with seeing how users were actually using it. Another obviously great example, especially if you're doing any physical products like hardware, smartwatches are all the rage these days is to do a crowdfunding campaign like Kickstarter and actually get people to pay for it before you go manufacture it. Now again, whenever you're doing something that's technologically new, you want to make sure that you can actually get the tech to work. But you don't need to build out the final end all piece. You can do a prototype, make sure it's working. And then if there is enough interest, because you get these pre-orders, then you actually have the money to go manufacture it. So as we like to say in the startup world, these are all great ideas, but ideas are kind of a dime a dozen. It's all about execution.  So I want to spend the second half of this talk talking about what are some development practices that we can use to make sure that we're focusing on the right thing. So make sure that we're focusing on things that add value, not waste, and allow us to move very quickly while continually learning and adapting. So the first thing is just get into this mindset, and this is really painful, but of minimum viable everything. Like you're really excited about the idea. You want to go build this huge thing, but stop and wait. And what is the minimum thing that you can do to kind of get to the next stage? So we've already seen examples of this. If my assumption or hypothesis is if I build this product, people will want it, great. Do a landing page. That's a great way to test it. If your assumption is if I sell this product, people will buy it, you can add a pricing to your landing page, or you can do a Kickstarter for it. Now, if you want to build the product, I think the next thing you're probably assuming that you want to test out is, OK, I have identified who my customer is and what that one thing is they're dying for. And so if I build this particular solution, I'm thinking of that people will use it. So here, what you want to do is think about what Buffer did and think about, OK, what's kind of the absolute bare bones minimal feature set that I can put out? And they kind of say, if you're not embarrassed by your first release, then you waited too long to put it out there. So I don't actually know all the details, but I took some guesses at what Buffer's initial minimum feature set might have been. Obviously, people need to be able to create a user account, link it to their social media networks, add posts to the Buffer, and then edit and delete them, add what your posting schedule is when you want the tweets to go out. Buffer needs to then automatically be able to post from your Buffer to the schedule, and then just let you view a history of the post. So that felt pretty minimal. The thing that you always want to kind of do is go look at, OK, I think this is my best absolute minimal thing. Ask yourself one more time, like, what is it that I'm trying to prove? And do I really need all of these things for it? And so again, I'm making guesses, but I think that what Buffer initially wanted to see is, OK, people will download the app, but there's a big issue with people download apps all the time and never use them. Will they actually post something into the Buffer? And if that's what they're trying to prove, then some of this stuff can go away, at least initially. So if you haven't had anybody post the Buffer yet, you don't need to allow them to view a history of their post, or even edit or delete their posts, and that's painful. But if you see people are using it, then you can kind of very quickly add some of these simple features. Similarly, if you're just trying to address the issue that they don't want to post all of their tweets at 2 a.m. on Sunday, you don't necessarily need to let them set up their own schedule. You could hard code something in and say, this is based on when we found, or the most popular times for people to look at Twitter, people are going to be happy with that. Again, you're just trying to see if they're going to post or not. And then, of course, you don't really need to add Facebook and LinkedIn. Just start with one, whichever one you think is going to be most important. See if that works or not. So that's sort of how the process looks. Now we've gotten down from what we thought was the absolute minimal to only four of those items. And you can get that out pretty fast and see if people are going to be using it. So, OK, you know what features you want to build in now. Now what is kind of your minimum viable software development process to use for this? I'm kind of an agile girl. That's my background. I remember when Lean Startup first came out, I was asked to present at a Scrum Club on that Lean Startup. And I was really excited about it. And I was at, actually, a Lean Startup Meetup. And I was bragging about it. I was like, oh, I'm so awesome. I'm going to go present about Lean Startup to Scrum Club. And one of the organizers of the Lean Startup Meetup looks at me horrified and goes, Scrum? Oh my god.  It's so heavyweight.  I was really embarrassed. But it was a big learning moment for me. And I've noticed that many of my big learning moments have come when someone's kind of screamed at me and may be really embarrassed. I don't know. Maybe that's how I learned things. But I realized who is really right. I mean, when you're innovating on something, you are going at such a different pace and at such a different scale than we're used to in software development that Scrum just isn't even built for this. It doesn't even make sense for this. And if you try to do something like Scrum, it's going to slow you down. And I don't necessarily mean all aspects of Scrum. I think there's still a lot of good theories from this. But in particular, the time boxes that Scrum sets up. In Scrum, you have these sprints that are one week or they're two weeks. And it's really arbitrary. And honestly, two weeks can be a lifetime in the beginning. It's way too long. So I just want to see if anyone's interested. I just want to put up a landing page that takes me. There are tools that you can do this without even coding. You can do it in an hour, right? I just want to do it and put it up there in an hour. Why would I wait two weeks or even a week for the sprint to end? It doesn't make sense. And then to be constantly looking at how our users responding and be able to adapt to that immediately. And so I put up the landing page and I'm looking at the stats and I notice that people are coming to it. But no one's leaving their email address. I say, OK, I should try to put a different message on the page. Maybe that'll get more email address signups. Again, I can just do that in 10 minutes. I don't need to wait for a time box. Even when I get to the point where, OK, I figured out that first version of the product, that's those four features and I'm going to build them, well, say it takes me two days or a week and a half, whatever it takes me, once it's done, I should just be able to post that up. It doesn't make any sense to put it in a time box. Time boxes make sense when you're kind of building towards this actual list of known features. They don't make sense with when you're at this stage and you're trying to figure out those 10,000 things that don't work. So what I like instead is Kanban. So you can start with sort of a simple task board. I'm sure you guys have all seen this before. What's our backlog? What are we working on? What do we have? What have we finished? A problem that I see with startups just do this is that they're in progress. Column starts to look like that very quickly, which is particularly bad when you realize there's like one person working on it. And it's tough because you have, especially if you're trying to actually make a business out of this, even if it's just you're doing it for yourself, you're excited. You have all these different things that you want to be able to build into it. And then you talk to people, and they have ideas. You talk to investors, and they're like, if you build in X, Y, and Z, it'll totally be fundable. And you're like, oh my god, we better stop everything and do that. And if you talk to customers, or potential customers, you're like, oh, if you just built these features, then we would buy it.  I should build in these. And pretty soon you have something that looks like this and nothing is getting done. And so what we're missing from Scrum that was really nice was Scrum had these nice sprints where you'd actually have to finish everything in the sprint before you can then go work on the next items from the backlog. And that was really nice. So we want to still have that constraint in place, but we don't want it time-based. We want it more task-based based on our capacity. So if there's just one of you or maybe there's just one developer on it, you put a work in progress limit on that column of one, meaning everything else has to wait. If there's two of you, then the work in progress limit would be two. So this way you make sure that you're actually completing those things before you can go work on anything else. One thing that might strike you here is obviously I just talked about how you have to be able to move really fast and be really flexible. If that one item is like a two week or three month or whatever long item, you obviously can't wait that long to do anything else. So I would keep these really short. It's a little different for everybody. But I usually recommend that places start off with one day, keeping the tasks less than or equal to one day. The beautiful thing about that is then every single day something completed. And it has this momentum that's going forward. And usually no matter what's going on, it can wait until the next day to pull in the next thing. And while you're working on that, the to-do, unlike Scrum, this to-do backlog can be moved around. Priority order can be changed to whatever you want. It just matters. Once you start working on it, it just needs to stay the same until it's done. But I'm looking at that to-do column. And that still looks pretty overwhelming to me, right?  And I feel like when you get to do columns this long, first off, if you're really early and you're still trying to figure out what the right features are for the customer, how do you even know what all that stuff is?  And you should be just getting little things out in front of the customer to kind of figure out what the next thing is. So first off, a lot of that could possibly change. Second off, like if I'm the developer and I'm working on A and I see all these different things, I'm like, oh my God, when I'm doing A, I need to think about how B and C and D and E and F and G and blah are gonna like work into this. And you get overwhelmed and it slows you down. And so I say, you know, if you want to write all these ideas down, great, put them in a spreadsheet, put them in an op-up or whatever, but put a limit on what you can put in that to do column as well. And I would put, you know, at a maximum, how much you can do in like a week or two. Get rid of everything else, that's a maximum, not a minimum, so it can be less. And then you are hyper-focused on just what are we trying to do this week, right? And it's helpful if it's just you, it's helpful if you have a team of people, everybody's kind of focusing on the same thing. So okay, now you're gonna go start developing it. You wanna think about what's our minimum viable design, which of course we would really call emergent design. I actually, for anyone who has been here for Katrina, has talked very nicely about how to refactor, which is great.  If you keep thinking Yagnit, you ain't gonna need it, you don't know what's gonna come tomorrow, so don't try to build out this architecture that's gonna scale to a million users when you have zero users. The truth is, a lot of startups build a product, it's totally wrong, they throw it out, they build a product, throw it out, build a product, throw it out. So you don't need this built up architecture, you're just wasting time, and that's sort of what Eric Rees was talking about, when he thinks about the difference between value and waste. Similarly, you don't need to go design, for we like to follow all these principles, like okay, I'm gonna hook Buffer up to Twitter, but I know other social networks are coming in, so I better do this abstraction layer so that it can then easily be replaced with Facebook or LinkedIn, but in order to do that, I kinda have to research a little bit about the different social networks we might use and the differences between them and how you interact with them, and then I have to figure out the abstraction layer, which is really hard to do, until I built one and oh my god, just do it for Twitter. And then, if later on you determine, okay, we're gonna need to add another social network in, great. Refactor it, figure out what the best design is for it at that point. Just keep thinking Yagney, like very aggressively, much more than you might on a normal project. So okay, you're developing the code, you're moving really fast. I know that this looks a little bit water folly here, but these are kind of generally the steps that you're gonna be doing when you're doing development. And if we think about okay, if a big success factor, a big indicator of success, on whether or not our products are gonna be accepted in market or not, is understanding whether the customer is gonna like them or not, then in kind of learning that, then we wanna look at this and say, okay, where is our learning occurring? And so, there's some learning that occurs when we do requirements, because hopefully we've gone out and we've talked to customers, we kind of deeply understand what their problem is, and we're trying to come up with something to solve for that. But really, most of the learning about our product happens when you release something, put it in their hands and see how they actually use it. And unfortunately, the place where we spend the majority of our time, and as developers is often the most fun, there's very little learning that happens here. And so, the question is, how do we maximize our chances for success? How can we maximize this learning that's going on? So another way to look at that is to say kind of how do we shorten the timeframe between when learning occurs? And so instead of doing a whole bunch of features and batching them up and putting them out, a great thing to be doing is continuous deployment. I put a little smiley face, because I'm very happy that there's like a whole continuous deployment track here today. So I won't go into a whole bunch of details on that, but I did want to kind of talk about how some startups are using it. So Etsy is fantastic. If anybody's doing continuous deployment, they've got a terrific blog that talks about what they're doing. They're currently deploying 50 times a day. Actually, I got that stat about a year ago, so it might even be more now. But anyway, in 2011, they deployed 10,000 times to production amongst 100 engineers, which is pretty extraordinary. And what they said is, ever since we started deploying so many times, ever since we started deploying 10,000 times, our system is so much more stable because we've already done this 9,999 times. Like, we got this.  So before, when they were only releasing once every few weeks or maybe once a month, they were constantly having to pare down what actually went out because they were like frantically trying to make the release.  If they do, we can either pull it back and kind of build it out or we can just quickly add features to it. It just gives us a lot more flexibility. Another example that I like a lot is Ash Moria. He has done a lot in the lean startup space. He was actually one of the really early lean startup practitioners when there was just theory and he's like, okay, I'm actually trying to do this for a startup. How does this really work? And he had this great blog which he's since turned into a book about kind of his experiences. And so I feel like, so his company at the time was called Wired Reach. I feel like they were one of the early practitioners of continuous deployment and he just kind of compared his before and after experience with it. And what he said is, before they were doing two week release cycles, after they were releasing multiple times a day. Before releases were all day events, like I know I've been there before when you're like, oh my God, and it's frantic and the whole team's like trying to make sure it works right. Now that they release all the time, releases are non-events. Before releases were 100 lines of code, now releases are under 25 lines of code. And before they had a lot more emergency releases because they'd only put something out every couple of weeks. If something didn't work, like it was such a big deal to have to go release something again because it was like an all day thing to release it and they had just deployed such a huge amount of code that it was really hard to find where the error was. Now, it was no big deal. Like if they pushed out a release, it was like a couple lines of code. So A, they could either just pull it back in or go look at those couple lines of code and find the bug in like two seconds and do another release. So it was no big deal. So I really liked kind of that before and after and how much easier it makes things, which I don't know, I feel like it's unintuitive. You feel like it's gonna make things harder and it actually makes things easier. So I kind of like, I feel like I've heard that a lot in Agile. Like if you're not good at something, just do it a lot, right? And then you get really good at it. And then one other thing that Ash Moria does, which I really like and I feel like continuous deployment makes this a lot easier, is he actually adds a validated learning column to his Kanban board. And the idea is that a feature isn't actually considered done until they've put it in front of a user and actually watched how that user behaves with it, either in person or through analytics that are going on. And I really like this because now it actually builds learning explicitly into the feedback cycle. And the idea is hopefully that learning that you get is now going to feed, figuring out what your next features are. So that makes a lot of sense. So I just got the 10 minute warning, but I guess I'm a little bit ahead of time, so we'll have time for questions. These are the patterns that I have seen time and again for successful innovators. And thank you for your time. So yes, so questions, yeah. I'm sorry. You didn't want my cool hacker check up there? This is kind of just to add on to your Kanban. We use Kanban, I love it. I think it's definitely better than Scrum. One thing that you mentioned the learning column, we have sort of a review column. And I find that really helpful because it's like this pause in the development where people think that they're done, but it's nice to have a time for reviewing the pull request, making sure the PO's are on board, making sure QE's on board. And I think that's really valuable. And with Kanban, you can kind of add in whatever you want. Yeah, absolutely. So how do you determine when something is ready to move out of the review column? When something's ready, it's when the developer thinks that they are finished with the feature and they put it in review and that's when everybody basically reviews the pull requests and comments on it. And only after then, actually our QE department then is the one that's responsible for merging it into the release because they're also kind of watching the pull request and they can say, okay, this looks good, everybody's happy with it. And it kind of gives them the control over what goes into the release as well. Nice, thank you. Something I've seen people do is say basically, well, if it's not perfect when I put it out there, people will get the wrong impression about what it is and not try it later. How can you combat that when people say that? Because I worked with some people who were doing a startup for like two years and they never put anything in front of anybody and I was trying to convince them to actually put something in front of somebody and they're like, well, but then they might not use it later. Right, so I have several different answers to that. So I'll just run through a few of them. One is actually a personal pet peeve of mine. I said I kind of hate the term MVP, but it's like a love-pate relationship. I feel like people have taken the MVP, the minimum viable product concept, a little bit too far and I feel like people started creating MVP with crappy product and I don't actually advocate putting out a crappy product. So I just want to be clear on that. I feel like you could do a very minimal feature set but not have it a crappy experience. Another thing that I would say is, and it also, you know, it depends so much on who your user is. Different users have different tolerance levels for this so you have to be sensitive to that. But another thing that I would say is I hear sometimes startups say this concern when they have no users and I'm like, so who are you going to offend? You don't have any users today.  Maybe you'll actually get a couple by doing this. If it's that absolutely terrible, you had no users, you can create a new company name, right? I mean, that's extreme but you don't have any users yet, right? The third way I would answer this, however, and actually it's funny because I did a talk here for constant contact and I had a great slide but it's not here anymore. I have this great example of TripAdvisor doing something very similar to this. So TripAdvisor, actually I don't even know, they have a lot of users, right? Millions of users, I guess. They sometimes have ideas for new features but you know, they like this lean startup principle and they don't wanna go take the time to go build a feature until they know if people want it or not. And so with their hundreds of thousands or millions of users, they will do something. Sometimes they gave me an example, they're like, sometimes we think maybe what we should do is actually make hotel recommendations, right? You can go on TripAdvisor and you can see all the reviews but wouldn't it be nice if TripAdvisor just recommended one for you? They're like, I don't know, would people want that or not? And so they actually like just put a dialogue box up as soon as you loaded the TripAdvisor page, like you didn't even like click it into a hotel or anything like just boom, right in your face, super obnoxious. Do you want us to recommend a hotel for you? Yes, no. If they said yes, it actually gave them an error message saying system unavailable. Like it was totally ghetto, right? It wasn't even elegant. But the thing is they have so many users coming in that they were able to put that up for like two hours and get, I don't know, like 100,000 tests from that. And they were like, that's really good. And we pissed people off for two hours but we got this great test. And no one's, we're not losing customers over this, right? So those are my three very different ways of answering that. Does that help? Hey, Abby. I know Dropbox got lucky with posting in Hacker News and gaining 70,000 users just overnight. What are some other great ways of acquiring users? So what you really, I don't know that I would totally say that they got lucky. They did get lucky in the fact that they had a very easy way to reach their audience but I think they knew who their audience was and their audience were these heckies who happened to hang out. And so that is sort of the answer is figure out who your people are and where they hang out. If you don't know where they are, there's actually another story of Pinterest. Apparently when Pinterest first released, they had like 3,000 users very quickly because the team was very well connected. Like I think they'd been through iCombinator and stuff but I think like all of their users were actually like them and so like other young like 20-something techies who probably lived in the valley and I don't know, Pinterest's target market is probably like moms in the Midwest or something. I don't know. It was not the right target and so they had these users and nobody was using it and they're like, oh my God, I don't know how to reach my users. And so they tried to think of who would be the people who would use this type of thing and they realized that people create these, I don't know what they're called, vision boards or something, like physical boards where they do collages and they put up pictures that they like and things that inspire them and so they actually created pin it forward meetups. I think it was called. So physical meetups to bring people together who were interested in this stuff and what they said is not a lot of people came but the people who came, I guess they let them do the vision board and then let them do it online. They were so excited about it and that was kind of the momentum that they needed is to start reaching these passionate people who could then spread the word. So long answer but you need to just figure out who your user is and where they hang out. Yeah, what's a good way to control for false positives and validations? For example, say I built an app, I put it up on Facebook, I get a thousand likes, I feel great and then I check the next day and have zero signups. What do you think is a good way to control for false positives? Yeah, I think you just have to be careful about what you're actually proving because it is, I don't remember the stats but the stats are really abysmal like in the number of mobile apps say they get downloaded and never use and so that's almost a false positive too. And so kind of be very deliberate about what is this actually going to test? Is it going to actually test that people are just curious and will download it or can I actually put a feature in there and see if they use it or not like Buffer did with that first like week and a half release? Thanks very much. Thank you.