Transcription
Sarah Drasner: All right. You guys came back after lunch. That was a bad move.
[Laughter]
Sarah Drasner: My name is Sarah Drasner, and I’m here today to talk to you about storytelling in the age of JavaScript. I am a storyteller on the Web because I’m a designer and a developer. If you’re a designer and developer too, you’re also telling stories on the Web, so without further ado.
Oh, I will tweet these slides out to the btconf after, so you don’t have to take notes or anything.
Without further ado, we’re going to kind of talk today about why storytelling is important and why we’re even discussing it at all. We’ll go over some concrete examples to get you going. And we’ll talk about some general options for tooling on the Web.
Why is storytelling important? Storytelling is a fundamental piece of humanity. Our earliest records of humans all revolve around telling stories, and part of the reason for this is our biology rewards us for this experience.
We get a dopamine rush when we’re curious about something because we want to know what’s in that bush so that we can eat the thing or run away from the thing, as it may be. Story allows us to plan for the future. We can safely think about possible outcomes that are dangerous for us and plan ahead.
For these reasons, we crave story. That’s why, after a really hard day of work, you turn on Netflix or you go to a bar and tell stories with your friends. That’s actually relaxing for you to hear stories.
Some of you might be familiar with this, but in case you aren’t, this is called a journey map of a story on a site. It’s an example of what people are imaging the user is going through as they’re visiting each piece of that site. It’s what it looks like from the point of view of that user. A lot of what we’re going to talk about today is going to be framed within that type of journey as our story.
Now that seems simple enough, so what are the things that are getting in our way of telling a good story on the Web? Well, we each have these teams, and sometimes at big companies they’re siloed, like maybe you have a product page and a search page, and there are two teams that maybe don’t even talk to each other, so they’re not talking about how that experience feels when a user goes from being on the product to, like, conducting a search. That’s one way.
But even within these teams, we get split apart, right? The PM maybe wants you to get somebody to click on a button or, like, they really need to drive conversions in an area. Then design wants to make things look cohesive and branded. Then in engineering we want to take out legacy code or maybe try a new framework. Even on that one page or that one experience, sometimes we’re not really that aligned.
In storytelling and in building websites, we have something called the “so what” factor. People start off intrigued, but that curiosity is really finite. We talked a bit about that during Patty’s speech too, so we know that user attention span is short. We have around two seconds before it completely drops off. Amazon has discovered that for every one second delay, conversions drop by 7%. Walmart has found that it gains one percent revenue increase for every 100 milliseconds of improvement.
Usually we talk about this drop off in terms of performance, like how fast our sites load and keep their interest. This is very, very important, but I would argue it’s equally important to talk about this window in time in terms of sustained curiosity. Your site can be the fastest loading site on the Internet, but if it doesn’t ultimately compel people, they’ll go. But it works together with performance because your site could also tell the most beautiful story on the Web, but if it never ever loads before the user sees it, then the users drop off. These two things work in tandem.
When a user visits our site they’re not worried about the button or whether it looks like a Dribbble shot or whether it’s using a framework. They’re wondering, “Is this useful? Is it captivating? Is it easy enough to use?”
That’s the issue you might run into even with journey maps is that a user in that scenario is going from point A to point B. But I don’t know about you. That’s my best case scenario. As a user, I don’t even know where I’m going when I’m the Internet. Most times I’m blurry eyed in the morning looking at my phone. Maybe I clicked on something because I was curious. So point A to point B is actually your best case scenario.
Okay, now that we’ve made this sound sufficiently difficult, let’s talk about how we can solve for it with tools and planning. It’s easier for us to plan for our user’s journey if everyone agrees on the end. Now you might think that everyone actually is in agreement for the end, but a lot of times when I work with companies people aren’t aligned on the end. Product thinks the end of the user’s experience is the contact form. The engineer thought it was that they’re searching on the page for longer. Sometimes getting aligned on those things is really helpful because then you have a single point of validation. Google PMs are encouraged to find one goal on a page, not to do a million different things. That’s a really, really good starting point.
Once we have that starting point, it’s easier to fill in the spaces in between. I talk about spacial maps a lot. This is kind of like a heat map of your eye exploring a page. What ends up happening is there’s an event called saccade when you’re looking at something and your eye is always moving around. It’s never just staying in one place. As you’re looking at a site, you’re trying to create a spacial map of what’s going on in that site.
Now if anything changes, you have to remap all of those details. That can cause cognitive leaks. That is also how we, like, build up an association. Again, this is tied to our biology. If the entire team is aligned on the beginning and the end, you can start to connect those states in a way that reduces friction for the user.
The other thing to keep in mind is that your user doesn’t look like this. No one is sitting there in a bright white room, like, super happy to be using your website, just super happy to be there. Your user looks like this. They’re holding an infant. Their boss just yelled at them. They’re on the phone with their insurance company. They have to go to Walmart later. Again, think about the fact that your user’s attention span might be more short than you actually think that it is.
It’s our job to not expect that everything we know is immediately clear to them. It’s our job to shine a light in a sea of features on the one thing that they should really be paying attention to.
I particularly like this user accessibility study from Microsoft. If you’re working at a company, you might make the excuse like, oh, okay, there’s not that many one armed people, so we don’t really have to account for them. But if you kind of expand that to situations and situational injuries like you went skiing and you hurt yourself, or you’re holding an infant or something like that, all of a sudden your user base expands, and this is true for eyesight and all sorts of things that kind of limit us from doing a lot of things on the Web.
We need to think about how to offer clarity. We can have them click on that button, or we can have the site look beautiful, or we can use the new framework is everyone is aligned and we’re all working towards that one goal together.
This doesn’t begin and end with the user’s experience either. When Addy Osmani asked what developers needed to make PWAs, the answer was better docs and guides because developers and designers, they need clarity too. One thing I do, I’m a consultant. I work with a lot of different companies. One thing that I often have companies do because nobody is making a site from scratch, right? That just often doesn’t happen. You’re taking an existing site with a ton of features and trying to figure out what to keep and what to throw away and what’s best to focus on.
What I have them do is I have them write down every single feature on the site on a post-it note. Then I draw this on the board: things customers love, stuff that makes us funny, stuff that makes us stand out, and not applicable. Now the real point of this exercise is to find this. All of the things that go into this category can completely be eliminated from your site. You might really be attached to some things on your site because you made it two years ago and the team was really great then, and that project was kind of successful for the KPIs we had then, which aren’t really the same that you have now. It kind of helps you divorce that emotion from what’s actually being used on your site and what users are actually interested in.
If we’re considering how a user feels on our site, we have to consider our site’s personality. Let’s look at the good, the bad, and the ugly of this. Of course for the bad we’re going to talk about Clippy. That’s kind of the end all, be all of annoying UX examples. It’s usually because people say that it popped up, like something popped up and we didn’t like it.
But it’s a little bit -- the story here is a little bit more nuanced. Imagine Clippy, for a second, was a person. If the first time you sat down to write something like a letter or something and somebody came along and said, “Oh, do you want my help with that letter?” it would be a little annoying, but it wouldn’t be, like, that annoying. But if every time you sat down to write a letter somebody came by and, like, “Hey, do you want help with that letter?” and they never learned and they never really went away very easily, that would be a really annoying person.
Again, you might be thinking, “But a computer site is not a person.” Research shows that this might, we might actually be thinking of them subconsciously as one. One company used to do a yearly survey of all of the software people used, and at first they had a separate computer where people would take that survey. You know consistently they got the same results.
Now they didn’t change the software at all, but one year they figured out how to send it so that people were taking that software study and, like, reporting the software that they were using on their own computer. All of a sudden the reports were showing that people were really happy with the software, and it was okay, and none of the software changed. They went into examining it further, and it turns out that even though if you ask these people, “Are you worried about your computer’s feelings?” they would of course say, “No. I know my computer is a computer,” but subconsciously they were all rating their software higher because they didn’t want to be rude.
If we go back to the Clippy model, we can understand that Clippy was annoying because his personality was annoying. They ran these tests where they didn’t change the functionality of Clippy, but they had him make fun of himself, so he came out and he would say, like, “God, I’m back. Why am I here? Ah, this is so annoying. Why don’t you just, like, write a letter to Microsoft and really let them have it? No, no, that’s not rude enough. Really let them have it,” and people started rating that they loved Clippy because Clippy became a likeable person.
Here’s one example of a site that I think has a great welcome journey. When you sign up for CodePen, they take you through all the functionality, so you learn how to use it. You set the pace, so you can kind of decide when you’re going to the next step or not. You can see from the progress bar where you are in that tour, and you can kind of get used to that interface. But I think actually the most important feature that’s in this entire thing is that “Leave Tour” button. It means that you can exit that conversation whenever you feel like, and that’s a little bit more close to a real human conversation. I can say, “Oh, I need to go to the bathroom,” or, like, “Oh, I’ve got to go,” or something like that. That’s actually a better human personality.
I think Smashing’s new footer redesign is a perfect example of good personality. The cat is the mascot for Smashing. You can see him here on the desktop view. He’s pouncing towards the bird. Then when you scroll the window down on responsive, you get this funny story about what might have happened to the bird. There’s actually another view here that I haven’t seen yet. There’s like an Easter egg where if you get at just the right dimensions, you see that the bird escaped, so it’s actually like a little more optimistic than that.
Audience: [Laughter]
Sarah Drasner: But this is actually really smart because every time we feel an emotion, emotions are attached to our limbic system and allow us to remember better. So if you’re trying to be memorable on your site or have users associate you with a good feeling, one way to do so is to add some personality.
I think Netflix is a good example of good and bad personality. Netflix tries to learn your interests through machine learning, and sometimes it does a really good job. But if you’re like me and you love horror films, and you watch a whole bunch of those in a row and then you watch a comedy, and then forevermore you’re only shown Shaun of the Dead, you could see that this algorithm sometimes gets a little confused. So some users do hacks like this person made a Hattie and a Drunk Hattie account. I think that’s ingenious.
Audience: [Laughter]
Sarah Drasner: But, like, ideally your users shouldn’t have to make alternate drunk accounts to use your site. In case you’re curious how these kind of machine learning algorithms work, there’s a great playground for it called TensorFlow For Poets. I highly suggest playing around with it, even before you get into, like, the nitty-gritty details of some of the computer science.
Personality is also important in telling a story on your site because relatable stories create empathy. I really love WALL-E. I think it’s like a really, really beautiful story, so I made this pin to kind of like control WALL-E, to try to get his little cockroach friend and stuff. But it’s really, really interesting to have the user navigate that story. Instead of me just showing you an SVG animation where you’re watching it, you actually get to control the cockroach and make him move around.
Personality is not the only way to make your site more memorable or make it appear better. I think we talked a little bit about perceived performance before. Loaders are really, really important for perceived performance. We’re reducing the impact of perceived wait times through curiosity.
One thing about this is a lot of times we look at these benchmarks, and we look at the data behind how long things take, how many seconds things take, but humans will actually overestimate passive wait times by 36%. What that means for you is that your timeline benchmarks are not telling the full story. People can actually feel like something isn’t as long than something that, you know, has a similar experience by the way that you design it and by the way that you build it.
Viget did a great experiment where they used the kind of normal spiny loader and then they made a custom loader that was just their logo with some dots. People were willing to wait twice as long between 14 seconds and 22 seconds for the custom loading experience. Your users actually just want to know that you care about them a little bit. It’s kind of interesting.
I actually started putting this slide together and had this on the page. I immediately took it out, but I think I left it because it was so entrancing that I often lose my train of thought while I’m trying to give this part of the speech. That’s a really good loader if you’re like, whoa.
Some things that we know about loaders are that uncertain wait times are longer than known or finite waits. Disney World and airports know this, so Disney World will give animatronic animals and stuff while you’re waiting in line so the kids don’t feel like the wait is quite as long. Airports will make you walk all the way around to get to baggage claim so that you feel like you just got to baggage claim and your bag was there. You can actually check it out the next time you’re at an airport. If you look at a map, you’re actually walking a really long way to get your bags.
Anxiety makes wait seem longer, so any time you can let people know, yes, we got your credit card information. We’re processing it. Please wait. That kind of stuff is really helpful for your user because it reduces stress. Putting your credit card info on a website is always a little bit stressful for your user.
People want to get started. That’s why doctors bring you into an exam room before they’re ready to see you because people feel like they’re already on the journey of seeing the doctor even though they’re waiting for another half an hour in that room or something.
I think loaders are a really great case for SVG. SVG can be super small if you design for performance. It offers a navigatable DOM, which means you can reach right inside of it and add classes or IDs to things and move them right around just the way that you would with an HTML element.
It’s also scaleable. We talked about scaleable vector graphics. What does that mean? It’s built with math, so any time you’re using it on different devices and it displays retina, what have you, it’s always going to stay crisp, which is really nice because you don’t have to worry about image replacement. You actually don’t even have to worry about HTTP requests at all because you can put them directly in line in the HTML and save yourself that time.
This is an example from an extension I use called Honey. What Honey does is every time you go through a checkout, it searches the Web for coupons that might apply to your checkout. I actually save a ton of money on travel. I don’t work for them. I just think it’s cool.
They’re testing these codes the whole time you have this cute, little SVG animation that keeps you busy. You also have a progress bar, and it tells you what code they’re testing. So you feel a little bit like you’re more part of the experience. It’s good that they do this because it takes -- that whole process takes up to a minute. I’m actually willing to wait a whole minute if I have something like that to look at. If it was just a spinning loader, I probably would have deleted that extension by now.
I made this loader for Smashing Magazine for their checkout experience. It’s kind of funny and cute, but the real big deal here is that the entire file size is six kilobytes. That’s graphic. That’s the animation. That’s everything. When they first gave me that file, it was much bigger, but I optimized my code, and I make sure that it’s g-zipped and all sorts of stuff. Ultimately, I’m delivering a really, really small file size.
Compare that to a GIF. GIFs are actually really huge. If you think you’re saving yourself time and money by using GIFs, you’re not. You’re doing yourself a disservice. Plus it’s kind of fun.
Chris Gannon does a lot of really amazing SVG work. Actually, some other designer made this kind of loading experience on Dribbble, and he copied it and made it into a real SVG. It’s kind of neat to see those cross-collaborations between designers and developers.
This was in Smashing Magazine from functional UX design animations. One thing it illuminates is foreshadowing or hints. If you just saw that initial screen, you wouldn’t necessarily know that you can toggle it back and forth. But if you show a little animation at the front just to say, like, oh, you can knock it this way or you can knock it that way, then the user kind of gets an idea of what they can be doing.
I also have an article about animating the view box, so this is an SVG. It’s just one SVG that’s a map. What we do is actually just, like, move this view box around so we’re expanding and contracting that view of it. What those bloops do is allow us to hint to the user what’s actually clickable. Not all of this map has information. Only four spots do. Those little pieces guide the user to what the next interaction is. This is also showing that it’s completely responsive too.
We can do more innovative things. This is a really kind of not usual interaction on a site, and there is room for innovation. I think a lot of times we shy away from innovation because we’re like, oh, well, the user won’t discover it. But if we show them the way just a little bit, this whole thing is like maybe 30 seconds long. It actually gives them a hint for what’s coming next and how to work with it.
Another really important thing is the element of surprise.
Audience: [Laughter]
Sarah Drasner: I don’t know if you guys saw that BBC interview where the kids interrupted his dad.
Timing is intrinsically connected to surprise. In order to time things appropriately to be useful, you can see an example of this as we update these baby’s legs. When he’s slower, it’s even like 300 milliseconds slower and it’s not funny any more. The baby completely loses all humor, so timing and paying attention to that timing is incredibly important.
This is kind of a side note, but I had the funniest JavaScript error when I was working on this. The baby just kept coming out right away. I was like, baby, no.
Audience: [Laughter]
Sarah Drasner: By the time I was done debugging it, which took 45 minutes of just the baby appearing out of nowhere, I was cracking up the whole time.
When we’re working with timing, we have to consider the way that things look to our users. I’m sure you’ve all had this experience where you visit a site, you’ve never even looked around yet, and it all of a sudden asks you for your information. You’re like, whoa. Buy me a drink first.
Audience: [Laughter]
Sarah Drasner: That’s very fast to be asking me for my information. That’s not a good experience. That timing is too quick. If you think that I’m being picky here, Google will actually now decrease your SEO if you have a timed interstitial on mobile because it’s such a bad, dark UX pattern. That link will show you that article and all of the information about it.
There’s also a post recently about Shame the Confirmshamers, which shows all the way that people that insult people who won’t convert. This one is hilarious to me. It’s like, “Here’s 80 books.” Not like I don’t want books. I don’t read. You have to put in here, “I don’t read,” in order to get away from this. I just think that’s a really bad, dark UX pattern as well.
This one is particularly bad because of that spacial awareness gathering I mentioned before. When I got to the site, I have to continually readjust where I am in this page because the layout is constantly shifting around while these ads are loading. It’s really hard to read.
This is documentary footage of me trying to read that site, or any site on my phone in the morning.
Audience: [Laughter]
Sarah Drasner: Don’t do that.
Okay. We talked about some good examples, some bad examples, so now let’s talk about storytelling with code and some of the options that are available with you. We talked about surprise. One thing to know about surprise is that nothing is surprising unless you set up a world beforehand. The whole thing about surprise is that it’s different from the thing that came before it.
Here’s a heat map of Google. Again, consider what people are seeing when they’re looking around your site before you do something really interesting.
[Bombing sounds]
Sarah Drasner: So this is an SVG animation, and the whole point of the surprise here is we set up this polygon world just for a second. People can kind of see that that’s the pattern that we’re using. But then we break it apart with that filter. That SVG filter is very different from the way that the polygons were kind of working, so it gets that kind of pleasant surprise.
But if you’re going to be working with SVG filters or manipulating them, one thing to call out is that they can be performance insensitive. What I usually end up doing is setting the base frequency to zero first, and I make these helper functions that allow me to set it to zero and then immediately remove it when I’m done using it. You can actually make sure that you’re only using it for the time that you’re using it and the rest of the time the page is kind of like SVG filter free.
Another thing we talked about was creating a more seamless transition from the beginning to the end of a user journey, so identifying the end of the story and making sure that transitions from one state to another happen as seamlessly as possible. This example from Leo Leung is awesome, and it shows a really nice, seamless transition between the same elements with different uses and views. It feels really nice.
If our goal is to get the user from point A to point B and make that as seamless as possible in code, one thing that we can do is kind of look at the different views of our site and try to figure out what’s changing. What are the things that can stay the same to keep that spacial awareness or context? And what are the things that we should be adjusting?
Without transitions between those events, we kind of lose an opportunity. The user has to remap each part of that interactive space, and it doesn’t feel as fluid or as responsive. It feels more clunky.
We’re going to talk about the progressive framework view for some of these examples. I really like this framework because they’ve done a really good job of understanding transitions of state in a responsible manner. You’re also actually writing HTML and Semantic Markup, which is really, really nice. Addy Osmani is going to be demoing a Vue Progressive Web App at Google.io in a day. I can’t give you that link yet, but you should go to his speech and he’ll give you the actual link for that, so stay tuned for that.
This is a really nice, declarative way to manage state, but also kind of progressively add JavaScript. Here you see two ways of describing the changes that we can hook into: the enter and leave states. The hook for when the transition is occurring, which is the v-interactive and v-leave-active.
In Vue’s transition component we have these sugary bits like in-out modes. What that allows us to do is say, wait until this one animation is done until you do the next animation. That flipping card is actually two animations. It’s one thing flipping and the other thing flipping in. That’s a kind of common thing to do when you’re transitioning something is to have one thing wait for the other. All you have to do is add just a tiny bit of Markup and it kind of handles those situations for you.
This is an example without that. You might have seen stuff like this where one thing is transitioning in, but they’re happening simultaneously, so it doesn’t look terrible, but it just looks a little bit more jarring.
The Markup is really simple for this. I’ve got a slot that changes out, so slots allow me to replace content, and that mode, that out-in, is all I need to say to kind of specify how I want those transitions to occur.
Our transition plugs into the interactive class hook, and we can state how we want that transition to work. I can use JavaScript. I can use CSS, as I’m doing here. We can kind of just put a cubic-bezier on it and the computer does the heavy lifting for us.
Geoff Graham wrote a really great article on CSS-Tricks about feature requirements. This is exactly what we need in order to build our transitions. As a user, I expect that something happens so that I can get to some goal. That’s a really easy thing to write out before you get started.
We can have these kind of end-to-end user experiences--
[Raining sounds]
[Wind sounds]
[Birds chirping]
[Thunder]
Sarah Drasner: And basically we can reuse the same component and just say that any time you want to enter and any time you want to leave you should have these things occur.
In this, we’re encapsulating state. It’s state driven animation, so I’m using Vuex here. If you’re familiar with React, it’s similar to Redux. I have a centralized store for all of this and, instead of passing the state around from parent to sibling to children, I’m actually managing it all here. I have these ideas of screens where I’m kind of toggling the state of that template. Then I make sure that it loops back to zero. I can have different animations come in as I’m using different components.
If the state is similar enough, you can even use the transition in the state with watchers. Here I’ve built from scratch a chart with Vue. As the data changes, the watchers will update and simply transition between them.
Actually, I think I forget a demo here. No, it’s coming up. Okay.
I’m not the only one who likes working this way. David Khourshid wrote an animated intro to RxJS in which he uses observables to update CSS variables. A totally different technology stack, kind of similar idea where you’re kind of like you hold the state of the thing, and then you’re allowing the user to manipulate it. In this case you’re working between JavaScript and CSS. Now that we have those variables, the CSS variables are well supported in a lot of browsers.
Indeed this kind of thinking was about transitioning state was how we made our little WALL-E from before. We basically have this at mousemove. That’s a way of writing an event in Vue. It’s very simple. You can do all of these kind of directives and, in that coordinates method, I basically am plotting the progress of a timeline along the coordinates that you’re moving your mouse.
Another way we can tell a story on a website is to create a fixed window narrative where the user is not rerouting, but rather exploring some Web GL or 3.js world. Now this is definitely the kind of experience where it’s not for every website. It might be great for a movie or, in this case, it’s for Harry Potter and making yourself a Patronus. But it could be really powerful for storytelling because you’re engaging the user’s emotion system while keeping them from using navigation systems, just like dreams do.
We could also have user driven interaction on sites that still create a world. I particularly like this one because they have a really interesting and innovative user interaction, and they guide you through it with some of those hints that we were talking about earlier that actually really complement the site. You can see that cartoon hand kind of shows you where to go, and so you can click around and be part of, guided through, all of these really, really interesting user experiences.
You guys should definitely check out this site later because it has really good music associated with it too. It’s just a really beautiful, immersive experience.
We kind of talked about gaming, you know, spacial understanding. I think this example from Codrops does an amazing job. If you’re selecting seats at this movie theater, you’re transitioning between these states, and you really actually get a sense of where you would sit in this movie theater. It’s not just like, okay, I’m going to click through the ticketing system.
Now if there were two movie theaters that I had to decide between and one of them had this before checkout, I would definitely use this because I know where I’m sitting. I know how that would feel. I can get the sense if I’m, like, maybe too close up. That maybe is too close. I already have a sense of that experience.
In order to keep these pieces consistent across your site, I think it’s really important to have motion design language. A lot of times people talk about Google Material Design as a motion design language, and I think there’s a distinction to make because sometimes people think Google Material Design is motion design. It’s not.
They did a really, really good job of making a motion design language that was easy to understand, that people could adhere to, that could keep things consistent, but every time you use Google’s Material Design on your site, you are losing a chance to be memorable on your own site. You’re implementing all of the stuff for material design. People go to your site, and they say, “Google. Now that’s good branding.” You are now showing off Google when you’re implementing their motion design on your site.
I made this kind of like motion design docs that you can go to on your own if you would like. It kind of just shows how having an opinion on motion might go. Maybe you have, like, okay, we never flip things. Not that flipping is wrong, but that’s just not a part of our motion design. We always make things glide. Or maybe you have something like, okay, we have to try to make things morph as much as possible, like in this example, instead of pop into the screen. Or maybe we have custom entrances and exits, which I’ll address again in a second, so that people don’t have to keep reinventing the wheel.
I feel like people on sites often think about their typography as a cohesive whole. They talk about the colors as a cohesive whole. Then with animation it’s just like this ad hoc like, “I don’t know, we’ve got to make a modal appear. Whatever.” And so they kind of lose out on the experience to be really cohesive in the same ways that they do all sorts of other kind of cohesion in branding.
If we’re breaking these kind of things into actionable code, what I often do is I’ll make T1, T2, T3 classes for timing. If you think about H1, H2, H3, H5 is the default. That’s the body. That’s what everybody uses. Everybody who uses this animation system can just start with H5. If that doesn’t work for them, they increment to a different T class. It’s all just available for them to plug into.
Another thing to do is to create entrance and exit easings, so everybody plugs into those. Maybe you want an emphasis or a kind of emphasis out in case you need something to look a little bit more fancy. Then you build those in as well.
Now you’ve made a system where nobody needs to know animation in order to plug into this. They just default to T5. They default to entrance. Then they can adjust as they need to.
And so what this looks like is this is just a simple popping animation, but you can see how it kind of changes the characteristics of that pop as we work with different things. That’s kind of nice. We always use the same easing structure, and we kind of have an opinion on how it goes. It actually makes things easier to build from then on. You don’t have to keep reinventing the wheel.
In user interaction-driven stories we spoke a little bit about how relatable experiences create empathy. It’s nice to show a user as the main character in that story. In this, they kind of show your slavery footprint as you go through the site, rather than just telling you, okay, everybody on earth has a slavery footprint of 3.5 people, like you probably are employing three slaves without realizing it. They actually guide you through this with your own information. You’re plugging in your own details and, at the end, you kind of learn about how the things, the products you buy and the things that you’re using, actually impact the rest of the world. It’s much better and it’s much more compelling of an experience than someone just telling you that data.
We have to be careful with data. Using real time data can be really powerful for telling stories. Here’s a great example from FiveThirtyEight where you can actually drag the different handles around and change the subjective reality of real time experience. But be aware that this kind of forecasting, when done wrong, can kind of have the opposite effect.
FiveThirtyEight was really compelling during the American election. I was checking it all the time. But when the projections actually ended up being false, a lot of people were kind of disenchanted. Real time data can be powerful this way, but you have to trust that it’s actually very accurate in order to keep, keeping up the trust of your users.
This awesome piece of storytelling is called Scrollytelling. It’s a device often used by the New York Times.
This example is by Shirley Wu. She’s the other half of Nadieh’s Data Sketches. You saw that great speech about hacking the visual norm, yesterday. This experiment was built with D3 and React, and it’s really, really beautiful. It’s a visualization of every single line in Hamilton, the musical.
Let’s Free Congress is also a great example of Scrollytelling because this storytelling allows the user’s attention to pair with the graphics as they’re being led through all of these things. These concepts are shown to you one piece at a time, and you feel like you’re part of this journey.
What do we learn when we consider our websites to be storytelling? We can think about how to get the user from here to there in an efficient way. But even if we can’t connect those dots so directly, we can make the journey interesting enough along the way to keep them going through our sites.
In this talk we went over the most important means of guiding the user through a site that is just as vital as performance, thinking about the sustained curiosity of users on our site.
I have a book by O’Reilly. This is not that book. This is my friend trolling me. I don’t have the man blob animal. That’s not even my last name. This is my actual book--I think I have a fancy chicken. Actually, this is now in color. They decided to print it in color, so that was really cool--If you want to learn more about the technical details of some of these SVG animations.
The conclusion of this talk is the best way to make your site compelling is by actually making it really compelling. But wait. Is there more?
[Pause]
Sarah Drasner: There’s that damn baby again.
[Laughter]
[Pause]
Audience: [Laughter] [Applause]
Sarah Drasner: Thank you.
