 All right. So, hi. My name is Marcus Helberg. I work as a developer advocate at Vaudin. I've been doing web stuff for the last 10 or so years, everything from front end to enterprise Java systems with me. I've got Yoni. So, hi. My name is Yoni, and I'm a product designer at Vaudin, and I've also been working on the web for over 10 years now, and actually at Vaudin also over 10 years already. And today we're here to tell you why we think, and like Comcast just now showed us, why web components and the web platform make so much sense in business or enterprise context. Great. So, just to give you a little bit of context of where we're coming from, our company, Vaudin, has a 16-year history of helping developers and companies build web applications with a Java-based framework that we have. Now, that framework comes with a really big library of components. So, in a way, we've been building web components for about 16 years. So, you can imagine that we were pretty excited when web component standards started coming out. What that allowed us to do is take everything we've learned over the past 15 years and translate that into a new set of components that we can run directly on the browser. By doing that, we can have a much larger audience of people who are able to use it, and also all the framework users that we already have get access to a much wider library of components. So, in the talk today, we want to really make the case for why we believe that the web platform with all these new features coming out really makes sense for business applications. We also want to highlight the things that we, at Vaudin, do to help this become reality. So, how we build high-quality components internally, how we improve compatibility with other frameworks, such as Angular 2, and finally, how we make web components customizable so that they fit into your company's look and feel. Now, in this talk, we want to focus on business applications. I know a lot of the material and a lot of the talks on progressive web applications and web components tend to focus more on websites and maybe web shops, but we want to make sure that people developing business applications also understand that these are technologies that really make a lot of sense when doing these applications. What I mean by business application is the types of applications that really help run a business. They're in a very critical part of running that business. They're more often internal applications, and they tend to have very long life spans. So, even if you start building one today with the latest and greatest technologies, five years down the road, it's still going to be in production and running something you probably consider legacy technologies. And I think business apps get a pretty bad rap. They don't need to be slow and ugly. In fact, these are the applications that a lot of your users spend their entire working day working on. So, it's really important to be able to deliver a good user experience to these people. And that's what we at Bodin have made it our motto to really fight for simplicity. We want to make it as simple as possible for developers to build great end user experiences. The way we try to accomplish that is by giving the developers the tools and the components that they need to really build these great experiences. So, if you're checking the bingo card, you can do it right now. Let's take a look at the reasons why we think that businesses should use the platform. So, first off, when we're talking about business applications, especially the internal-facing ones, these are typically built with a very tight budget because they don't directly bring in any revenue to the company. So, building on the web platform, we can really save time and effort by focusing all of our work on building one great application instead of spreading our effort into building two or three different applications on different platforms. So that means that there's less for us to build and maintain. It also means that we don't need to have separate teams within our company that have the skills that's needed to build all of these different apps for different platforms. Also, it takes care of the distribution problem. We don't need to go around updating people's computers and devices. We can just have everyone use the latest version. And this ability to stay updated is something that I think is really a strong suit for the web platform. So, if we think about these web business applications that have a long lifespan, it means that somewhere down the road you'll have a need to update it to stay relevant and to kind of address things that you couldn't think of in the beginning. But at the same time, the application is in a very critical position in your business, so you can't just, like, toss it all in the garbage and start a new project. With the web platform, we have the possibility, like Taylor mentioned yesterday, to incrementally upgrade our app in place. So, for instance, we could take our application, add a service worker to it to make it work better in poor or no network conditions. We can also find the kind of problem areas in our application and start replacing those with web components. So, that can allow us to start bringing in this component-based thinking into our existing app without needing to re-architect the entire surrounding application. Then, later on, if we do decide to do our entire rewrite of the application, we can bring those components along with us. So, this re-usability that web components allows us to do not only across projects with the same framework, but a lot across projects that are using different platforms or different frameworks is really something that I think is unique to the web. And in a business context where you have apps that are written years apart with different technologies, that's a really big thing that allows us to bring a consistent user experience through all the different applications. Now, we're not quite there yet. There are still a few things that we need to work on to get this level of re-usability that we want to achieve. One is how do we make web components work great together with all the frameworks out there? And two, how do we make web components so easy to customize that we can just drop them in any project and make them look like as if they were built for that project? But before I get into that, I want to bring Yoni here to tell us a little bit about what it takes to build a high-quality business-grade component. Yeah, so what do we actually mean when we say business-grade components or enterprise-grade components? Is that like stuff for people in suits in fancy offices or gold-plated buttons or something like that? Well, of course not. So for body elements, that means components that you need when you build these complex business applications. Now, these components might be more complex feature-rich ones or more seemingly simple use case-specific components. Now, all of our elements are open source on GitHub and we test them with the latest Polymer versions and we provide support for them to ensure compatibility and functionality. And we build the elements as a seamless extension to the Polymer element catalog. So combining all of these element sets, you kind of have most of the components that you need when building a complex application, like the expense manager demo application that you're seeing right now. So we used our data grid, date picker, combo box, and upload elements together with some paper elements there. But apart from the visual feature that the end user sees, what else is required from a business-grade or high-quality component? To put it briefly, it's quite a lot of work. First off, you need to consider both end users and developers alike. Starting from end users, there's already multiple aspects there that you need to take into consideration. First, usability. Can the user accomplish a certain use case with your component and hopefully with ease? There's accessibility. Can the user perform that use case regardless of their own abilities? Does your component load, initialize, and respond to user interaction quickly? Responsive design. Again, can the user accomplish those use cases regardless of their device, screen size, or input methods? And last, robust or complex interaction design. Does your component handle the user input and interactions as intended in all of its different states? That's especially true for these more complex business-oriented components with a large number of different features that need to work nicely in concert, no matter what the combination of those features might be. Like Taylor also mentioned yesterday, in yesterday's keynote, doing all of this work on the web is very hard. So it requires a lot of specific technical knowledge and attention to detail to get things right. And I also want to thank the Polymer team for actually providing us tools to make this a lot easier. So that covers end users somewhat, but there's developers that you need to treat with equal respect for a component to be considered high quality. And again, for developers, there's usability, but this time from the point of view of the API. So is the API of your component intuitive and flexible? So can the developer make the component do what they need to do in their app? Similarly, does your component, is it usable together with various text sacks or layout environments where the developer might want to use it? And last but not least, like Comcast mentioned many times, great documentation is really necessary in order for developers to learn how to use your components efficiently. Now this seems quite a lot already, even though it's not really an exhaustive list you need to consider. So how do we actually succeed in building these high quality components? How do we attain the complexity? So I'll give you a brief look at how we do this at Vardin internally. Yeah, we basically do the regular agile process with these, so regular design, development and testing cycles. Even though it's not a really formal process that we follow there, it is on a high level how we do things. And it applies to like the whole components as well as to the individual features of those components as we work on them piece by piece. So we start with design. And that begins by identifying the use cases that we try to cover with the component or with the feature. And those use cases usually come from existing projects, customers or users directly. And as examples, when building a data picker you might have just simple use cases like, well, select a date near today or select your birthday. And for us, it's not very difficult to come up with these use cases as we're rebuilding some well established UI patterns. But it's still a good idea to check that those patterns are still valid today and accommodate any new requirements such as small viewport sizes or touch input. And it's also a clear place to apply our motto and fight for simplicity. Now, researching existing solutions and reusing the parts that still hold up is a natural next step. But we're still not afraid to pursue and experiment with alternative or unconventional designs like with our data picker here. So we could have easily gone with this more traditional page calendar design. But we wanted to see if this alternative of an infinite scrolling calendar list would actually perform better. So once you have some designs, you usually want to validate your assumptions somehow. So you might not be sure of your alternatives, which one is the best, or you might have some technical uncertainties that you want to validate or clear out somehow. And for that, you build something you test. So prototyping is the next step. The type of prototype you build or use depends on the level of complexity of the use case, how confident you are in the design, or what type of feedback you're looking for to get with the prototype. So for example if a design, if you want to know if a design is technically feasible, you probably want to actually code that in the browser to get a really concrete feel of that. Or if you're just unsure if something is visually prominent enough for end users, you might just go with a static or animated mockup instead. Now again as examples for our data picker, one early prototype that we did was this iOS or a version that mimicked the iOS calendar app with this zoom-like interaction. And we wanted to see if that's actually feasible to do in a browser. So we ended up coding that actually and seeing that work in different devices. Another one later on was that we wanted to get a more tangible feel of the dual scrolling list that we had as an alternative design. So before investing time in prototyping that in code, we actually just did a clickable image-based prototype that we did some early usability feedback or user testing with to get more confidence before actually doing something in code. And yes, like I mentioned, testing that's the primary purpose for your prototypes. You want to learn something from them. And those code-based or clickable image-based prototypes work great for end user testing. But for developer and API testing we need or we usually do something different. So we have an API design available. We have some use case that we try to cover with that API. And then we draft some code examples based on those. So we use kind of the API already even though it's not implemented yet. And then we just show that code example to different developers and get feedback directly on that early on. And before we ship a larger set of stable features like 1.0 we do these more formal usability tests both for end users and for developers. So we bring in more users and actually give them tasks that we want them to accomplish with our component and then we just observe and take notes during the session and so forth. And of course we do the more traditional compatibility testing on top of this so to make sure that our components work with as many framework, browser and platform combinations as possible. And based on the learnings sometimes we end up changing the designs. So with this iOS like zooming design we noticed that well the performance wasn't that great on some devices so we ended up designing something else. And with our, we learned also with the image placed clickable prototype that users didn't actually have any more trouble selecting dates using the infinite scrolling list and many actually preferred it so we went ahead with that design. But we also noticed that we can actually combine the separate calendar and year and month scrolling list into a single view with this dual scrolling interaction that you see here and that's what we ended up shipping. And that's actually one of the last important steps in the cycle. So once you have confidence in your designs and your implementations you actually want to ship some features and other fixes after you have the confidence. And that's one really important aspect of this is great components that they have a roadmap how those are going to be how the components are going to evolve and how they are going to be maintained. So we use semantic versioning for our components and what's the same for all of those versions basically that we're constantly looking for feedback. So please try out those versions early and provide us feedback as much as possible because in that place a big part on our maintenance and support efforts. So we try to respond to pull requests and issues as quickly as possible and we also have an active chat and form where you can ask questions from the team directly. So don't hesitate in contacting us. And in addition to these we also offer commercial support in case you need that. Now speaking of support one question that we get a lot is how about Angular 2? So I'll let Marcus tell you more about that. Great. So yeah as you probably know since web components are built using web standards they work great with a lot of the frameworks and tools out there. Namely those that work directly with the DOM directly with the web standards. Now there are some other frameworks that abstract a little bit away from the DOM and bring in own concepts for doing stuff like data binding which means that in some frameworks like in Angular 2 web components don't really work as great as we would hope them to do. So in order to help fix this issue we at Bodin have created a universal Angular 2 to Polymer adapter. So this handles things like custom CSS and shady DOM operations. It ties in with the data binding system and it makes sure that the components work in forms and with the validation that Angular 2 has. You can install this on NPM and once you've installed it you just import it in your module as Polymer element. With the Polymer element imported you will declare it for every Polymer component that you want to use. In this case we're using both a Vodn combo box and a paper input. There's no special support needed to build into the Polymer component itself. The wrapper will take care of all of that. So with those declarations in place we're able to use these Polymer components just the same way as we would any Angular 2 component. So here we can see that we bound the value of the combo box to the input and we're able to do a two-way data binding between them. Next up we're going to talk about something that I think is really exciting, something we've been working on for a while and something I know a lot of people in the community have been asking us about what if we can't do material design? What if we want to have web components that look like our company? So Joni? Yeah, so how do you customize the look and feel? Like Marcus said earlier it's one of the aspects of reusability and compatibility that you want to affect how things look from project to project. And one thing we get asked a lot is that, yeah, web components look like a cool technology but our company design guidelines don't really allow material design. So how can we change the look and feel? And we're running a survey currently and I've pulled some direct quotes from there that highlight this issue. So there's one person saying that, well, it doesn't provide look-less elements, you're pretty much stuck with material design. And another one saying they would like better decoupling of look and feel from code like paper essentially buys you into material design. So it's a real issue for web component users or Polymer users. So while paper elements are awesome, the features that it is great, just changing fonts and colors is not always enough and you might get this face when you're trying to do something. But you might also be thinking that aren't there multiple existing CSS frameworks for theming web applications out there like Bootstrap, Foundations and what have you? And we use those. Well, one big thing is that those existing frameworks rely on specific DOM structure and specific CSS classes to apply those styles. And as you know, that doesn't really play well with Shadow DOM because you need to have complete control of your internals of your components in your whole app. And that kind of defeats the purpose of the reusable components, right? So you should be using custom properties and mixings instead. Another thing that the existing frameworks commonly do is that they require a build step when you try to want to customize some things in the theme. So while that might be a okay thing to do on a high level when you're theming or customizing your complete app or multiple components at the same time might be fine. But for individual components they should not rely on any build step to provide their theming capabilities. That also again kind of doesn't make them really portable or reusable in multiple places. So we want to get rid of this build step as well. And we kind of already can. So standard CSS already has most things that we need for theming. So just a quick checklist of things that preprocessors usually offer. So variables check. We have custom properties now shipping in multiple places natively already. Mixings, that's in the spec coming up. I don't think it's natively shipping anywhere yet, but the shady CSS polyfill or shim does that for us. Basic math, it's something that you sometimes need when doing customizable themes. Well, that's really well supported already with the calc function in CSS. So we got that covered. And these three things are just essential basically that we need. And it could be also almost all that we need. Now there might be some limitations with the shady CSS shim, but once native support gets better, we actually get more benefits with the native inheritance and cascade of CSS. And one extra thing that I'm really looking for in the future is color computation, which is already in the CSS specs but also not shipping anywhere yet, and we don't actually have a good shim for that either. But once that comes out, it finally closes the gap between CSS preprocessors and standard CSS, so we get color computation in the browser. And all of this is actually then runtime, which opens even more possibilities for theming. So you can adjust things runtime. Now, so the future for theming looks bright, I would say. And we've been researching and prototyping this for a while with our components. And we want to bring you or offer you the possibility to really get a nice starting point quickly, which you can then start customizing further to get the app that you or get the look for your app that you really need. So these are just mockups at this point, and early prototype code, but it should give you a feel of what we're after here. So similar to paper elements, you should be able to customize the high-level stuff of your theme using custom properties, like the main colors in your theme, the overall sizing and spacing of your components and fonts and that kind of stuff. Now, in addition to these, you should be able to quite easily adjust other visual aspects as well, like rounded corners, border styles, gradient, shadows and stuff like that. And this level of customizability is a real key feature for web components, like to make sense in a business concept, when you can have these reusable components from project to project and you can still make them look consistent within an app. And looking for an implementation point of view, each component should expose similarly named mixings for different parts in their internals, like subparts, and for different states of those subparts. And at that point, the components should basically look quite look less as the one person said in the survey, so they shouldn't provide that much theming capabilities per se, like if you compare to a native input. So they should be quite bare minimum styling there. And then we can start building on top of that, like a theming layer and define our, for instance here, like the global styles for our input elements, wherever they may be. So we want our inputs to look like this. And then we can apply those styles at the same time to any of our components that actually use an input element or text input somewhere. And the idea is that then we have these multiple starting points, different type of themes for you to begin with, and might offer different kind of features themselves. And then you can take one of those as a starting point and then start fine tuning and customizing and tweaking from there on using the mixings and custom properties that theme offers, like to really adjust that border radius on that one button right there. So we have all of the elements that you've seen in this presentation available already. So go check out the website for more information on those. And we're really excited to get you this stuff hopefully already this year, some early stuff. So stay tuned for that and briefly back to Marcus still. All right. Thank you. So I hope you see that we're very excited about all these new advances on the web platform. And we really look forward to seeing how we can use them to really make our developers' lives easier, make it easier for them to provide great end user experiences. So we have most of the bottom elements here today. And we'd really love to talk to you. So if you see anyone with a reindeer shirt on, come and say hi. We would love to talk. A final thing I want to mention is that we're running a survey currently on trying to figure out how people are actually using web components and progressive web app technologies in the real world. So if you have about 10 minutes to spare on your way home today and want to help us kind of affect the future of these technologies, please go to the link and fill in the survey. Thank you. Thanks.