 All right, thank you. So I'll try to wrap it this very quickly because we are obviously running out of time. So hello, my name is Mati. I work for Vadan as a developer advocate. And yeah, so Vadan is my employer. We are based in Finland. And today I'm going to talk about some design thinking that we are doing and applying at Vadan for increasing the reach and interactivity of our components. So what I'm going to do is basically giving you three examples out of the box. And we can discuss them. So the first example is when Android devices gets announced generally. And here I don't mean a specific company. I mean in general. Whenever a new Android device with huge specifications, technical specifications, and all these kind of things gets announced, we then find that it doesn't get the amount of popularity as much as iPhone. And it's always a wonder why iPhone gets more popularity and more market. If from technical point of view, we compare between an Android device and an iPhone, then this is the best way to describe an iPhone from technical point of view. Regardless of whether you are an open source and you like technology and privacy and security and all these kind of things, if we take a random person in the street outside of this room and we give this person $1,000, and we tell them that this money can be used to buy a new mobile device, which mobile device you think this person is going to buy? Statistically, most likely they're going to buy an iPhone. And the reason behind that, of course, marketing and all these kind of things, but also because users don't care. So yeah, we are in an open source conference. We talk about open source, but users don't care. You cannot pitch to users that my software is best because it's an open source. And you cannot pitch because it's secure or it uses specific technology and these kind of things. So this is the design thinking number one. You need to choose technical specification versus usability. If it just works, if it's just intuitive enough and if it's just easy to use right away, then users will use it. And well, in an ideal situation, if you can combine both usability and open source and security, then you are probably on the ultimate best. The second example I have for you today is Amazon. So again, because we are technical people, most of us think about Amazon as data center, servers, back end computing, and stuff like that. But again, for people in the street, probably Amazon for them is a way to ship devices and for online shopping. If we pick bigger audience, like for example, many places in Europe or Africa, for example, or many places in Asia, for them, Amazon actually is a cool place in Brazil. So this is just one word, how the word is translated in many concepts or many perspectives. And this is also an important thing when you are developing a new solution. You need to think what is your target audience. We at Vauden, we are targeting developers. So we are targeting this portion of internet users. Don't do like us. Try to target the blue person. So if you want to target the greater audience, African people, Asian people, well, we are in Asia, right? So European people, American people, and everyone in the world is completely different design perspective than targeting only developers. And again, this is related to also mentioning the kind of technology and the kind of open sourcedness that you have in your design. Mentioning that for the user, they don't care. So this is a note number two, using familiar tools that you are familiar with versus targeting specific users. So mentioning, for example, that you are using native C++ code or mentioning that you are using very complex assembly optimized code doesn't help the user. What helped the user is basically the final output. The third example that I'm going to go over it very quickly is Twitter. So anyone can spot the, oh, we have four twitters now, but there are only two, OK? So can anyone spot the difference between those two's Twitter? One big highlight. Sorry? One's in French. Both of them are in French, isn't it? Oh, yeah. Well, yeah, they are different in the language. But there is one more difference. Sorry? The what? OK, that's a good observation. Actually, the biggest difference between both. So both of those are taken from my Android device. And the big difference between them is that one of them is a progressive web app. And the second one is actually a native app. And this is actually what I want to highlight. So if we go quickly and make a comparison between the native app, which is this one, then we're going to see that to get the native app, you need to download some 25 megabyte. You're going to ask your permissions like access a notification, access a camera, and so on. And if it happened that it's your first time ever to download the Twitter app, or it's a new device, then you will not get the features of auto-fill and automatically remembering your data, and so on. And it's going to also not remember across other apps. So if it happened that, again, this is a new device and you are installing for the first time, and then you download another app like Facebook, or Google Plus, or something like that, then it will not remember your data, and you need to refill it again. And whenever there is an update, you need to re-download a lot of new data, and so on. And the cost of development from technical point of view, the cost of developing this is quite expensive, because you need to manage multiple platforms, multiple different devices, and so on. Versus the second one, which is basically exactly the same. I didn't modify the picture or anything. This is a progressive web app running from the web directly. To load it for the first time, it took me almost a quarter kilobyte, it doesn't ask for permission, it progressively asks for permission. So at this point, it didn't ask for anything, but when I try to access a camera, then it's going to tell me, hey, can I take permission to take your camera, or your location, and so on. Because it's a browser-based, so Autofill is out of the box, as well as everything that I enter here is well-remembered across other apps. And I'm guaranteed to always have the latest version. Every time I open this app, I'm guaranteed to be given the latest version. And here we're talking about the platform. So we develop only once on one platform, and then it's available everywhere. So this is a huge difference. Now, when I tell you, again, 24 megabyte or 25 megabyte, maybe you feel like it's a small number, what is this number? Actually, let's put it in this context. Would you wait for a website to load after 25 megabyte? Like, you have to wait for 25 megabyte for the homepage of a website to load. Probably you will not. So this is a huge difference between a progressive web app and a native app. And from a user perspective, if you are a big fan of developing natively and developing on a native context, do your user really care? Of course, if you're targeting developers, then mentioning that I developed this app with Objective-C or with Kotlin, maybe you will get more attention. But most likely, most users don't really care. Remember, your user just wants some things that just work. They probably don't care about what kind of processor, what is the RAM capacity, what kind of things, all those kind of things. Now, what is the big idea about progressive web app? This is a kind of modified joke taken from the internet, asking about what kind of pre-installed app that we can have on the mobile device when you buy a new device. Why do I have to install all the apps? And the answer is internet, isn't it? So we have seen this happening recently. We have seen that cloud took over. We have seen that mobile also is taking over. We have seen that people are moving away from normal executables files, .exe file to the browser. And then we have seen people moving from desktop usage to the mobile. And here I'm not talking about developers again. I'm talking about users. We are seeing clearly that the majority of traffic is coming from mobile or tablet-based devices. So the important note that we need to take care of here is that is it really worth it to advertise about your fancy technology, or is it worth it to care about user experience? And luckily, there is a term for that. It's called progressive web app. I mentioned it briefly earlier, but I'm not going to talk about that. I mentioned it briefly earlier, but basically the first person that announced about this name or came up with this acronym was from Google. And now all the big companies and all the big players in the market are adopting this. As I showed you, Twitter now has a version of progressive web app. So I don't have to install Twitter anymore on my mobile device. I can just use the progressive web app version. And it's coming to other platform news websites and so on, and there is a huge support from it even from Apple. So if you're on the beta version, you're going to see support for it. So what is progressive web app? Progressive web app is not a new framework. It's not a new programming language or anything like that. It's just design specifications that you need to add to your application, web application, to make it progressive. And it comes from the name itself, progressively understanding the user and eventually make it fast, feels native, and so on. And my highlight today is the offline first design part. So making it also work offline. So I want to take these Twitter applications that I just showed to you and I want to fly and still be able to use it. Of course it doesn't make sense, right? Because tweets is about lifetime. Sometimes it makes sense if you want to see recent tweets, recent messages, respond to recent messages, respond to them and then it syncs back when you connect to the internet. So two topics today, offline first design and how is that related to web components or how we are doing it with web components. Gonna go very, very quick over this. So web components, have you heard about web components before? Two, three, okay. So actually web component is a standard. There is a huge reading about it like what is the standard specification and how to follow it and so on. But I like to summarize it in this picture. So this is actually a video. It was played on Facebook page and we see that if we inspect it, it's actually a video tag. It's not a flash plugin or anything like that. And when HTML5 appeared, when HTML5 appeared it made this possible and we have seen that video tag can be used. But the fact is, it's not actually like one big tag that produce a video player. It consists of something called shadow DOM that consists of divs and spans and a lot of things. So basically it's kind of encapsulation or object oriented concept inside the browser that we see inside the video tag. And luckily now the standard make it possible for developers to produce web components. So having the power of some stuff related to object oriented programming available inside the HTML DOM. And here I would love to share a small experience that we had at Vadan comparing what we had in our framework before using web component and after using web component. So in Vadan framework, before using web components, we used to have a set of UI components but they only work with Vadan framework because they are designed for the Vadan framework. And if you are using the framework and you want to extend it with other add-ons, then you need to go to the directory and see the contributions. They are all open source of course but still limited to only this add-on. And it's a bit challenging because you need to be expert in this field to be able to modify those add-ons and so on. But after using web component, now the whole concept is changing because it's standard. And when we say it's standard, it means that it's interchangeable. We can use basically pretty much any web component it can be used with the framework. And at the same time, if somebody designed a UI component for our framework, then it can be used elsewhere as well. So yeah, that was like a quick comparison between before and after web components. What is the benefit? So only in two years in the directory there is approximately 1,300, or a little bit less than 1,300 open source, freely available web component that not just work with our framework but can also work with pretty much any modern framework such as Angular, React, and so on and so forth. It's a big deal, isn't it? The second concept I have for you today is the offline-first design and how we actually can perform it. So offline-first is my favorite because it's the only way to guarantee 100% always on user experience. And it's my favorite because this is really what matter from user experience point of view. So this is all what I was advocating about from the first because we need a better design. We need to reach better user experience. So having an uninterrupted experience and having the user still using the app while moving around is how to reach your user better. So how to do that? There are a lot of ideas, like for example, caching. So it's a website, we can just cache it and that's it. But the challenge with caching is that it doesn't work with dynamic web applications. So caching can be perfect for a static webpage and so on but let's take a very small example like a contact application. So I have a list of contacts and then when I click on a contact, it should display a form displaying my picture and email address, first name, last name, and so on. So this is not gonna work because it requires some kind of dynamic data changes. Luckily, there is offline storage inside the browser. It's perfect, there is a lot of nice frameworks that do that as well. Down, or the limitation here is that it's one way storage. So you take the data from your database and store it inside the browser. Now what if the user modified the data offline? How can you synchronize this data back to the server? Of course, you can write your own solution but the data replication part is there are a lot of attempts that are trying to help those and today I'm gonna highlight two solutions. The first one is Firebase and Firebase is, well Firebase used to be an independent solution before it got acquired by Google. It was excellent in doing this out of the box and works on mobile devices as well as web applications but now you have to understand that it's owned by Google. So the servers are owned by Google and you have to pay Google and you have to store everything on Google. So it's up to you, you decide. But the other solution that I love so much is PausDB. So PausDB is a Apache 2.0 solution available freely open source. You can see from the GitHub that they are very active and this is my favorite solution up till now. Of course there are other solutions but to just summarize how the solution works. Basically you implement your application in this way. First of all this is your client side and this is your server side. Now instead of making a direct communication between your client side and the server side you make it work with PausDB and PausDB gonna make automatically bi-directional replication with the server. So instead of communicating with the server it's gonna do that out of the box for you. So now what will happen if you lost connection? No worries because your client side still works with PausDB. So from your client side implementation nothing gonna happen and PausDB gonna take care of managing the data offline and synchronizing it back to the server. I have also a demo for you that is showing you how this basically can be done. This is a screenshot of early phase of the demo and just to give you an idea I'm gonna show you the final version. So if you go to my GitHub you're gonna find it here offline first app. The good part about it so this is a final version after a lot of modifications and a lot of improvement and the best part this is also on how it look like on mobile device. There are steps showing you step by step how I migrated from a normal application just started a very normal application HTML based and migrated it to be an offline first application. The whole idea is simple just breaking the connection that is happening from your client side to the server to be going to the PausDB and then implement a PausDB layer on top of your back end server. So if you are interested please do follow this project or contribute if you are interested. This is a continuous project that I'm continuously trying to improve and show how it can be done. But if you are really into this I'm also trying to do it with other languages like Angular, Polymer and yeah I have done it also in React but it's not here you can see it in my repositories because it's not really ready yet. But the idea is simple I'm trying to use web components and I'm trying to make them work offline in an application. Now this is a link for the applications that I just showed to you now. And finally the challenges. So what are the challenges with this concept? The first challenge is the initial load of the data. So you would expect that if you are connecting this with a database and then you have a big database like one terabyte of data or something like that you don't want your user to wait till one terabyte of data gets downloaded on his device assuming that he has one terabyte of available storage. So this is something that you need to really architect from the day one to know how to take a snapshot and very specified snapshot for this user to be downloaded. The second challenge is the security of stored data so now you're exposing a database level data and store it inside the browser and this need to be really taking care of in term of authentication, wiping the data if you log out and so on. And finally the race condition which is something that will happen in real application the only problem here is that it might happen more often that I modify the data offline multiple users modify the data offline and then when we connect back online we're gonna have the race condition. Luckily there is a solution for that. A PowerDB provides something called best guess merge but if you don't like that you can fall back into for example asking the user okay the data got modified when you were offline and I cannot save the data what to do. So ask the user what to do or just implement your measuring strategy but this is something that you're gonna face even if you are implementing an online application just it happened more often. Now well I had some talk about also comparison before web component but I can basically summarize it here so we had a small article talking about how to do that in Java but after using web component I figured out that it's a little bit tricky to do it as a standard way. Luckily we have improved and showed a standard way of including web components inside a Java application if you are into the Java part. Last thing I have, well I'm running out of time but last thing I have. Yeah, sure we got a lot of minutes. Okay, okay right. So the final thing I have for you today is a practical test. I'm all the way talking about design so I'm also telling you how to test that your application is best suitable for design thinking. The first thing is make sure that it's mobile first design and by mobile first design I mean that when you are testing your application test on mobile device. Don't test on desktop. Don't test on an emulated desktop. Don't test on an emulated browser. Just test on device. That's the real meaning of mobile first design. If it works on mobile then eventually out of the box it's gonna work on desktop. The second thing is touch first design which is also think that your user doesn't have a cursor. So they cannot reach the small icon on the top left corner. They cannot reach if there are two links or a drop down menu or something like that they cannot click on it. So make sure that the user has a big fat bump when they are clicking and navigating around your application. The final practical test is coffee first design. I made up this one which is basically give your tester a cup of coffee and a mobile device on the other side and see if your user will be able to navigate across the application and do everything without splitting the coffee on top of his device. So if he can manage to do all of that with one hand then you are on the good side. If you are not really with the coffee design then maybe you can take the drive design. So make him drive a car and see if he can crash. So that was everything. This is again the link for the GitHub. Please do follow it if you are interested. Another article I have for you related to Java with progressable maps. Other than that, thank you so much. If you have questions, do I have questions? Yes, so before I take questions, currently and furthermore if you are in the room please therefore, please therefore, Ben.