 excited to be here. And today I want to talk with you about how we can bring animations to the web. What you should go home with after this talk is actually to have a better understanding of where animations are coming from and how the history looks like. Also, which tools and APIs we can actually currently use to transport animations to the web today, and how we can create our own animated components in Ember.js to actually leverage and create these animations today. And before we get into the full topic, I want to shortly tell you a little bit more about myself, for example, what I currently do for work. And here I actually have the really great joy to also work with Ember on a day-to-day basis, which is really great, with a company that is called Leadfeeder, which offers an online lead generation tool for sales teams to better understand who visits the website and how they can help their customers. Also, what is interesting for me is what I actually do after work. And I'm from Berlin. Here in the background, you can see the very beautiful Alexander Tower. And what I like to do here is enjoy the vegetarian alternative cuisine of the city. Portland should also be very famous for that, so I'm looking forward to this this week. Also, I'm a big fan of art, and I like to draw myself. And what I also like to do is engage in the text scene in Berlin. So I'm one of the co-mentors and organizers of different workshops of open text soup, which tries to offer free access to learning resources about technologies. And also, just recently, I started with two other Ember developers based in Berlin, Clemens Müller and Joschka Kinscher, to relive our Ember Berlin jazz meetup. So if you ever happen to be in town and actually want to say hi, please do so. We would be really happy to see you there. But there's also a really great passion of mine that brings us much closer to the topic of this actual talk. And this is cartoons. Since I was a kid, I really like cartoons, as probably many others of you as well. And if we think about animations and cartoons on a more abstract level, we realize this is nothing else than actually animations that we see on television or in the cinema. And the interesting part about this is we as developers actually think about so many other different things when it comes to animations. We might think about something like UI elements that have specific animations, once we hover over a button that we just created for our web app. Or we might think about something like smooth page transitions with Ember liquid fire, which we already saw in the former talk. Also what comes to our mind are things like data visualization with SVG. So this is something that also helps our users to better understand what is happening in a web app that we're building. And by the way, if you're interested in this specific topic, I highly recommend you to check out Jen Weber's talk on SVG animations interactions tomorrow. But summing this up, all these elements that we can describe under the category of informative UX. So everything that informs our users actually what is happening on the website and where they should be heading is something that I won't talk about today. Today I want to talk with you about how we can create stories and actually tell narratives on the web using animations. So with that said, let's maybe have a look what an animation is actually consisted of. How can we actually define an animation and what are the basics of actually creating traditional animations? Probably the most well-known and very first example of classic animation like frame by frame animation is what we see here in the background. It's a sequence of images taken by the photographer Edward Mulbridge already in the end of the 19th century in which he in very strenuous work actually had to take 12 different images of a rider riding on a horse along the Palo Alto track. And he would collect his images, put them onto a disc and a specific device that he could use back then in the 19th century to actually create animations. And here's a reconstruction that you can see of this kind of like impression that you get looking through this device that if we see these images in rapid succession it seems as if this rider on the horse is actually literally riding along the cross track although it's just a composition of different still images. If we take a look at this example and realize an animation is not much more than just the sequence of images that is shown in a specific frequency and that would later on create the illusion of motion to us. And this effect is something that is not inherently the essence of animation itself. It's something that actually is mostly powered by our brain. What our brain actually does is it has a specific resolution for like changes in our visual perception and an interesting work by a psychologist called Max Wertheimer described this phenomenon as a fee phenomenon. And he realized that with images that we see that has been shown in a certain delay that is lower than 200 milliseconds or optimally around 60 milliseconds it will give us this illusion that there are not two distinct images. There's actually a motion between these two images that we see. And this is quite interesting. We can use this actually to create animations just by still images that we show in this certain time frame delayed. So with that said you might think now okay this is like 150 years ago. How is this relevant to us today? But the good thing is the story of animations continues until today. And we as developers might find really interesting. Can we also bring this to our most loved platform that we know actually the platform of the web? And yes actually we can do. And in the next part I want to show you which kind of tools and APIs can be currently used and have been really vividly used in the past to achieve this. There's really no pun intended right? But probably many of you here in the audience can still vividly remember that there was a specific tool used for over a decade to create animations on the web. And you might also still remember when its first release was with what actually literally 20 years ago. In the end of 1969 the first release of Flash was out. And this kind of like multimedia platform enabled us to create games, animations, many other multimedia content and also deliver it to the web. But as many of you know the popularity for Flash decreased many developers abstained for actually still implementing that in the websites. And they were kind of like shifting to another space where you were like, okay we can't really use this anymore, there's a lot of controversy around security issues with this platform and also the browser support is not really given because when the browser's opted out of still supporting that. But luckily already quite a while ago but in 2014 really officially accredited by the W3C we have a new hero on the horizon. And as many of you know, now I already got it away. The zero is called HTML5 that's right. And with HTML5 you get a lot of this very lovely things that we used to do and to create in Flash. Also out of the box we get like video elements, we get access to an audio API and also we get animations just out of the box implemented for us to use and create new features on the browser. If I talk about HTML5 animations, I use the term very loosely. So although the HTML5 spec is very specific to certain features around the specification, I will also include all the cool features that we get from CSR3. I will also include open source JavaScript libraries that are based on HTML5 specifications. And many others that I cannot really go into further depth in this talk, but just to give a short summary of what we can use, we realize there are many things out there that can be used to create open web standard powered animations. And the big advantages of open web standards is obviously that they are open. This actually means for us developers we actually have insight in how the specifications are made and you might even have the power to influence how they are further progressing in the future. What we also get is a certain consistency. As these technologies mature over different browsers over the years, we realize the features that we built now on these open web standards will play for a very long time into the future. We get a lot of reliability in our code and realize this is something that is meant to last. And also the really great thing is because the web is so omnipresent, we can actually reach our users with the animations we create based on this open web standards on any device, any time, anywhere we want. So there are a lot of advantages around this concept of embracing open web standards to create content and specific animations. And interestingly with regard to other things that we used before, for example flash to create animations, we might think what about actually about the experience for all the people that don't have a really strong background in programming. People who are maybe not so familiar with the web as a platform and that really love to use graphic user interfaces to create the content and also tell the stories that they used to tell in the past. And if we have a look at that, we might kind of further investigate how this actually unfolds. And in this regard, I found a really, really powerful quote by Rachel Naborz and about winning cartoonists and also web animations advocates in the community. And she is talking about the concept of an endless canvas which kind of describes the possibility to create animations and tell stories on this almost endless possibilities that we have on the web. And she describes her transition from coming from traditional media to actually create cartoons and stories to the web as very empowering because she realized that all the new specs that were coming out, especially HTML5 specs were actually quite approachable to her although she was not really familiar with the knowledge behind it, but she was really keen to try them out. And to give you an understanding of what we're actually talking about and actually doing something with Ember in this talk as well. Let's maybe have a specific look at, yeah, a demo, something that is actually also based very similar call to an canvas, especially specifically the HTML5 canvas API used in Ember. The HTML5 canvas element is an element that we can just drop into our HTML. It comes with the canvas tag. And what we gain from that is actually the access to a very powerful web API that we can use for many, many things. So if you're, for example, interested in WebGL, you might already relate it, but we can also do traditional frame-by-frame animations with that. So that's pretty exciting. So let's have a look at that. The canvas context object is very crucial for understanding how we can actually achieve this. The context object is something like our toolbox. Once we actually get a reference to the HTML element that contains canvas, we can then get the context object with the GetContext method. And once we have this, we can actually draw on the canvas. We can set colors and background images to the canvas and get all the great things from the API. And what is also interesting to note here, the Bravo support for HTML5 canvas and the, yeah, I would say, basic features from that have a really great browser support. So this might not really relevant to you. And yes, we still have users relying on ES7 or EA8 or something. But if you do, it might be worth noting that you might have to pull the full of these features or think about a fallback for anything that you do on the canvas. So let's maybe have a look on a specific example of how we can actually create an animated component. First of all, we would have to create the component. So we could have a comic panel component, let's call it like that, with a certain width and height. And later on, we could, yeah, just describe the tag name on this component to actually create our HTML element later on once the component renders. Then interestingly, we would have to think how do we achieve this effect of the frame-by-frame animation? We learned that we want to show the certain images of the animation and rapid succession. What we would like to do is, first of all, create a sprite sheet, so like a collection of different images into one single file, which helps us a lot later on in the web app to actually just load one file and not hang into reload with several requests as several subfiles for this animation. And what we can do here is think about getting certain frames after each other and actually putting them on a specific destination of our canvas element, one after each other. And in the HTML5 Canvas API, we have a really handy draw image method, which enables us with the coordinates of the upper left corner of the source image that we want to map and the origin of the canvas space that we want to actually occupy with this image and the width and the length to map this onto the destination of our element. And if we have to look at this how this might unfold, we also realize where do we actually get the image from, right? So we would first have to load this. And what we can do here is actually create an instance of an image in our element component once it's actually initialized. And then we can say, okay, we grab the haze and the width of our spreadsheet because obviously we also want to know where does the next frame actually start and where does it stop. And we can only deduct this from the length of the spreadsheet and also from the number of frames that it actually contains, right? And later on we would like to load this image and once this actually is done, we set this object instance here in this example called pseudo image as a property on our component. Then if we move on, we would also like to actually draw something. Also just as a disclaimer, I cannot really go through the full code. So if you realize at some point, okay, there's some gaps or something, I will also link to the original wrapper of the demo so you can still look everything up that you're wondering about and also feel free to ask me afterwards. But yeah, if we do this, we create the draw function. We would define all the different coordinates of our spreadsheet and also the canvas object that we want to map to. And what we can do here is first of all, clear everything that we drawn before. This comes in handy later on if we actually loop through our drawing function which we have to do to actually create a succession of frames and then also we would actually have to draw the image with the draw image function that I explained earlier. And if we do this, we can finally get our context object. We can set a context property that can be reused in other functions in our component as well. And then we can actually draw. And the interesting thing here is as well, we actually want to wait before until the image has loaded, right? That we preloaded earlier in the initial solidization so it might be come in handy to actually wait for that. We can, for example, do this with an observer. So with that, with that said, okay, now we have a drawn image to canvas. Okay, cool. I could have just used an image tag for that. We, yeah, we actually want to make it move. So let's do that right now. And if you want to run something, there's something really handy that we can use in Ember as well to actually iterate over something over and over again. And this is called the Ember run later method. And here we can actually say, okay, we have a certain function that actually draws everything and clears everything what we've drawn before. And we can call it again, again after 100 milliseconds, which we already realize is a quite good interval to actually create this illusion of motion to our human eye. And also what we would do is call a function that actually increments our frame number because everything in our drawn function is also dependent on the frame number and will then recalculate which part of the spreadsheet we actually want to map. I won't show it here in this code example, but you can look it up later on in the repo. And also what we have to do, if we, yeah, click on the play button later on, it would be cool to maybe also pause it at some time point. I mean, animations are really cool, but they shouldn't be there forever, right? So really simply we just set reference to the current run loop as a property owner component. And then later on we can cancel this again at some other part in powerful action. And yeah, if we do that, let's maybe have a look at the demo. So what we can do then is just like play it and then also pause it. So our raccoon guy finally can jump off the building and actually save a gentleman from getting his hand back picked by rubber. So the day is saved. What's also good to know about HTML5 Canvas for you, performance wise we get like a lot of advantage by not having to rely on DOM objects being loaded in the background to actually create these animations. The HTML5 Canvas MPI is really low level. So this means everything that we do on the canvas, even if we create a lot of different layers on it is not powered by specific DOM objects and a lot of like memory in our browser that has to be used up. So this is really good for performance if you do something more heavy. And it's probably also one of the main reasons why WebGL actually relies on HTML5 Canvas. We also get a lot of control as a developers on what is actually happening in our animations which is also really great. Creative experience wise I realize we have to do a lot of kind of like lifting before we get like just six frame animations kind of running and also kind of like interactable with us. So I think this is something that might be quite approachable but maybe also to improved and also accessibility wise we realize there are some obstacles we have to jump over to actually make it accessible because we actually just rendering images into a flat object in our browser that doesn't give us access to any kind of attributes that might be used by screen readers or any other accessibility devices. So this is just like a summary and for getting this in a better context on how we can this compare to other browser APIs let's have a look at another API that maybe not so many of you might be familiar with but I would like to know actually like a hands up who has ever heard before about the web animations API? Like anyone here? Okay, actually quite a few, cool. So maybe some of the things now will be a bit of a repetition for you but I see a lot of hands didn't go up so this might be really interesting for some of the people. Yeah, the web animations API is something that is quite cutting edge and I believe it's actually the animation of the future, the future of the animation and we get from this API a lot of like control to actually synchronize animations and also get play-based control of the box which is really exciting so we don't have to do any heavy lifting for that and yeah, if we then think okay this is all cool then let's have a look at the browser port and then realize, oh okay we go to can I use.com screenshot us from this morning and realize well a lot of red, a bit of olive green, this is not so good, right? A lot of like this doesn't really work yet so okay that means that's a no, right? We can't really use it yet but luckily for the web animations API we already have really, really well maintained polyfill out there which is really great and this actually enables us to use features of the web animations API already today to create animations on the web and also for many features that are not even in this kind of like accepted draft states yet but just like still in a very kind of like discussional mode we even get another really cool web API polyfill called the web animations next polyfill and there's of course also an add-on for that so you can just install, and by install and by web animations next polyfill and you get all the kind of features that are currently in draft state out of the box in your application so let's have a look how, yeah this looks code wise the web animations API largely depends on key frame effects and key frame effects if you look at them they look really similar to the key frames you already know from the CSS3 spec which I think is really cool because it means if for example I'm a designer or someone who's like very familiar with CSS3 I already kind of know where this is coming from and what this is about and we also very similar to the key frames in CSS we get that all the key frames that we list up in one single list will be distributed evenly across the animation span so if there are three they will all be triggered at time point zero, 33% and then later on at 100% so pretty straightforward we can kind of get our head around that and yeah let's have a look how we can actually create also an animated component that's similar to the example before if you want to do that we can first of all have our comic panel component again and we also create a new sprite sheet that we actually want to animate in this component and we would actually create the key frame effects and for this to happen we would first of all have to have key frames defined we already saw some of them and what we also need essentially for every animations are animation options so these are the definitions that we usually know from CSS to actually find how long an animation is what kind of timing function you want to use interestingly for our key frames animations we actually don't want the animation to ease we actually want to stepwise go through the animation and we can use this really handy steps function that enables us to just put in the number of frames that we want to show and then later on actually animate through it infinitely as we have to find here we can pass this in in our comic panel component and once we have actually done that we can already very easily start our animation with just a few lines of code once our component has rendered we can just say we get all the key frames we get all the animation options that we have passed into the component and the only thing that we now have to call is this element or this dollar reference to the element that we're on and then animate and this is it so we already have an animation running out of the box just with this few changes but interestingly yeah this is really not so super exciting because I've seen cartoons most of the cartoons usually didn't involve the comic character just like running in front of blank screen there was stuff going on behind and stuff so I actually want this as well so let's have a look how we actually can create multi-layered components this is also possible with web animations API and how would this actually look like if we want to create several layers it might make sense to actually create some sub-components we could for example imagine that we have comic panel layer components that are embedded in our comic panel and what they could actually do is taking care of binding the key frames to themselves as elements that should be animated because the web animations API is dumb based so we just have elements that are animated with the key frames and then later on if we have created this a comic layer it could call a frame action that kind of like set these key frames to the parent component so the comic panel and just how this looks like to actually create these key frame effects we can use the key frame effect constructor and this will actually create a key frame effect that can later use can later be used in the web animations API to be played back to us also in the parent component the comic panel we can then very easily just with a few lines of code say okay we grabbed the timeline so a global object in the web animations API that lives to give us feedback on which animations are currently running and actually give us access to them to play and pause them and we can take the key from effects that we already get from our comic layers and later on use a group effect constructor one of the features by the way for which you would actually need the web animations next polyfill and with this we can say okay please group together all of these animations in one single instance and if I call play or pause or even reverse this also comes out of the box for the web animation API on it then please do so for all these animations that are embedded in this group effect. This is really great and what we can then easily do we create some actions for it we create a play action, a pause action what they do is really simply calling the play and pause method that we get from the web animations API and we are already good to go this is really fascinating so yeah let's just have a look how this looks like so we have a background that is already rendered as a single layer and then we have the character and if we just hit the play button and if we hit the pause button we can actually iterate through the different key frames that we have already provided with the spreadsheet which is really exciting we can do a lot of more things than that we can add more layers in the foreground we could also create single DOM objects that kind of like swirl around the foreground just imagine we had some leaves that could also be there which is quite exciting and pretty straightforward to do if we look at this instance of API so that's quite exciting and I really like to check it out with this example what's also good to know with the web animation API as a contrast to HMFA Converse we realize that it actually has quite an approachable create experience so even if I'm not a JavaScript Guru yet I kind of like understand where everything is coming from and it's very easy to set up once I actually use the polyfill for right now but it will be even easier in the future I still have lots of develop control I can define how many objects I actually want to render in my animation and I can also easily gain access to different ways to animate it with the key frame effects and also accessibility wise it's really straightforward for us to make this accessible because it's so much powered by DOM last but not least also something to consider if you would have like thousands of different objects that you want to animate this might be quite of like difficult performance wise compared to HMFA Converse at least because we realize for everything that we try to animate in the web animations API we would have to a specific DOM object that is actually created so yeah it's quite hard to argue about that but for something that is not too complex I think it's really still an interesting thing to look into so yeah we are almost at the end and let's just like get a conclusion of what we have found with this example that we have looked on so far so first of all we realize the story about animations and how we can create and deliver animations is not over it actually is still continuous until today and we have even more than ever tools and methods to actually do this and yeah the good thing is with Ember and also with the power of web standards we are actually pretty good to go and with that said I would say the endless canvas is actually now used to be animated and I'm really looking forward to see what you will create in the future so thank you very much for your attention and yeah have great fun at EmberCon