 Hello, everyone. I'm Maria, and I'm working towards my PhD at ETH Zurich in Switzerland. And so for my research, I'm experimenting with UIs that are distributed across multiple devices. And in this talk, I'm going to tell you how I use Polymer for that. So we have more and more devices including phones, tablets, watches, and TVs. And I saw many people around here that have brought their laptops, and I assume that most or maybe even all of you also have brought the smartphone. So you already have at least two devices with you. However, we still mostly use these devices in isolation, except maybe for some cloud-based synchronization for things like files and email. However, there could be benefits if we could use multiple devices in combination, for example, to have more screen real estate. And I took this photo here of someone who's shopping for wine on a train, and they're using their phone to access the shop. And at the same time, they're using the tablet to get reviews on a specific wine, so for the same wine that they're looking at in the shop. However, in this case, there is no coordination between the two devices. So the user has to manually select the same wine first on the phone in the shop and then go to the tablet and look at it there as well. So for the user, it might be nicer if they could just select the wine on the phone and the tablet would automatically show the review for that same wine. Another benefit of combining devices is that we get a richer set of input and output modalities. So in the scenario that you see here, it's easier to scan a document with your phone because it has a camera and it's more mobile. But once you have done that, you may want to continue your work on the laptop because it has a larger screen and it has a keyboard, so that might be more convenient. UIs for multiple devices are also interesting in collaborative scenarios. Here, for example, you can see a group of people using both personal devices like a phone or a laptop and shared devices like this tabletop or a tablet. So researchers call applications that make use of multiple devices at the same time cross-device applications. And as part of my research, I'm trying to make it easier for developers to build such applications and for that we have created a library that uses Polymer. So if you wanted to build such a cross-device application, you would need to address at least the following three things on top of the usual single device development tasks that you will need to do anyway. So first, the state needs to be synchronized across devices. So if the user clicks a button on the phone, the other connected devices need to be informed somehow that something has changed. Second, the UI needs to be distributed across multiple devices. And you need to decide what part of the UI should be shown on what device. And for that, you also need some information on the kinds of devices that are involved in working together. And third, the devices need to be connected somehow. So there needs to be some way to tell the system that these two devices over there are working together, and the other three devices are also forming a group. And so our library offers support for all these tasks using web components. And we are going to look at how you can use the library to build cross-device applications by looking at this sample application of a webcam viewer. So it's a pretty simple application that shows a large image of a webcam on a large screen, and the user can pair a phone and then use the phone to control the camera angle and select the camera to show. The application was built using less than 300 lines of code in client and server combined, so also mostly in the client. And you can find the code if you want to have a look. There's a link to the GitHub down there. So here's the screen cost of the application. To pair the phone, I could just scan the QR code that you can see there, or I can just copy it onto this emulated phone. Then I can use the buttons to control the camera angle. I can go back and forward in time. And then when I flip the phone, I can choose a different location to display. And let me show you the most important steps now for building this application, and we'll start with state synchronization. So if a user interacts with the device on the left, they trigger an update to a shared view, so to a shared model. And the model is shared over the networks with the other devices and will then trigger updates to the view of these connected devices. This is somewhat similar to something you might already be doing with Firebase. However, we use WebRTC peer-to-peer connections if the device is supported. So WebRTC is a newer protocol that allows devices to communicate directly, so they don't have to go via server, which you would do with websockets. So this lowers latency significantly, especially if the devices are in the same room and the server is remote. And this is kind of our expected scenario in cross-device applications. And here's how you can do this in Polymer using our library. In our application, we define what should be synchronized by creating a property with our state. Here I've named the property synced, but you can choose any name, essentially. And at the moment, you can synchronize arrays and objects, and you need to provide a label for each. In this case, we use time, camera, and position as our labels. And with this, we synchronize the time of the photo to show which camera to select and the angle of the camera. Then you can use this XDNBC synchronized web component and use two-way data binding to specify that the synced property should be synchronized. Now you can write code as if all of your code was running on the same device, but the library then takes care of the synchronization for you. For example, I could have a bit up there with the iron selector, where we select which camera to show, and then use this information to display the correct image in the code. As I said, you can write code as if it was all running on a single device, but you still might want to specify what part of the UI should be shown on what device. And for that, we provide a couple of templates for what we consider common distribution patterns. And one of these is the remote control patterns, where we use phones to control a larger screen. And we call the phones controllers and the large screen we call the viewer. And again, here's the code. So you add this controller layout component to your application, and then inside this layout component, you need to add a controller class to everything that should go to the controller devices, and the viewer class to everything that should be shown on the viewer devices. And that's it. Finally, the devices should be associated somehow, and we chose an approach with identifiers in the URLs. So when you load the application on the large screen, it will modify the URL and add this connect parameter with a random ID. When another device loads the new URL, the devices will be paired, and the URL can be encoded into a QR code and scanned by a device. Or in another scenario, you could also send it over instant messaging or transmit it using NFC. And we call the device that displays the code, the connect device and the device that scans the code, the connector device. And again, this is how you add the functionality in your application. There's again a custom element for that. So you add this URL pairing component, and the component will take care of modifying the URL for you, and it will handle the pairing. For the webcam application, we specify that the connector device should be assigned a control role, and the connected device should have the viewer role. We then use this information for the UI distribution that I showed you in the previous step. But if you don't have any use in your application for this information, you don't have to use it. So I've shown you how to build the application, and next I'm going to speak about why we chose to work with Polymer. That thing, custom elements are great. Declarative code is very readable. I can get a quick overview of an application by just looking at the HTML. And for us, it was all important to have code that works across platforms and on all kinds of devices. So if you look again at this picture that I've shown you in the beginning, you can see there are a lot of different devices. And we want the code that we could just write once and run everywhere in Polymer and meet that requirement. Then the Polymer concept just seemed to be a good fit for what we are trying to do. So two-way data binding integrates well with idea of state synchronization. You just hook everything up and it works. And under the hood, we use conditional templates for the UI distribution. So we wrap things in a DOM if and decide whether it should be rendered or not. Modularity is also important. As a developer, you can choose the level of support you need. Maybe you want your own way of distributing the UI fine, then you just don't use the pattern templates. The same goes for pairing. You don't have to use the QR codes. You could implement your own pairing component if you wanted to. As a PhD student, I don't only do research, but I'm also involved in education. We have used our library and Polymer in various lab projects as well as bachelor and master thesis. And students had varying levels of experience with web technologies, and some had even no experience at all. And none of the students had any experience using Polymer. But the students usually become productive quite quickly, and I think the declarative style is helpful for that. And I have to admit that the documentation of our library is not in a perfect state, but the students learn how to use it quite quickly by looking at sample applications. They can use the DevTools and click on a component and inspect the application. And for this, it's important that Polymer uses the platform, and the component is a custom element that they can inspect. And it's not just a bunch of diffs. Now, I'd like to give you a quick tour of an application that was built with our library and Polymer. It was built by three computer science master students at ETH, and they did it in one semester, which is around 14 weeks. They were expected to work around 300 hours each on this project. So Switzerland has this stunning landscape, and it's the perfect country for mountain biking. And as their projects, the students build the mountain bike trip planner. There are other trip planners out there, but they tend to not work too well on mobile devices because there's so much information like charts and maps that it's really hard to squeeze it onto a small screen. So our idea for this application was that when you're out with your friends or your partner, you could just pair your devices, and then you'd have a bigger screen. But we did not want to limit ourselves to just using smartphones. So for example, if you had a TV in a hotel room, you should also be able to use that. So we wanted an application that adapts to whatever devices you throw at it. And here's a quick video of the result. Two phones on the left are already paired. One shows a map and the other shows a summary of selected routes. And they are synchronized. So when the new route is selected on one device, the other device updates. And when we add a third larger device, the UI redistributes. And there is room for more information like the elevation chart in the left corner. So what were our experiences in this project? As you may have noticed, the students have used material design and the paper elements to build this application. And our students usually don't have that much experience building UIs when they arrive in our courses. But I think the paper elements here were really helpful for creating a nice-looking application. And because the students could use our cross-device library, they did not have to spend much time on implementing the cross-device functionality. And instead, they could focus on the main features of the app. They enjoyed working with Polymer and also find the concept of web components very intuitive. And one student told me this is how we should build web applications. And on that note, I will end my presentation. Thank you.