 Thank you, everybody. So I want to talk about responsive data visualization. And thank you, Irene and Jory, for putting together this amazing, amazing event. I'm already looking forward to next year's. So as Irene mentioned, my name is Gabriel Florete. And I do data visualization at the Boston Globe. Some of you may know that the Boston Globe, it's one of the two newspapers here. And also well-known for probably most well-known in the tech world for being one of the first ones to create a responsive site. And by responsive, I mean, by the way, I have no idea how much of this topic the audience knows. So I'm going to try to err on the side of caution and explain a bit more. And so by responsive, I mean that the content is reflowed, and if you will. And so that using the same source code, you're able to see the same content fitting on all devices. So this could be, if you had a really small screen, like a phone, you'd be able to still consume the content in an appropriate manner. So the Boston Globe, they made this responsive site a couple years ago. It's still very new. And it means that it is a great platform for, well, it's a great enabler for me to do responsive work, but also means that I have to do everything responsive. And so it's a challenge that I really enjoy. And so I want to talk about some things that I've discovered during my time there. And I want to make sure to let you know that I don't think there is an easy solution to this. And we're not there yet. And hopefully we will get there one day. But I don't think we are anywhere close. But so before I begin, I want to do this. Let's play a game. It's going to be a boring game, but I labeled it a game, so it's going to be a game. When you hear responsive, what is the first thing that comes to mind? And shout out. Bousers board? Mobile. Give you one. Media queries. Yes? Yes, hard to test. Yes, good. OK, OK. Well, lots of scrolling. Great. That's a good one. That's a good one. What's that? 10 times the work. 10 times the work, yeah. For sure, for sure. Yes, preaching the choir. OK, well, thank you for being so brave. I heard some good yells from you. And let's keep that in mind later. This was in case none of you felt like contributing. But you did. So the goal is to create data that works on all devices, of course. And I want to refine that and say that the goal is to create data that is of all devices. And by that, I mean something not only that works on the device on my phone, but feels like it was of the phone. To explain that further, you could say that a PDF lives on the web, but HTML is of the web. And so likewise, the goal is to create something that feels like it was meant to live on your browser, on any device, on the device that you're actually using at the moment. Of course, using the same source code. And I think that's where the complication arises. Because we can make things that work beautifully targeting a specific device. But when you're trying to do everything with the same source code, it's tough. If you have more time to do, to have one developer for a phone, one developer for a tablet, then great. And where I come from journalism, that's just not you can't. Unfortunately, that's not how it works. So before the globe, I was in software dev. So that was my background. And so when I came to this, that was my first question, which is, how hard can this be? Surely we can figure this out. Can I add structure to the process, which is a fancy way of saying, can I write a framework? And so I'm going to walk you through my probably flawed thought process that I took when tackling this. And so I'm going to use, as a starting point, a previous graphic that I made. Yes, I should talk about it first. So this is a graphic that I did some time last year. The Boston Globe reporters investigated 21 grocery stores and seafood markets in Massachusetts and found scallops with water levels far exceeding industry standards, which is code for some of these distributors are pumping your scallop with water, so that you end up paying for water. And so we did this. Let me actually see if I can. We're on a smaller screen, but on a bigger screen, there we go. On a bigger screen, this is what you would see at first. How much water is in your scallop? And then you see a little bit of a game. How much water drag? I think my scallop probably has what? 65%? Wrong. The average water content is 77%. And then there's a scatterplot here, where using a very well-known convention, when you hover over these dots, it gives you the name of the distributor. And then on the right side, we have the locator map with some more information here, et cetera. And then some previous next buttons, which perform the same as this. And then as we get a smaller screen, the little shell, the game disappears. And then once you get to phone, we hide the locator map and then previous next buttons on the scatterplot. So this is what I did last year, sometime last year. And so this is what I'm going to be using, explaining the workflow. So that's how it looks like on the iPhone, right? And that's the data set, just if you're curious. So mobile first. How many of you have heard the term mobile first? Since there's at least one person that didn't, I'm going to explain mobile first very quickly. And that is to say that in the world of responsive, the world of web design these days, especially when designing things for all devices, mobile first is this approach that says that you should think about the smaller screen first, lowest common denominator, and then go from there. So in this case, for many reasons, one of them, which is that it really helps you to focus on what's really essential. When you have a really small screen, you cannot afford any junk links, related links, ads, et cetera. You really can only give the user what is most essential. So mobile first is what I'm going to be using for this. And so what I'm going to do is if we don't have JavaScript on the device, and you'd be surprised by 2% of readers do not have JavaScript enabled, whether it's because their device doesn't support it, or because they turned it off, some of them do. So if you don't have JavaScript, the least you could do is give them the data. So I'm going to start from an HTML table. So I think the starting point could be an HTML table, where at least you're giving them the data. There are many different ways to make tables look pretty. And I'm not going to go into them at all. But there's really different frameworks out there that can help your JavaScript less table look really nice on responsive. And at least if you're going to do the least amount of work, then give them the table and the user can scroll. So now let's say that we have JavaScript on a phone, and we have Canvas. And then I won't mention SVG, because most browsers, most older devices, including mine, my phone does not support SVG. But it does support Canvas. And the majority of it is going to be more often the case that a phone will support Canvas instead of SVG. So we have JavaScript, and we have Canvas. Fine. We can draw a scatterplot. So again, just to make sure that you're following along the idea here is that I'm starting from an HTML table. And then with a little bit of code, the code is going to automatically transform my HTML table to a scatterplot. And so fine. Notice these two circles. Actually, there's three circles. I've blown it up a bit. I'm going to go back. The slide that you showed you is this area right here. There's actually, this is the real data. There are four circles here. And one of them you don't see. You can barely see. And that is because they're basically sitting right on top of each other. And that brings us to a very good point, which is data navigation. On the previous, on a big screen, you can use, if you have a mouse, you can hover over like that. You could see that? I mean, it's almost invisible. But at least I can do it. But when you're on a smaller screen, forget it. So in a sense, in a lot of ways, this graphic is flawed because of that. So data navigation is an issue. Like, if I'm on this graphic and I want to be like, what's this scatterplot? What's that point over here? Which is the distributor that was measured that has the highest price per pound of the scale? Well, I can touch it there because there's nothing else around it. But touching here, touching this is already going to be annoying, because my fingers are not that size. And touching this is just going to be impossible. Actually impossible. There's no way that I can beckon that I can call up that information for that point. Which brings me to data navigation. So how do we deal with that? So then I thought, well, how do we navigate between points? And I mentioned this because it's really important. It's one of those things that you don't think about until you have to. So one way would be to add previous next buttons. Like that. So that's what I did on the graphic. I added previous next buttons above the scatterplot. It's a bad solution because the buttons themselves are small. And it's going to be annoying still to touch them, to tap them. But also, what if you're on this point and you want to navigate to somewhere here? You're going to have to tap 10 times. There's 25 points here. I mean, there's almost no data here, right? 24 points is nothing. Imagine 100, and you're on element number 5 and you want to navigate to the 50th element. Forget it. It's going to be so annoying. So it's a bad idea. Make the entire graph two big previous next buttons. At least it improves on the previous one because now there's more touch area for you to tap. So if you can imagine a curtain dropped on top of the scatterplot and then half of the screen will navigate back, half of the screen will navigate forward, at least you can touch. But you're still going to have to deal with the previous next, with the fact that you're going to have to tap a lot. So a way to improve that is to map the graph to data point index. And this is the simplest way I could come up with this idea, which is this. There are 25 points here. And so the idea is that I've divided this graph. I create a curtain on top of the scatterplot and divide that curtain into equal bars, 25 bars. And so then when you're over any bar, say I'm on the last bar, and this bar wouldn't be here in the actual end product. And just putting it there so that you can see what the bars are doing related to the points that are being selected. So in this case, if I were to be touching the screen right next to the end, then that means that I'm on the 25th bar. And so then the 25th element would be selected. If I then go to the 24th area, then the 24th element would be selected, and so forth. And then you can see that as I do that, I'm able to there. So it's just as hard to go from this point to this point as it is to go from this one to this one. So this is a much better solution. This means that I can now at least navigate between data points, which is important. But there's a disconnect between finger travel and selected point. This looks weird, right? I know about you guys, but I wrote this, and it still looks weird to me, that I can go like this. Right here, it sort of feels right. This totally does not. Because my finger is right here, and now it's a little bit further to the right. And whoa, I just went to the next point. So that just doesn't feel right. It is helpful to add a guideline. And so we could do that, one that tracks touch. So in this case, do you guys see that little faint line? Right here, good. So in this case, that guy, I've added a guideline that is tracking selection. So it's simply telling me another confirmation on the element selected. I could also try to create one that tracks touch. And so now, that is nice because, and I've tested this on my phone. I purposefully do not upgrade my phone because, which sucks, but it means that at least I feel like I'm experiencing the common man of pains. And so it works. I can tell you that it works just as fast on my phone. And so this is nice because it means that at least when I'm dragging my finger over the scatter plot, something instant happens. But still a big disconnect because why is that happening, right, or this? So if I were a reader and had not encountered this navigation style before, I would be confused. So another alternative is to add a Zoom-like control. And that is not a bad idea. If there is one navigation interaction that I would say almost everyone is familiar with, it's the Zoom control, especially on phones. Pinch-zooming, we're familiar with it. Non-tech people know how to do the two-finger pinch. So you could imagine that happens here where now I've added Zoom controls to this. And so if I were to start here and I think, you know what, I really need to know what's those two dots. I want to select that one. So then it's just as simple as zooming in and there I've selected it, right? So you could say, well, I think, Gabriel, you came up with a solution. But to which I would say, no, because now look at this. What is this? That's not a scatter plot anymore. That's three circles and a bit of an arc. And I think that's a subtle point but really important, which is that now I have lost context. Now that is not, it's still data, but it's not what I was before. I think it's important to always remember that data points only have meaning in relation to each other. In this case, this data point is meaningful because it's above this one and under that one and sort of to the left of this one. So when I'm zoomed in like this, I've lost track fully of the greater picture. By the way, I have to show you this that, so all these examples, by the way, are on life coding. And I cheated as creating this because this is just a map. And I just clicked on the map to get the lat lungs to create the scatter plot. But there you go. I mean, that's just a map. That's really a map. And I mentioned that because we are very familiar with that, there you go. Now we have the plus, minus. This is really familiar. This way of navigating plus and minus or pinch zooming. So context loss. So data navigation is hard. So why did I mention all of this? Because so that was my actual thought process. I thought, great, I'm going to figure it out. And then I sat down and I had this idea that if you think about, if you look at this, this guy, if you look at this, I thought I could call this a primitive. A scatter plot is a primitive. If you will, a bar chart is a primitive. A line chart is a primitive. A pie chart is a primitive. Primitive in our data of this world, in the sense that it is like a building block. So I thought, well, what I'll do is I'll have this primitive. And then I'll create framework that, depending on the primitive, will add your proper interaction data navigation for your device. So if you're on a small screen and you don't have a JavaScript, then the JavaScript won't do anything. But if you have Canvas, then it'll automatically create a scatter plot. If you're on a small device, it'll use that thing I just showed you, the map width to selection. If you're on a bigger device, it will let you touch. And if you have mouse, then it'll let you mouse. But even on a really small basic primitive, like a scatter plot, I was already running into trouble. There are complexities to navigating between data. And I imagine if I had something like a graph, like some of the coolest stuff that Santiago is going to be showing off. I have no idea how to navigate between data points on something that complex. So it's something that we should not underestimate. And fortunately, I can simply say that since I'm not an expert, someone else is going to figure out. And it's true. Like in data vision and journalism, we're not the ones to be. I don't have any expertise in human computer interaction. But it's definitely something that we need to be thinking about. So something I'd like to discuss that helped me in this thought process, somewhat unrelated to what I just discussed, is a paper written by Segland here, Narrative Visualization, Telling Stories with Data. And in the paper, they discussed the concept of genres of narrative visualization. And then they talk about how they make this effort to categorize narrative visualization into different genres. And here you go, the magazine style, annotated chart, partitioned poster, flow chart, comic strips, slideshow, and film video animation. And I think this is for most part true. This is a good exercise. And I'm not going to talk about all of them. I'm just going to mention I'm going to talk about some of them, the slideshow being one of them. This is a graphic that I did earlier this year. The data here tells a story of a, if you drive a cab in Boston, you need to own a medallion. And there's 1,825 medallions. And this guy owns 372 or 1 in 5. In the 70s, he bought his first medallion. And so he's slowly been acquiring more and more until now, where he owns just about a fifth. And so this originally, I made this as a stepper, or a slideshow, where you have previous necks in each of these slides where there was a next button here and a previous button here. Until I realized that a slideshow can also be brought down. So instead of just going previous next and seeing the next slide, you can simply expand that horizontally and then have the navigation control is going to be scroll bars. And the benefit of that is that it works really nicely on phone. Anytime that you can use something native, and by that I mean something that you're not creating yourself, an interaction control that you're not creating yourself. Like that map graph with to data, and there's blah, blah, I created that with JavaScript. That does not come out of the box with phones. This scrolling, it does. And so it's so nice. And already built into it, it's going to behave better. So anytime that you can, do that. And so that's what I'm doing here. And it just works nicely. The other thing that I want to mention is that small multiples and the combination of small multiples and slideshows or steppers is perhaps the one genre that works best on phones. Because anytime that you show and change over time, or change over anything, change over place, change over x, where you're holding something fixed and then changing something else, that probably means that you have something that itself can have meaning. Like this slide has meaning by itself. It doesn't need this slide to have meaning. And this slide has meaning by itself. And this slide has meaning by itself. And so anytime that you can do that, using small multiples, using a slideshow format, that just works nicely. It's probably the one that works the nicest when it comes to making things just one source code. Annotated chart. So I did this graphic earlier this year, inaugural language, showing the inaugural addresses that have been given by presidents. Going back is the first recorded one that we have, which is Roosevelt's 33. And so each of these dots corresponds to a word that was spoken, the darker the word, the more frequent it was said. And then its placement depends on the first letter of the word, in this case C. And then when it was said, these ring concentric rings denote when it was spoken. So you can see that Obama in 2013 said country several times. And he said equal near the end. If we look at Nixon, he said in 1973 he said responsibility a lot. And peace. Roosevelt was fairly ill in 45, so his speech was the shortest of them all. And then there's another way to navigate here. You can enter any of the words engineer. And surprisingly engineers, only Obama said engineer. You'd think that someone from the New Deal would have said engineer, but it was curious that only Obama said that. So this works well on big screens. We have reports from readers that they spent an hour on this. I mean, an hour is unheard of. When I heard that, I thought I've made, you know, like I won, right? I mean, not even I, the creator, spent an hour playing around with this. And it works really nicely. There's a really nice, this is almost like a, this is so instant, and it works beautifully on an iPad too. Just dragging your finger around. And it cheats you into thinking that this is more important, that this data is more important than it really is. I don't know how important this is actually is. I don't know if I would do it again. Probably not. But it is a failure on the phone. Just to begin with, it's written with mostly canvas, but some SVG. And so SVG, my phone won't display it. And so on bigger devices, I mean on bigger devices, on small devices that support SVG, this is what happens. And that is a failure. The point, all the data is still there. I just shrunk it down, right? I just shrunk down what I did on the big screen like this, and you can still see all the data. But everything is taking such a small space that there's no way for me to navigate between data points, which is what I discussed earlier. And so data navigation, I think, is becoming one of the biggest pains in all of this. But it works really well on big screens. And finally, comic strip. NPR did this thing earlier this year where they worked with an illustrator, Jen Sorensen, to do an illustrator version of Pride and Prejudice. And let's see if I can, there we go. So she made all the panels the same dimension, which means that it works really nice on any screen. And you might think, well, this is great. I mentioned in comics because it has a very applicable to data this, I think. And I want to mention something here, which is, you bear with me for a moment, when I first encountered this, I started reading, and this is what happened. The money Mr. Bingley and his friend Mr. Darcy have come to stay in town soon at a ball, Mr. Bingley and Jane had it off. While Mr. Darcy says of Elizabeth, I made a connection. My eye made a strong, almost causal relationship between this and this. I don't know if it was intended that way, but my eye thought this is very strong related to this. And look what happens when I do this. The money Mr. Bingley and Jane had it off. Scroll. While Mr. Darcy, that is now happening, there's been a beat here. And I think you might say, well, it's really subtle. But I think something has changed. The content of this comic, something here, has been altered by changing the format of the comic. And one more, I want to talk about another comic, Remind. So I got into comics late last year. And so I had been reading about a comic, Remind, and also because the first volume was free. So I just put my daughter to bed. It's late. I'm in my bed. I only have a phone. The light is off. So I had downloaded a comic app reader. And I'm like, great. I'm going to read this. And so this is what happened. And just to make sure you catch up, the comic's about Sonia, the lighthouse keeper at a seaside oil drilling town in Victuals, Hercat. And so this is what I did. This is what I saw. I'm going to stop it right there because there's only 10 minutes left. But you get the point. I actually put it down. I stopped using my phone because I knew that the next day I could go downstairs and use my tablet. And I would be able to consume the content in the way in which it was meant. And yes, you can communicate the same amount of information when you slice things up. But no, it will not be the same. And it just doesn't work as well. And I think it's called data visualization for a reason. My coworker, Alvin Chang, makes a great point, which is it's not data representation. When you visualize something, dimensions matter. We choose to put things the way in specific places for a reason. And so just to have this thought that we're going to adopt the idea that Responsive is going to be able to forget about dimensions and just keep the same communication across all devices. I think that's a mistaken thought. So I think at this point, either you cheat everybody out of something or you cheat some people out of everything. When I did the inaugural address one for that reader that, pleasure or heart, she spent an hour working at it. I don't know you, but I'm so glad you did. Well, that was great. But for people that were looking at it on their phone, I cheated you out of everything. But for that one use case, it worked really well. Back to the word association. Someone said media queries. And I'm so glad you did, because then I didn't have to say it myself. I think that so media queries in this world is something that we use. Media queries, fluid grids, and responsive images are the three things that enable the Boston Globe to be so beautifully responsive. And media queries is something that we use all the time. We are intimately familiar with media queries. Media queries is a way to tell the browser what layout to use with what screen size. And I think that the prevalence of media queries in our world means that more often than not, when we start doing things on mobile, media queries is so big in our heads and our thoughts that we started making responsive design equal to designing for size. I got the phone version done. What's the next break point? I got the tablet break point done. What's the next break point? James Pierce has a great code about this. In 2010, he said, we won't have a mobile web, but merely a 320 pixel wide one, a web for which the humans using it matter less than the width of the glass it is displayed on. And I think he's spot on. Do this, if you can, describe your smartphone. Have you ever done this, actually? I did this two nights ago, sat down and made a list of the things that I think my smartphone does. It is small. It is portable. It can be with you at all times. It has a touch screen. It has sound output. It has a microphone, so it has sound input. It has a gyroscope. It has an accelerometer together. It means that my phone knows if I'm doing this, if I'm doing this. It has a GPS, which means that it knows where I am. It knows where others in my network are. So if I set up the app properly, it knows where my wife is. It knows where my two-year-old, probably not. It knows where my friends are. It has light sensors. It knows how bright this room is, if it's dark, if it's bright. And surely there's more. And as we move on to more interesting devices like Google Glass, there's going to be more capabilities. But we still think about responsive as the screen size. Like 320 pixel, if I designed for 320 pixel, I did it. If I designed for 640 pixels, I did it. And that's totally missing the point. I think that if we equate responsive design with just screen size instead of use case, we're missing the point. I think use case is critical. The use case for someone on a phone is probably much different than tablet or desktop. If you're on a phone, it is more likely than not to get your Starbucks, your Dunkin Donuts, because we're Massachusetts, Dunkin Donuts waiting for your coffee. You have two minutes. So I have two minutes to get your attention, two minutes. And that's a lot. If you have tablet, you're probably somewhere else, maybe like on the T. If you're at desktop, then I have more of your attention, perhaps. But I think to ignore all of those factors is a mistake. And then to ignore the fact that a phone has GPS and users are now expecting GPS to be an integral part of a phone. And so we're so sure-tided to just think of what we do and just think about screen size. I want to mention one more thing. So most of you might know this, but Boston Marathon happens every year. There were two bombs that were detonated 31 days ago, April 15th. And so on that Wednesday, I put together this interactive that for Boston.com. Boston.com is the free version of BostonGlobal.com. And so this interactive allows readers to tell us where they were. Were you there? Share your story. Click your location on the map and tell us what you witnessed. Red dots on the map indicate location of explosions. So you can click anywhere. Look, I was here. You can add your story, et cetera. And then, or you can explore the stories. And so I can zoom in and out. And each of these dots corresponds, I've read them all, each of these dots corresponds to someone that was there, someone that witnessed something. And then you can click, and you see what they wrote. And the initial version of this that we launched Wednesday at 5.30 PM, I had not made, I didn't think. So the initial version, the map occupied the entire width. And so when you hovered over the circle, the box that you see here, I was walking down, hunting to nav. That pop-up box contained all the text. And so I just had no clue that people were going to write so much. The longest entry is 757 words, which when you put it in Word, it is several pages. And so we had people that sat down to write for several pages. And I had to rewrite it. I had to stay up all night and rewrite it because I made a stupid mistake to think that people wouldn't write enough. Because it got to a point where when you hovered over some of these, the entire map would be full with text. And there was no way for you to navigate. And so I had to rewrite it. And it works really well for this use case, which is someone that had a desktop and had to write a lot of stuff. A lot of people had to write about what they saw. And I'm glad they did. And so I think the mistake would be now if I were to then think, great, let's make it work on the phone. And so now how do I make this work on the phone? I'm going to, well, surely if you're on the phone, you're not going to want to write 757 words. But not even on an iPad, right? You're not going to want to do that, 757 words on an iPad. So for this use case, it works really well. What I should have done on the phone is take advantage of the GPS so that this would not be very hard to do. I just didn't think of it. So that when you are, as you're walking down Boylston Street and you bring up your app, you can then see only one dot, the one that is closest to you. And then the screen would then show the text of that person that was right there and what that person wrote. So then as you're walking along Boylston Street, you'd be able to see, oh, this person here wrote, this is what she saw here, walk a couple of steps. So this is what she saw here. That would have been a great use of GPS in a phone. What then should you then say, well, that worked really well, make it work like that but on a bigger format on the desktop? No, that would also be missing the point. So I think it's critical to always keep in mind that people are consuming your information in different ways. And that is very, very important. Thank you.