Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I have the pleasure of interviewing Rachel Nabors. Rachel is a speaker and a developer as well as a writer and an animator. We will talk all about those things in today's episode. Of course you can find her street cred on her website as well as in the show notes at spec.fm. Thank you to today's sponsor, hire.com. If you are a developer designer and you're looking for a job hired may be the perfect place for you to start. We will talk more about hired later on in today's episode. Welcome Rachel to the show. Hi, great to be with you Jonathan. I am happy to have you. Looking through your list of accomplishments, your street cred, you have been on many of the podcasts that I look up to. Being the first podcast that got me into podcasting was non-breaking space. Christopher Schmitt, who actually had me on his show a few weeks ago. Christopher is a great guy. I love any chance I get to hang out with him. Yeah, he's a blast. Then of course you were on ShopTalk and the web ahead and a few others. I encourage everybody to go and listen to those episodes as well. And today we're going to be talking about a bunch of stuff. But Rachel is responsible for a lot of movement in the web animation world. A lot of discussion has come from Rachel on this particular subject. So I'm really excited Rachel that you are on the show. Thank you. I'm excited too. I've been catching up on some of my back episodes today just to over prepare. Do you have? Okay. So I like to ask this. When somebody says that they've been listening. I like to find out, you know, what is their favorite so far? So far, I think my favorite has to be opinions, ally or enemy. Because this is something I'm noticing more and more in the web animation space. I started getting into web animations back around 2011 with CSS 3 animation. Now, I think they'd only been around for maybe two years. And I had, it was like, brought all the creativity I wanted into this, into my code. And it was wonderful. But there weren't a whole lot of people talking about it. Everybody was really ragging on flash. And most of the flash developers were high-tailing it out of their niches to go find work sometimes in motion design, sometimes in front end developers. So nobody was really talking about animation. And that of course, I ended up getting into it and getting a lot of opinions. And what was it you said in your show? You said that opinions are good when there's not a lot of information? Yeah. So I believe, and I'm having to rewind my brain back to that episode. I've done enough of them now where I actually don't remember everything I've said. But in any case, opinions are a good thing, right? They can be a good thing. But they are always a good thing. If there is information that opposes your opinion in some objective way, then it's important for us to be able to flex with our opinions and be able to learn honestly. It's true. And so now, now animation is being tugged into the spotlight and everybody is forming their own opinions. And of course, I got here first, and my opinions are the best. Yeah, of course. But sometimes I have to remind myself, it's like, well, are we trading opinions here? Are we trading facts? And if they're trading facts and you're trading opinions, you need to update. And if you're both trading opinions, then it's fine for you to have different opinions, just acknowledge them as such. So it's interesting going from this place where I was kind of talking to a sock puppet of myself to having actual conversations. And I really enjoyed your episode on that because you got into some of the ways that opinions are good, opinions make us go out and seek information to bolster them. They make us try new things. They make us seek out this discussion. They can also be bad if we cling too tightly to them. So I want to make sure that as web animation expands and there are more people having more opinions and contributing to the community that I am viewing those opinions and sometimes facts with open eyes and not letting many years of highly opinionated monologue, getting the way of that. I'm really glad you brought that up, actually. I think this could be a really good discussion and kind of like a post-mortem on that episode because I have some more thoughts on this subject. It really is one of those core, deep, principled discussions that people have about art versus science or this kind of deeper thing where you have expression versus analytics, right? Or you have, does this animation accomplish my mission, right? My desire for this thing to be a certain way even though it's not accomplishing some business goal or some metric. And how do you measure that objectively? Yeah, and that's the difficult part, right? And so that's why it's important to not do away entirely with opinions as is such a common thing for especially the engineering minds. Right. And for me as an engineer to say, oh, well, if you don't have data to back it up, then it's worthless, right? But it's not worthless. There is some value there. It's just a different type of value. I think one of my favorite things to remember was that Albert Einstein would have these really good ideas. And the worst part of having those ideas was then having to turn around and do the mass to prove that the idea works. Sometimes you have a really good gut instinct. And then you will get challenged. The developer will come up and be like, well, I use say that this will make the users think it's faster. But I spent last week shaving that time off of the render. So prove it. And then I have to go, all right, hang on, trot all the way back to a bunch of scientific journals from the 90s and do my research, then come back and justify it. And it's good exercise in its own way. Sure, yeah. Sometimes it can be frustrating. Like, can't you just trust me? Can you trust me? But then would I trust somebody who is asking me to buy all of their things, hook line and sinker without showing any evidence of their worth? Sure. Well, in another piece of this is that as we build history into our practice, right, as software development continues to get older, there's all these common tropes and all these idioms that we follow, like, don't repeat yourself or separate your logic from your presentation or whatever. And we take these things at face value. And because maybe they are useful in most cases. And then we create this kind of black and white if you repeat yourself, you are wrong. That's more of a historical experiential kind of thing than it is a black and white always kind of rule, right? If we take this experience in these opinions and we turn them into rules, then we forget the nuance of the craft. We forget how important it is to continue learning new and better ways of doing things. That is so true. One thing I've noticed is that people turn, I mean, I just watched from how animation has changed from like 2000, 2013 to 2016 and three years. We've learned so much and some things have changed. For instance, earlier this year, I ended up in a Twitter argument with a couple of people in the web animation community because one of them was saying 60 frames per second is life like. And I actually had just found out that that's not true at all. 60 frames per second is just sort of, you know, a capstone, hardware performance measurement. It's got nothing to do with what's realistic to the human eye. Human eye doesn't even see things in frames per second. It sees things as motion smears and we can see up to 200 frames per second. And so there are certain circumstances like say you had a really long LCD on a wall, right? And you're moving a ball of pixels from one end of it to the other very quickly, like in one second. Your brain would actually see that as janky because the ball can't move across the screen fast enough to create a continuous motion shape in your eye. You would need to add something called motion blur, which is used in the gaming industry and has many arguments about whether or not motion blur is better than a high frame rate. They already have these discussions. So I ended up in this discussion and I realized that I even have slides in some of my decks that say things like, well, just get it up to 60 frames per second and everything will be fine. It's actually not quite true. That is doing people a disservice because you can imagine how bad is it going to be in 10 years if people are still throwing around this 50 frames per second benchmark when we've moved on and we need to start talking about adding motion blur directly within the browser. So it doesn't really help. You have to be really careful what you say so that people are making sure that they're able to make decisions as their information changes and that they're not hoisting you up on a pedestal and saying, well, I told neighbors I said this, so that is true and you are a liar, sir. And it's important to equip people to make their own decisions admit when you're wrong and try to get people thinking critically along with you. It's a cool. I would say that last year was the year I realized that I have to be a little bit more careful about what I put out there. I'm not just demoing CSS to animations and saying this is really cool anymore. Right. Yeah. Well, you mentioned a really interesting thing. This idea that 60 frames per second is somehow correlated with the human eye capabilities, right? Which reminds me of my short-lived interest in human factors. I wanted to go to school and study human factors. Oh, nice. It's super interesting stuff. Absolutely. We have certain parameters around our existence as human beings. My fingers can only spread so wide, right, before it becomes uncomfortable or before I no longer have dexterity. And so when you create a keyboard, bigger or smaller isn't really an option because of a human factor, right? A lot of times, though, we mix human factors with technological factors and you pointed out a really interesting one. This is mostly a technological factor. The 60 frames per second number because a lot of refresh rates are right at that number, right? Right. Do you know the reason why 24 frames per second versus like the 23.97 frames per second? What was the reason for that difference? Just a random question for you there. The 23.97? I know. I've never heard of this. Three points, something seconds in the article that you sent me actually in preparation for this interview. You said you're going to learn after effects. You'll see this preset. There is a 24 frames per second preset. There is a 23.9 something frames per second preset. Of course, 30 frames and then 60 frames and then the abysmal 15 frames per second. But in any case, all of those are like presets for a historical reason. And usually it has something to do with technology. I can't actually answer that one for you. But I can't show you. I'll have to look it up and put it in the show notes. That the history of film and studio animation is littered with arbitrary frame counts like that for various reasons. You know, it got it close enough for the amount of time it took a person to hand crank of la la la. It's just, it's, our frame rates are pretty arbitrary. One thing is now 90 frames per second I hear is the next benchmark because that's the frame rate at which virtual reality starts. Well, let's just say under 90 frames per second it starts looking chunky. Sure. So to cast that illusion of reality, you, wow, I think we're going to see browsers hitting for 90 frames per second over the next couple of years. That's just a 2016 prediction. Well, I just hope that most people will start believing in higher frames per second, like at least hitting 30 in their web animations and their CSS because there are some really janky sites out there. And Adi Osmani, one of my favorite writers in the space has talked about Jank quite a bit. Do you recommend Adi or anybody else in terms of performance on those animations? So I tend to follow what the Google Developer channel posts about performance, especially with animation. They, they put out such cute videos that they have good high, high values and they can sit down and eat your lunch and watch someone talk to you about how to, how to use Chrome's rendering tools to spot bottlenecks. But honestly, when it comes to animation and improving its performance, you really can't go wrong with targeting opacity and transforms because across pretty much all browsers today, those things are pretty optimized. And I want to put out a small warning about following the Google Developer channel too closely. People don't always use Chrome and Chrome's engine renders things a certain way. So what might work great on Chrome could totally bomb in Firefox or Internet Explorer or iOS Safari. Do you have to test in all of them and testing frame rate in different browsers? That is harder to do. But most people, they just run it through Chrome. Look, see it's hitting 60 frames per second, give it the thumbs up and head out. And they don't think about the rest of their user base. Yeah, I totally agree with that. Chrome is perhaps one of the best at animating things, right? And if you are only targeting Chrome, then you're forgetting that that animation work that Chrome is doing and that all of those other browsers are doing is much more complex than just what you would do with JavaScript, right? It's much more optimized. In fact, I've actually had, this is just another little tip for you all. I've had issues recently with animation and the layering of the animations, different divs on different Z spaces, basically, because I didn't have my box model correct. Like there was some issues with positioning. And basically that was breaking the entire animation. And I could turn the animation off and the layering would be correct. And then when I tried to animate it again, the layering would be off. And so if you're going to go into animating things, make sure you have all of that stuff figured out first. Make sure you have your box model kind of down pat. Otherwise you're going to run into these weird issues that are a result of Chrome expecting you to create things with a particular set of rules and a particular set of like the overflow properties set properly and that kind of stuff. So make sure you have it kind of built properly first and that you understand the box model and then go back and reintegrate the knowledge of CSS animations. That's a pretty good advice. I definitely recommend people and I get a lot of young people who look at my work, especially the more creative stuff. And they say, I want to do what you do. Where do I get started? And I hate to tell them it's like you need to start with positioning and the box model and the dumb and JavaScript and all those good things. But you have to learn those things before you can do the cool stuff. And I know that's disheartening to a lot of folks. But I like to put it this way. You're probably going to get a really cool job to tie you over until you learn the fun stuff. So at least you can buy really fancy pizza with that money or pay off student loans. That's very true. And this is stuff that's going to be fundamental in the long run. It's stuff that you can't fudge. You can't fake it unless you only want to do animation in an illustration program. Like for example, After Effects in some ways and After Effects, what you see is what you get. But really, even After Effects, you're going to benefit from knowing code because After Effects uses a modified version of JavaScript, at least it did when I used it quite a while back. So you're going to benefit from knowing at least a little bit of procedural knowledge. And even more benefit happens when you understand the DOM because now you can do really amazing stuff and then publish it to the web immediately. You can create moving documents. It's incredible. But you're absolutely right. You have to know the basics. There are two kinds of animation. The kinds you sit down and watch and the kinds you interact with. If you want to build something people interact with, you need to know what's under the hood. If Flash was great because it let people build interactive things without really knowing much about what was happening under there. But that might have also led to its downfall. Yeah, that's good. That's a good point. Well, let's take a quick break for today's sponsor, Rachel. And then I'm going to come back and talk to you kind of about your background and where you come from. And we'll get into some of your themes for the year. I'm really excited to talk about this stuff, actually. Awesome, Jonathan. Today's episode is sponsored by hired.com. On hired software engineers and designers can get five or more interview requests in a given week. Now, each of these offers has salary and equity included up front. They have full time and contract opportunities. You can view interview requests before you ever even talk to the company. Speaking of companies, they work with over 3,000 companies ranging in size from startups to large publicly traded companies. And they have companies in 13 major tech hubs in North America and Europe. This is totally free for you. Only hired provides a $1,000 thank you bonus. But if you use a special link in the show notes, you can get a doubled bonus. That's a $2,000 bonus. You can find that link at spec.fm. Thanks so much to hired. So Rachel, we've been talking about animation. We've been talking about opinions. Really, all of that was not even planned. It just was such a good conversation, though. It all happened because you have been kind enough to listen to a few episodes of Developer Tea. I'm glad that those spark conversations, you know, you mentioned something. And I want to make sure that the listeners of this show hear this loud and clear for me. When you hear me say something on this show, I want you to go and investigate it for yourself. I don't want you to just take these tips from me as if they're some kind of hacking, you know, perfect way of getting to the top. Like that's not the point of this show. The point of this show is to start good conversations and to get you thinking about things. I actually said something pretty controversial on a recent episode. I said that one of the things that you don't need right away in a startup is an API. And you can imagine that not everybody is going to agree with this statement, right? I absolutely agree. People should definitely, you know, go out and test and make sure that that follow up on those sources, follow the links at the end of the podcast. Go see for yourself. Okay. Rachel, I would love to hear about where you come from. If you can tell me just kind of your background and how you got into animation, specifically what eventually led you to web animation. So I was raised in relative isolation on a little farm in the mountains of Virginia for most of my youth. And I mostly got the rest of the world through the library and later an internet connection. So I pick and chose where my influences came from and most of them were from the BBC. And I didn't have a whole lot of options. Didn't have enough of my to go to college. Didn't have many friends. But I could draw. I kept drawing. I put in my 10,000 hours on drawing and I started making comics and I was able to share them online with other people who love the same things. I love thanks to the Bill and Melinda Gates Foundation giving grants to the local libraries, which were all like half an hour from me, but I still got to visit them once every other week. And they had computers and internet access and I put up a site on geocities, started sharing my comics. Many years later that turned into a job that let me get out of the middle of nowhere and live in a glorified closet where Pond I realized I could make a whole lot more money. If I took the skills I had used to build the sites to share the comics and just did web development and that would take care of all of my financial problems and I did that. And now I can't really go back to making comics but there was one thing I wanted to do back in those days and I never got around to doing. I had something like 400,000 readers every week come read my weekly comics for teenage girls. And how it's not. And it really was. I was on an iVillage site. It was awesome. I was one of the biggest names and comics he'd never heard of. This one blogger put it. Congratulations. A weight congratulations. That's amazing. You know, it's funny because I left comics back in 2008 and it was like I got my award and I like see you guys and I was so sad. I miss them so much. But I look now and there are so many women and I remember these women. They were my contemporaries. There are so many women who are like they're writing adventure time and they're drawing my little ponies and they are being so successful and women's comics, women in comics has just exploded since 2008. Only seven years ago and I would be alive. I didn't say there's a little part of me that was like, oh, I missed it. But yeah, yeah. But being a cartoonist is really hard. It is a hard life and it wasn't one that I could continue. But I'm just so happy to see how things took off. But the thing I didn't get to do that I always wanted to do is I wanted to have a cartoon, you know, like an animation. And I thought maybe I'd do it in flash. But then flash wasn't cool. So I learned JavaScript and it was like, well, you can't animate stuff with JavaScript. Little did I know what would come. That's what they said. And I fell in love with CSS and that's what I did around the office. I was the CSS gatekeeper. And then I found out you could animate stuff with CSS. And then I started experimenting and I realized I loved doing the interesting things with animation and storytelling. Much more than I enjoyed being a gatekeeper for a CSS library in a house of no. And so I headed off to just travel the world and speak and pursue animation full time. That's an amazing story. That's really interesting. And I would say that maybe you didn't miss the boat as much as you think you did. It's possible that your contribution was one of the most important pieces of that puzzle for women in animation or women in comics, rather. People do often confuse cartooning with cartoons. Cartooning is what a person who makes comics does cartoons or something animators make just a vocabulary lesson for the audience there for me as well. And people always were like, wow, so you're like a Disney animator. And you're doing UI and I have to be like, no, actually, I just drew comics and fell in love with CSS and did exactly what you'd expect a cartoonist to do who falls in love with CSS and learns JavaScript. Most amazing thing I think for me is that I'm getting to a point now where I'm beating people in this industry who used to read my comics. I know a couple of women have been like, hey, I found you on Twitter. I used to read your comics. This is great. You know what? I'm getting into UX. So I'm a lead web developer at this big company and I'm just like, oh my god. What? Fancy beating you here. And I find it so exciting and I do still meet people who were making comics at the same time, read my comics. You know, like they now are going on to have careers in Disney and it's just amazing. I love it. And sometimes I still get the straight email in my inbox saying you really helped me through a hard time in my life and it means a lot to me. That's great. If people want to read them now, how do they do that? Rachel's a great.com. It's the archive. And seriously, I no longer necessarily entirely agree with all the opinions that I stated, but just keep in mind that these were written almost entirely by a teenage girl, which is kind of awesome. Of course that will be in the show notes. So go and check that out if you're interested in seeing Rachel's teenage opinions. I had so many. Don't leave all of them. We're Tina. You know, I don't remember the opinions that I had when I was a teenager, but I'm pretty sure I don't agree with any of them now. Yeah, lucky you mind live on a site where anybody can read them. And many have, right? Probably. You know, it's interesting because I like to say that comics is a terrible skill to wield alone, like you're never going to have a really cool life with comics unless you're one of the blessed few who makes it work and makes it big. For the most people, this is, well, it's an artist's job, you know, Pablo Picasso and Renoir. They weren't necessarily rolling around and filthy artists, I don't know, maybe Picasso did, but very few artisans make it big, but it is a labor of love. It's something people really do just out of love and commitment and it's awesome. But this skill, if you learn it, can be one of the most beneficial skills to have in your career. If I need to give a talk about something, I'm drawing my slides. People see my slides and they visually connect with what I'm saying. If I'm putting bullet points on something, I know I can turn those into images. I need to design my own site. It's going to have all kinds of really cool graphics. I have a great eye for layout because of my background with composition. It's just a really great and silery skill. And what's even better is when I'm trying to teach people things. I can come up with some really, really wonderful interactive projects for them. For instance, I'm working on the web animation API documentation for a Masala developer network right now, which is awesome because it is in sore need of some love. But this means I've been making some really cool demos, which I can't wait to show you all. And I've brought back a character from a demo I did for Adobe Inspire way back. Well, it wasn't just for Adobe Inspire. It went on NetTuts 2 as well. I wrote up two tutorials. It was a project so big it needed to. But it was about responsive images and CSS3 animations. And I'm bringing her back for this web animation API documentation because she's such a lovable character and everybody adores her. And I can't think of any better way to teach people about very dry things like the global clock and timelines than to have them interact with this adorable little girl. And hopefully I will get to use code pen for all these examples so they will be at your you're poking and prodding pleasure. That's really exciting. And it's one of the few times probably that you'll actually have a little character to help you along in a technical document. Yes. And I mean, that's one of those things. If I didn't have this background in cartooning, I'd probably make an article showing you moving a box across the screen. Maybe with some play controls on it. And I just got to tell you that's not very inspiring. It's not. You're totally right about that. I love code pen because it lets people share much more creative work than we've ever been able to share before. I go there all the time to look at people's animations. It's so awesome. Oh yeah. I have recently, if you follow me on Twitter, you know, there are a few demos that I've created that quite literally my battery went down into the drain within just, I don't know, a few minutes because I was animating DIVs all over the screen. I was reflecting things all over the screen. And I mean, just causing chaos on my machine basically, just for fun, you know, it was creating kaleidoscopes basically. But I mean, it was just so much fun. And so I just animate these things all over the screen way too many DIVs, way too many nodes in the DOM. And ultimately, it just totally killed my battery. But. No, that's wonderful. Some battery manufacturers should hire you. But it's interesting you should mention that performance issue. Like, back when I started talking about CSS animations, like back in 2013, I remember hearing a lot of, well, if it's not perfect, if it's not performing perfect, if it doesn't have perfect adoption across all of the browsers of all of the users, then we shouldn't use it. Don't you think? And I always came back with, but if you don't make things that push the browsers to get better, we will all be using IE6. I mean, it really is up to the people who build the web to keep pushing it forward. I'm not saying you should make a kaleidoscopic user interface. Please don't do that. No, don't do that. But I am saying you shouldn't feel gilted into not pushing the boundaries because of what's accepted or, you know, what rule people are polishing today. It's okay to try any things just so long as you're not, you know, killing anybody or making your site impossible to use in the process. It's okay to experiment. It's especially okay to experiment on a place like CodePen. You know, CodePen is made for this reason. And quite honestly, you can do this in environments that aren't going to be, you know, used by a business, by a large group of people. There is something to be said for taking care of people's, their data usage, for example, for taking care of their battery, if you are building something that's going to be consumed by people that are, you know, going towards a particular goal. For example, if you are building a website that takes utilities payments, let's take the most mundane thing I can think of, that takes utilities payments, then you probably shouldn't be doing, you know, massive images and video backgrounds just for the sake of the aesthetic. It's likely that that's not really the best choice, right, because people who have, who have limited data plans, all they're trying to do is pay for their utilities. They don't need all of your expression and all of your emotion. They're probably just trying to pay for their utilities. On the flip side, you should totally have a place to do those things. You should totally have a place to create battery killing, non-performance stuff, because that kind of playground, that kind of environment is where we learn the best, because we have no restrictions. Now, I will say this, it is important for you to also learn with restrictions, right, but having the playground where those restrictions are not placed on you, but you place those restrictions on yourself, that's an essential part of the exploratory learning that we actually kind of abandoned when we're very young, quite honestly. We have exploratory learning as children when we're in the sandbox. That's why we call it a sandbox, right? The sandbox. You can do anything that the sandbox allows. We totally do away with that notion, and instead we turn that into just a cubicle or whatever imagery you want to use for that. Co-pin is fantastic for this. So you mentioned something interesting. I said, feel free to push browsers forward by making impossible things, and you mentioned the batteries, and I just want to point out that there is a battery status API that browsers are dragging their feet to implement right now. Interesting. But wouldn't it be great to take the battery status API and use it to switch off animations if the user's battery is too low? Yeah, that would be great. That would be great. And you can also do things like conditionally load larger images. Of course, all of these things are APIs that are going to be available in about 2030. No, I feel like the browsers have done a very good job in most recent years, the last two to three years. I think that particularly Chrome becoming the most widely used browser has pushed browsers forward far more than the previous two or three years. Now Chrome is, well, it's kind of a beast, it's got all of Google behind it and dumping engineering hours into it with a band. Sometimes I wonder how other browser founders can keep up. Yeah, it's amazing, isn't it? Not that I'm complaining. Well, I think that some of the benefits here are that all of the tool sets, everything around the web, it's built on this fundamental concept of openness, everything may not necessarily be open to everyone to use for free in their projects, right? But the concepts being pushed forward, that benefits everyone, that benefits all of the other browser providers as well. Even though they have to still do the work to implement these things, the adoption on its own creates the demand. It's a symbiotic relationship between the browser vendors and the browser users. As we have the ability to adopt these new features, well, now these browser vendors have the kind of the business case for building those new features and for putting more development effort into those features. It's true, and some browsers like Edge, they have, they actually openly solicit their users and developers like what do you want? The web animation API has been moved into there to do list because of a survey on user voice and enough people saying yes, we want this. Yeah, that's great. I'm really interested in the web animation API, but I'm totally unaware of its features. I'm totally uneducated. So I'm excited to talk to you about that. I'm going to break this episode and go into the next episode and we'll discuss the web animation API in that second episode. Thank you so much for listening to today's episode of Developer Tea. I hope you've enjoyed this first part of the interview with Rachel Nabors. Make sure you subscribe to this show if you don't want to miss out on the second part, which will come out on Wednesday. Thank you again to todaysponsorhired.com. Of course, if you go to spec.fm, you can find the special link in the show notes that will allow you to get a doubled bonus if you end up getting hired through hired.com. Thanks for listening and until next time, enjoy your tea.