 So did you have to prepare fresh for this particular session that you're doing, or were you able to repurpose things that you have shared before? Some of it are things that I do repeat across presentations, but. Excellent, so I'm told we are live now. So hi, everyone. Whoever is joining us from the YouTube livestream or on Zoom, we'll start in like a couple of minutes. We'll just give three, four minutes for people to join in. And then we'll start our session. So just bear with us for a few minutes. So yeah, Gurman, so you're saying that there are some things that you are able to repurpose. But I presume for this session, when you're talking about responsiveness, that would be something different that you would have had to include or incorporate. Yeah, focusing a lot more on how I treat different screens, but I'm thinking of design concepts for visualizations. I have not focused on that particular thing before for a talk. All right, and do you work as a team or do you work as an individual doing the entire production? It depends on the project. Most of my projects are done in teams, but when the thing is a team, it's not like one person does the development, one person does the design. It's not like that. Most people on the team are people with multiple skills. So the designer is also the journalist. The journalist is also the developer, that kind of a setup. But yes, I might, for example, my expertise is writing data visualizations in JavaScript. Another colleague of mine might be data-making maps. Another colleague of mine might be really good at scraping data, but yeah, it's still. So do you also do journalism as well in any way? So do you write your own stories as well? So so much of what I do requires reporting, requires a lot of research. And I undertake that research. In my current job, I don't talk to as many people, but in my previous jobs, that has been a significant part of my job. I, for example, have degrees in journalism. I don't have a degree in design or computer science. So I'm a journalist by training. And I'm a self-taught designer and developer. That's amazing. That's quite a cool transition. Did I suppose you will be one of the few people in the world whose degree is actually helping you on the job? I don't think the degree is that helpful. In some ways, it is. There are days when it is. But yeah, otherwise, I think, for me also, I've mostly learned on the job. Clearly, our generation is not setting a great example for the next generation when it comes to acquiring degrees. Yeah. OK, it's 11 or 3. I'll start with the session now. Just start with some basic introductions. So hi, everyone. Whoever has joined us on Zoom, on YouTube, or any other livestream platform that we are streaming in. Thanks a lot for giving your time on a Saturday morning. A quick introduction about this space and about me as well. So I'm Sawvik, I run Mirage, which is a strategic web design and development studio in New Delhi. Along with Hasgeek and other volunteers, I've been running a content web series, which is a set of free-wheeling chats for people who create, maintain content-based websites. Content-based websites could be sites which are publishing heavy, typically CMS-driven, marketing sites, media sites, e-commerce sites, et cetera. And in the content web series, we want to cover topics that touch upon the three most important practices that come together to build websites. One is the content side of things, which you could be in any content team or content strategist, copywriter, et cetera. Or you could be a designer, graphic designer, web designer, UI UX designer, and all. Or you could be a developer, either front-end or back-end. So we want to touch upon topics that cover all these three practices. And there's also this fourth pillar, which is website owners or publishers, businesses, who might also want to participate and try to learn about things that are relevant for them, including analytics and other pieces that come in while you're owning a website. So today, in our today's conversation, we have Gurman. Gurman joins us from Singapore. Gurman, would you like to introduce yourself? Hello, everyone. I am Guden Bhachia. I work as a data and graphics journalist at Reuters here in Singapore. Most of my work involves using code to tell stories about Asia. I have previously worked at Hindustan Times and some publications in the US. So yes, I make charts and maps and tell stories with them. OK. What would you be speaking about today, Gurman? So one of the worst things about my job is to make beautiful visualizations and then kill them because they don't work on the phone. So today, I'm going to talk about how do I design visualizations for multiple screen sizes. I am going to do that by giving you 10 tips that you can use to kind of think of responsibility with respect to data visualizations. 10 tips. That's really click-baity. Yes. Perfect. 10 tips to make cool charts on the phone. Yeah. Clearly, Gurman knows all the journalistic tricks to get people hooked on towards a story. OK. Who do you think is likely to benefit most from this conversation that we are going to have today? People who tell stories. You could be telling stories when it comes through words. You could be telling stories through design. I think this will extremely benefit storytellers. A lot of it is focused on design though. So design thinking within storytelling. OK, I'm really excited about this. I've heard really good things about Gurman, her previous talks, and all have been also super interesting and have come highly recommended. So really looking forward to this conversation. A few quick instructions for people who are joining in. For the first 25 minutes or so, Gurman will be giving a presentation. During that time, we will try to not interrupt her or ask her questions. Let her go through a flow of the presentation. Post that. We'll have the Q&A session where we can ask any questions that we have for Gurman. If you are joining in from YouTube, you can post your questions in the comments of the live chat stream. And someone from the Haskeek team is going to forward those questions to me here on Zoom. Or, alternately, you can directly join us on the Zoom call itself wherein you can put in your questions using the chat tool. And in case, when I'm taking up your questions, you could then directly also ask any counterpoints that you have or any other follow-ups you have to Gurman directly. So that's the advantage of you joining Zoom. Also, in case you want to ask any specific questions during the Q&A and have a follow-up, you should use the raise hand features in Zoom so that I know that you want to come in and have a follow-up to ask Gurman. So that's also one thing I have to tell you. That's all I have from the instructions point of view. So over to you, Gurman, for the presentation. Looking forward to this. Let me share my screen. One second. Can everybody see me? Thumbs up if you can see the presentation. I can see the presentation. It's good. Cool. OK. So hi, everyone. As I mentioned, I'm going to focus on responsive data with today. How do we design data which will tell stories which really across screen sizes? Again, what do I do? My work is at the intersection of journalism, code, and design. That essentially means that I do some research and reporting. And I use code to tell stories. I'm a journalist by training. I don't have any degrees in computer science or design. I am self-thought because I figured that with these skills, I could tell stories that I otherwise wouldn't be able to. And it was something that I picked up in order to tell better stories. I currently work for Reuters. You know, the news, like, any of the organizations. Kurma, we are losing your sound. Our audience is primed. OK. Your sound is cracking up. Is there anything you can do at your end? Then please do otherwise. You can just start from the beginning of this slide. This slide? This slide. Yeah, this slide. The Reuters. So yeah, I currently do graphics at Reuters in Singapore where I tell stories about Asia. Reuters is a global news organization. So even though I'm telling stories about Asia, the purview is that we are telling those for a global audience. So thinking of stories in a manner that would relate to a global audience. And that's that. My work can range from covering the coronavirus to fires, to elections, to protests, to Bollywood. So it's essentially this data that can help with the story. I use it to tell that story. I don't specifically cover a particular beat. It's a wide range of subjects that I've covered over the years. And today, what I'm going to talk about as I mentioned earlier is one classic nightmare of my life, which is different screen sizes. I have killed multiple visualizations that I will make and love, but they won't work on the phones. I would kill them. And over the years, I think I've come up with some tricks and tips that have helped me avoid that position right from the start. Kind of be, we talked about being mobile first and things like that. But one tricky challenge with the Reuters audience is that I don't know. So we sell news to clients. So BBC could buy an interactive we make. And Hindustan Times could also buy a graphic we make. So we are designing for different audiences. I don't know who ends up buying my graphic. So I can't predict whether it will be a predominantly desktop audience or predominantly mobile audience. So we try to make graphics that are the best they can be on desktop and that they are the best they can be on mobile. So it's not typically mobile first, but it's more along the lines of the best possible thing we can offer across screen sizes. And today, I'm also going to, so I thought I'll start with something that I've never spoken about before, which is my first published interactive. My published interactive was during an internship at Pointer. It was a Google News fellow there. Pointer basically covers the media. And I did this interactive where the goal was to show how diverse the American newspaper industry was. So it's like basically two dropdowns. You pick something and it throws you some icons. I think this was in 2015, just after I graduated. As you can see, it's not very nice. The, it's an iFrame that's hosted on my GitHub, on GitHub pages. And like the line height, of course, is insane. So I had no sense of design or whatsoever. But yet it is something that you would be able to interact with no matter what your screen size is. So the interactivity aspect and the communication aspect still works because I'm asking you to make a choice and then kind of tap into the idea that you expect something else, but you're going to get something else. So that becomes the interesting hook for you. People have been doing interactors for a while. Within the news organizations, it was peer-headed by the New York Times where this guy called Mike Bostock along with a colleague of his called Sean Carter started making some really nice visualizations back in 2011, 2012. And they also created their own framework, which is something that today most people who make data is used. It's called D3. It's a JavaScript library that is used to make data visualization. So this is one of the key visualizations they made back in 2012, when D3 does not work on. Good. Gurman, I lost your voice. I thought I got dropped off. Yeah, you got dropped off for the last 10 seconds. You can cover after D3 the fact that they had launched D3. So when they did this, this is one of the first visualizations they made using D3 back in 2012. And this thing does not work on the phone because that was not even a priority or something they were thinking of then. All they were thinking was that of making cool visualizations. It's something that the New York Times does even today. So even with the current elections, they did the same with, but now it's responsive in 2012, it was not. Similarly, Reuters Graphics was also doing graphics back in 2013, 2014, and even our graphics weren't necessarily responsive. If you think of it, we have been thinking about this only in the past six, seven years of how do we make data visualizations for the phone? We weren't thinking about that before. Now I come to my tips. Click Betty tips are here. The first tip is that you tweak the treatment based on the screen size. So this is a graphic we did about pollution in India. This was, I think, last year. So using PM 2.5 concentration through models, we showed how the polluted as, as you can see, like the Northern Indian belt is quite bad. So it's a world map when we show all of that. But on the phone, it's a globe. On the phone, it's a globe because world maps on the phone don't look great because of the shape. So we, again, that also makes India the center. So you can focus on that as well. You lose some context. Yes, you definitely cannot see America, but still the focus of the story stays. Another graphic that we did about the coronavirus in Korea, this graphic looked at how transmission happened and how one patient led to the outbreak. So superstitors and things like that. So if you look at it on desktop, you will see we use actual people to show how many people were traced as contacts. If you are on different screen sizes, they're simple bars because the connections are the most important thing. But at the same time using icons can help you think of them as people, that we are talking about people. So it's more effective in that manner, but on the phone showing people would take up a lot of space. So we ended up using bars. This is a story I did when I was at the Hindustan Giants. I showed how margin of victory in Gujarat had gone down through this technique of using multiple visualizations of the same kind of small multiples. So I used small multiples on desktop, but on the phone, I just did that because I wouldn't be able to see all of them in one go. And if I have to scroll a lot, I would lose the point. I wouldn't be able to compare and things like that. So I did this on the phone. So thinking of ways where you tweak the technique based on the screen size can be one way. Another way that often works is to just flip it. So this is a chart I made about petrol prices in India. I think I did this two years ago and looking at how based on what percentage does a person, of their daily income, does a person spend on petrol. So based on GDP per capita. And this is what it looks like on desktop, but on the phone, it's flipped. So that's one technique you can use. And yeah, it's interactive. It attacks cells in your body and it was used as an illustration. So this is how it looks on desktop, flipped on the mobile. So that's gonna be one technique that you just flip it. Then you can also make subtle design changes to make things more readable. So we did the story recently with respect to the US elections. And it's a simple straightforward map driven story you scroll through and we tell you where they have gained, how much they have gained, if Biden has gained in suburban neighborhoods and things like that. So you see it's like has cities and state names and you have these peaks and it tells you a story. But so looking at the map again, this is what the map looks like on desktop. This is what it looks like on the phone. We got rid of the labels, both city and state names so that the peaks were the focus and otherwise it would have been too crowded and there's no space on the phone to show those labels. It's a very subtle design change to just focus on what's important. Next step, how you can make small U-Exchanges based on the device. So we have this tracker about the coronavirus and we have been focusing on this thing called percentage of peak. So say if India at its peak was recording 90,000 cases in a day and today they are recording 70,000 so what percentage are they like? Whatever percentage of peak they are. So that you can see how close is the country to their own peak who's at their peak and things like that. So this is of course it's a world map so it works well on desktop. If I translated the same thing on the phone it would look like this, which is horrible and you can't see things. So one of my colleagues came up with a U-Ex solution to this which is that we do something like this. You interact with insect map and kind of figure out, move the map that way. So it's a U-Exchange that helps with making the visualization more accessible and more readable on a different device. Now, if another way to make your job much, much, much easier is that you just design for the phone. You think of that. I have this technique where what I do is I take an A4 size sheet, I fold it in half and that is my sketching ground. So the idea is if I sketch for that screen which is my mobile screen at the end of the day I would be able to scale it back on desktop. So this is something we did for the Indian elections. The mobile interface, you just click on a thing, you get information, the tool type opens a box, the box is scrollable and things like that. On the desktop, it's the exact same thing. It's just you have a hover as well and on click you get the detailed one. So, but it's the exact same thing. The rest of the wiz, it's designed in a manner. The experience is pretty much the same across devices. This is a story I did about the Indian elections as well which is what it makes you scroll through all the phases of all candidates that contested in the election in 2019. So using those faces and this grid of faces kind of interface again works both on mobile and on desktop. So this was, if you think about mobile first, this was definitely thought of as something that was mobile first because it's easy to scale up that way, it's not interactive, it's all static. The only interaction here is scroll which is actually the most basic interaction and the most intuitive interaction of them all. First, add the names which puts the fastest person from every country against each other. So the lines race and you see when Usain Bolt reaches the finish line, where does everybody else? So like again, very mobile first, the desktop experience is exactly the same. There is no difference between the two. So thinking of a way that if it works on mobile, it'll pretty much work on desktop. That can be one way of thinking and conceptualizing your whiz. Tip number six, be selective with interactivity because interaction is expensive and it comes at a cost. I spoke about how that faces this was not interactive, it was all static. That was because if say it was interactive, I could hover over the face and get to learn about the people. I had to load a lot of data on the page. I had to load 8,000 photos separately which would have been a technical nightmare in itself. So things like that. And at the same time, it would not help me communicate the story any better. I could tell the story pretty much with the static whiz as well. There is a piece that I did at the Hindustan Times which was about Lata Mangeshkar's career. And it was like fancy trick that I did that I turned her face into a chart. And now if, and then you, as you scroll through, I tell you bits about her career. So I did that. But if you're thinking about like an SVG that is moving 5,000 plus reps across the thing, your browser will is dying in the process. So the same thing while it looks fairly okay on my fancy iPhone, on another Samsung phone, it will get like, it will not be that smooth. The animation won't be that smooth. A little, that means the device will probably heat up and things like that. Now of course you have WebGL and other technologies that can use, but even devices that are compatible with those and et cetera. So like thinking when you make things interactive, you have to think about so much more and it's just a bigger nightmare. So avoiding interactivity if it doesn't help communicate the story, that is something I do all the time. Now, and that brings me to my next point that static visualizations are great. They also give you a bigger control over what you're doing. Annotations are very hard on dynamic visualizations. Static, we actually at Reuters do a lot of static visualizations. So this is a piece that my colleagues did about plastic bottles in the world. Putting them next to world like known places, known Burj Khalifa and New York City and things like that and putting in perspective that how much plastic do people consume. Now, something like this is a purely static piece, but it is still so effective because of the context that it uses to communicate. Again, same experience on the phone. I can control everything. So I'm able to crop et cetera and just based on that, but I learned the same things on the phone. Exploit the scrolling interaction. Scrolling is the most intuitive thing for a person to do on the web. And with scrolling, it's more like, I think that something that drives purely on scroll is perhaps the most mobile first thing you can think of because even though on a desktop, my tendency to maybe click on buttons and interact with things and use tooltips would be higher, but on the mobile it might not be as much. My postdoc who made D3 says it's scrolling is all... So when you're telling those, if focused on scroll interaction, you can kind of tell a story in a linear manner. And with scrolling, it's also that you have now these scrolling kind of thing within interactors where as you scroll, I walk you through a story, like things happen and dots move, the Lata Mangeshkar piece or the Joe Biden story are both examples of scrolling telling. There's one thing that we use a lot in scrolling is to kind of build that suspense, the one thing you look at the faces, right? I'm scrolling, scrolling, scrolling, and it's not ending. So that is because I want you to tell you how many people can test. Like it's a big grand affair. And as I'm scrolling, I'm like, oh my God, I've still their candidates left. I've scrolled through 5,000, still their candidates left. So scrolling is also a very good way to interact with the audience and tell something and drive home a point. This is a piece we did about bushfires in Australia. And the only interactivity here is this figure that tells you how much land has burned at the top, which is basically done based on how much you've scrolled. But it's all static. It uses these shapes of different places for comparison and perspective that how much land are we talking about. And it's the exact same thing on the phone. So using scrolling as a way of interaction is also a good way. Tip nine, don't hide information in tooltips and use annotations for context. If I'm relying on the fact that the person will access the information to the tooltip, that's a bad assumption. If it's important, you should put it out there and not depend with the user on interacting with it. We try, which is why we do a lot of statics because it's easier to put annotation on. It's easier to communicate the context. And yes, if we have a more invested user, which might be like 1% or 2% of your most invested audience, they might appreciate tooltips. But majority of your audience needs to get like a story straight away. And the best way to do that is to tell them things and give them the context and use annotations in the process. This is a piece we did about the Ganga and pollution within the Ganga and at what points are sewage added and things like that, how much waste water is discharged within the Ganga. And it's entirely static and told through annotations in different points. Also again uses the scroll as a method of interaction. One of my favorite statics graphics is this by a former and current colleague of mine, Anand Kattakam. And it's basically how many people are on the depth row and the length of the line shows you the length of their case being pending. And then he has these annotations of time markers for context that this is the average time for person graduating college. This is the duration of the Vietnam war and this is Sachin Tendulkar's entire test to get there. So things like that, annotations can be very helpful for context. The last step is that mobiles can be a great lesson in editing because they help you focus on what is the most important. So whenever I am thinking of like a limited screen size, I have to start removing things based on my screen size. That's the time to stop and think, okay, this is important, but what can I get rid of? So it's the editing process, essentially. Even within a story, if I write 800 words story, I will crunch it down to 600 words. I'd be cutting what I can probably do away with. For example, this is a piece we did about the pollution in Delhi and the kind of really thing, but... Karmal, we are again losing you. Can you resume from this? We lost me and I'm back. Yeah, yeah, you're back. Can you just resume from this page only, the page you're on? Yeah. So this is about pollution in Delhi. And in addition to, I don't have the scale in the screenshot, but essentially green is good and red is bad. And it's a spectrum of PM 2.5 concentration. But with that, you also have these two charts that show the temperature in wind. So lower temperatures tend to also increase, like deteriorate air quality. Similarly, wind speed also will improve air quality. So things like that. And we wanted to put these two charts for context on the side. But on the phone, that would mean that it would take up a lot of space and things like that. So we decided to remove temperature and we just kept wind. So something that was because we looked at that and though temperature is helpful, the wind is much more affecting the air quality. Again, editing decision, deciding what is it that you can get rid of. So in summary, my 10 tips. So tweak the treatment, you can flip it, you can use subtle design changes, you can make UX changes, you can just design for the phone and your life will be so much easier. You can be selective with interactivity, do static visualizations because you'll have a lot of control over them and exploit the scroll, don't hide information and how mobiles create less than editing and help you focus on things that are the most important for your story. I'm also going to briefly mention three tools that are very helpful in whatever I do. One is, as I mentioned D3, so it's a JavaScript library that essentially lets you get a lot of control over whatever vision you're making. If it's anything that goes beyond the basic line chart or bar chart and it's anything more complicated, this requires you to have greater control. For example, a map with peaks and things like that, something that you won't see in normal tools and you're coding from scratch. This is the go to library. It's essentially my bread and butter. I won't have a job if this library won't exist. The second thing is AI to HTML. So this tool, it's also a JavaScript script and what happens is you can make your static visualization in Illustrator or you can make it somewhere and it'll bring it to Illustrator and polish it up and things like that. And with this JS library, get an output that's just HTML and paste it on your website. So a lot of the static visualizations that we do are AI to HTML because it makes the text selectable. So the text remains crisp and clear and everything that's not text is outputted as a faster as an image and it just takes care of all the positioning. And the third is PIM for eye frames. Height is a challenge when you're doing eye frames and some of our visualizations may be made and our clients will go and put them within an article and things like that. And when they are doing that, the eye frame in itself needs to be responsive and PIM helps you do that. It's also snippet that you add to your code that lets you make it responsive. And the beautiful thing is that all three of these are open source projects and all three of these came out of newsrooms. So because they're aids that people who were telling stories within news realized would really help them tell the kind of stories I tell for a living. And with that, I am done from my side. And if you have questions, comment. Thank you for that, Jay. Gurma, thanks a lot. This was an amazing presentation. I don't think we should give too much credit to D3.js. I am sure you would still have a job even if there was no D3. And most likely there'll be some other library that you will create if it wasn't for D3, given that you're doing so many different forms of visualizations throughout. Thanks a lot. This is a super useful set of tips and it's a great presentation. Folks who are online on Zoom or on YouTube, if you would like to ask any question to Gurma, this is your time to start sharing them on either the YouTube live chat or on the chat window in Zoom. And I will keep taking up these questions one at a time. Just to start things off, I do want to go back to the first visualization that you had created and you have put out that it doesn't look too good. You had no sense of what's the proportionate line height and all those things. So what's your thought when it comes to visualization on form versus function, what is more important and how do you prioritize things? I think the function definitely is more important. The way I, so when I'm talking about stories and storytelling, I focus first on the story and then on the design because no matter how beautiful it looks, if there is no story, there is no story. The entire exercise is futile. Yes, design can help you tell a story in a more effective manner, but only if there is a story. So the plastics piece, for example, that's, it's based on one stat. It's based on that every minute we consume these many plastic bottles or something that came out in a report. But instead of writing that one sentence, we decided to make a visualization out of it. That was definitely much more effective and powerful. But if that stat in itself was not interesting, there's no point. So the focus is definitely more on what you're trying to say and then on how you're saying it. Right, so I do believe that lots of times when you look at really interesting visualization, you are caught up in how beautiful the thing looks. It's so interesting. And sometimes you fail to read into the story itself, what is it trying to communicate? Like for example, when you were showing the nice visualization that slowly led to the birth of D3 in New York times that come the waveforms that were going down, it looks so cool because you've not seen anything like that before. But at this point of time, I have no clue about what the story was. I just know it looked cool. So how do you strike that balance between pushing, because you know you have a good, great story, but maybe at a certain degree and after a certain stretch, if you make it too visually appealing and interesting, people might just get to engage, like engaging with the visuals significantly more than the meaning that it's trying to communicate. So which is why we try and use a lot of annotations because annotations can be a great way of putting the story on the whiz itself. So I honestly believe that paragraphs, et cetera, and context is great, but it's best if it's on the visualization. The visualization should itself tell you the story. And that's the thing that we are also evolving towards now. It's something previously, as I said, doing annotations on interactive visualizations is hard and it's hard to crack on dynamic visualizations. If it's static, it's much easier. So one way we deal with that is that we put the story on the whiz itself. That's one thing. And the other is, of course, based on the story, you have to make certain sensitive choices. Like I can't color matters on the kind of story you're telling. If it's something about the coronavirus and like I'm talking about depth, I can't use cartoons. Just normal sensitivity also helps. Whereas if I'm telling you how the virus attacks the body, that's great. Cartoons are great to explain that. We lost you for a few seconds. The subject. Yeah. You said cartoons are great. So we got to that point where you said cartoons are great when you have to explain how does the virus attack the body. Yeah. So it can be great for that context. I'd like to explain how vaccinations work. And so it depends based on what you're trying to communicate. Also making those choices can help. What which kind of stories do you think are good contenders for visualizations? So in India, for example, you will see a lot of visualizations around elections because there is a lot of data that exists for that. So anything that has good data is a good contender for a visualization. In India, that would be elections. They have some good education data available. Globally, right now the biggest data story of my career and most of my colleagues' career is the coronavirus because everything is driven by data. So which is why so much of amazing with content is coming out alongside the virus because you're trying to find out that there are excess deaths happening. You're trying to answer where outbreaks are happening. And all of that is driven by data and through visualization. So it's also the best possible visual story of my career actually. But the interesting thing that I started realizing is that I think a few years back I used to think that, oh, when you have a data heavy story, that's when visualizations are great. But somehow, once you dig into a story, you start finding data. Essentially, there are so many times I never thought that this is data. But these days, as you get into a story, you start discovering data out of it. It's almost the other way around as well. So do you feel that almost every story has data that you can find out and visualize it? So ideally, yes. But a lot of times your dream dataset does not exist. So your question might be correct. And yes, you can answer that question with data, but maybe that data is not available. So that's a challenge. But I do agree with you that the instances where this happens a lot when I read scientific papers and they will explain so much about key studies and the number of people they analyze and things like that. I'm like, this is a diagram. Why is this written in one page long paragraph? This should be a diagram. I had a surgery and my doctor sent me a paper to understand the risks of surgery. And I read the whole paper very meticulously. And in the end, I was like, this was a Sankey diagram. This 30-page paper was actually a Sankey diagram. So even if there is maybe no data, there can definitely be visual opportunities that you can use just to explain things. For example, I showed just pure illustration. There is one way which we use to show what signals people use during the Hong Kong protests. So what signals they use for umbrella is what signals they use for wrapping paper and protective shields and things like that. And we did that through illustrations. So again, maybe it's not data, but it can be something else. Photos can be data too. If I'm showing that thing with people's faces, that's photos, but that photo in itself tells you something as well. So that's data too. Then there is one story we did for which we put a camera on top of a building in Delhi to tell a story about pollution. So we click the picture every hour. And that picture is also data. If we analyze colors in that picture, those colors are also data. So you can definitely be more creative about what is data. It's definitely more than just a spreadsheet or a CSV or a JSON. And yeah, you can definitely be creative with it. Yeah, yeah, I totally agree with this. There are a few questions that have started coming in, but before I go to them, I'll just take a couple of my questions, give people more opportunities to write your questions. I'll take the slightly more technical ones a little later. I'll start with the lesser technical ones first. So my next question is what direction do you take when you're thinking of visualization? These days, are you going mobile first or are you doing a desktop first and then crunching down the visualizations into a mobile? I personally do mobile first. But there are people on my team who do desktop first and then transition on. So it varies on the person's techniques and inclinations. My technique definitely is mobile first because I just want to write less code. Pros and cons? That's definitely a pro. Yeah, and a lot of what we do is extremely on deadline too. So because news, if it's something is happening today, maybe I can tell, talk about it tomorrow, but nobody is going to talk about it a day later. Which is also there. Though most projects that I've been doing in the recent past have been week, long months, long projects, that take time and I have time, but still I just want to write less code. I am lazy that way. So which is why mobile first, biggest pro. I am the first person on my team when somebody comes up with an idea. I'm like, yeah, that's very nice, but what in the world are we going to do on the phone? So I try thinking about that early on just so that my life is not very hard in the end. How has your life or your experience changed from the point of time you started asking mobile first or how do we treat that on mobile? Like if I say that in 2015, when you said you were starting out or 2016, you were not thinking mobile first and now you're doing that mobile first, in what ways are you better off other than the fact that you're writing less code? Like as I said earlier, like I would make some very nice cool visualizations. I could take a lot of time and that's all great, but then feel very stuck when I have to think of the phone. So it's time as well. It's really hard to translate if you're thinking of something that's branched out and like lots of things are happening if it's extremely dependent on interaction, et cetera. It was just that I made these things that looked cool and then I had that did not work. Then I learned from my lessons and my mistakes. I'm like, I don't want to put myself through that again. Has it impacted your creativity in any way? It does in certain manner, yes. It is, the mobile screen comes with limitations. So sometimes I will just think of an ID. Like early in my career, I would say 2017, 2018, I hated phones. I was like, everybody should throw their phones. Why do phones even exist? Because of precisely what you're talking about, I'm like, I want to make that cool biz, but I can't because it won't work on a phone. So yeah, then I had to eventually get over the fact that people are not going to throw their phones. Whereas maybe at some point in my life, I have to design a viz for a smart watch. Who knows? So it might get harder, but it's definitely not getting easier. Have you tried doing that yet? Tried any visualization at the, that form factor? No? No, no, 98. Okay. So I'll take the question that Hamza has asked at this point of time. What is the composition of the team behind most of the stories you have shown today? And what is a typical design to their workflow you follow? Does it change project to project? It does change project to project. So in a breaking new scenario, say for example, there's an earthquake, there's a cyclone that's hitting and things like that. All hands on deck. As I said earlier, our team has, everybody has multiple skills. Somebody writes well at its well. Somebody makes a fantastic illustrator graphics. Somebody writes code and does D3 graphics. Somebody does both. So we are all over the place when it comes to skill sets. So we try and pitch in. We, typical workflow might start on a work call these days. So earlier we used to have meetings in the office where we would huddle around the whiteboard. Now we have a morning call where we say, okay, this is happening in the world, guys. Is there anything that we can do about it? Is there anything we should do about it? Or if people have other long-term ideas, people will just bring in their ideas. A lot of it comes through. We still lose. Gurman, can't hear you. Yeah, you're back. You're back, you're back. Can hear you now. I think it'll be best if you start from the point where you said that now you do morning calls. Yeah, so on the morning call, people might mention that, okay, this is a story. This is happening in the world. Do we do something about it? Should we do something about it? Is it worth a graphic? Then people might also come up with ideas of their own. Something that's more forthcoming that maybe in the context of the coronavirus, what vaccinations are gonna start? How do we track that? Or things like that. People will also talk about potential long-term ideas. And then we kind of start from there. Some of it might also come from a reporter who's doing an in-depth story and might come to us and say that this, maybe this has a graphic opportunity. So it can come first from the graphic team. It can also come first from the rest of the newsroom. It varies from project to project. But to talk of it, it generally starts with research, finding out what data is available. Then kind of cleaning that data and seeing what that data tells you. And then visualizing it. So if you, you can basically it's a three-step process. If one is your data extraction and research, the second would be your data analysis. The third would be data visualization. And the visualization is definitely the easiest. It also takes the least amount of time. The first two are take up 90% of your time. And the last is perhaps the production of it is relatively easy. Unless and until you're coming up with a very crazy idea, then this can take some time. What is the turnaround time usually between the inception of an idea to actually producing it? Again, depends from project to project. In a breaking news situation, sometimes we do it on the same day. So for example, if the Beirut blast happened, we had a graphic on the same day. Then we had another graphic in a day or two, something like that. So these are relatively quicker turnaround pieces because they are based on a breaking news event. But then if it's, we built a dashboard for the virus and that took around two and a half to three months. And it's also something that we are continuing to add features to over time. So I might do like one week's print and add one small chart on the US page. Let me, now currently we are working on incorporating testing data. So something like that can take a longer time. Something like breaking news will take less time. Then there is the pieces that we have done explaining different context in terms of the virus. So how it compares to SARS and MERS or how the virus attacks your body or how vaccinations work. And those might have taken anything between three, four days to a week to two weeks. So actually it really depends on the project and ranges a lot. So the visualizations that you showed today, none of them seem to be breaking news, right? They are more thought out, detailed and would have taken more than a day clearly to create them, right? Thinking, yes, yes, yeah, for sure. Got it. All right, now between mobile and desktop, you had shown how the visualization changes between desktop and the mobile screens. What technology do you use to do that change? Is it very similar to how responsive web design works? Or is it something like the JavaScript does, browser sniffing, that what are you the browser? Or what is the technology behind it that helps you between the transition, between the phone and the desktop? So it is basically, as you said, responsive web design for the most part. Media queries. So D3 lets media queries, then D3 also lets you redraw your chart. So essentially what it does is on a V size event, it will redraw the chart again. Okay. It will take all the pixels will be drawn again. So that's something you do. Though... Because the way... Sorry, lost you for a few seconds there. So D3 redraws the chart then? Yeah. So the way it works is that like when you open a webpage, it takes your screen size and based on that, it will decide which pixel goes where. And it's an SVG that it draws. And if I change it, it draws the SVG again. So that way, D3 lets you do that. But then if you're doing annotations, et cetera, you might have to, you know, hardcore things for that. Like if it's a bigger screen size, maybe I want the annotation on these coordinates. If it goes on a smaller screen size, you know, change, look for different coordinates and things like that. So that's one way of doing the responsibility. Some of it, some of our visualizations can also actually be videos. Okay. So for example, I showed the pollution was where the world map was there and you could see PM 2.5 move. So those are two are actually videos. So I've outputted two, three videos for different screen sizes. And based on the screen you are on, load that video. So some of our visualizations might also be that if it's AI to HTML, it is essentially a different chart for every screen size. And it loads up the chart that you need to see. So it will hide different, the other screen sizes and show the breakpoint you are on. So it is a lot like a responsive web design and a lot of display and display block as well. Got it, got it. But I was going to come to a different question but this actually ties into another question. Very cleanly. When you do implementations like this, how do you take care of the accessibility aspect as well in any way? So color is one thing that we do check for accessibility. We have a palette that we have come up with based on all the checks for that. Other than that, I don't know. I was talking more from a screen reader point of view, especially when you're showing an annotation, hiding the annotation and things like that. Is there, are there anything that you're doing currently that will make sure that someone, for someone who is not consuming your story visually for that matter, is still able to access it to a certain degree? What kind, do you have any tips around that or that you follow? Unfortunately, actually we don't do much around that. The only thing that might help in that scenario is the story that goes along with the piece. So they are actual words on the piece as well, paragraphs that tells you what the wizard's going to show. But other than that, we are not doing much as of now to bridge that gap. Got it. Something we definitely should but we are not doing it right now. Fair enough, fair enough. I just wanted to know if you are, then what is it? And then this also ties in nicely with the fact that most of the newsroom or the news sites, the visualizations that we see, very few are like, have such dramatic stories that you have just shown, which is completely immersive or completely visual. Most stories will have a written story, which is what you just talked about and certain supporting visualizations. So when scenarios like that come in, is the story written to explain the visualization or elaborate on it? Or is it the other way around where the story is written and then your team is called in to say that can you give some supporting artwork for this or a graphic for this? So in most of the scenarios, if it's not a visually driven story and the visual is just complimenting the text, it's probably because the visuals came in later. Got it. Like, if you are thinking from a visual point of view right from the beginning, your reporting of the story also changes. You start asking different questions, you start reporting in a different manner, which is where like my journalistic training also helps. A story would be very different if graphics are brought in the end and if graphics are brought in in the beginning. In those scenarios, I think it's just, the graphic is complimenting the story itself. Say for example, there's a bomb blast and you write that there's a bomb blast and then you put them in. We lost you Gurman for some time. You said that the story is like a bomb blast and then? So it might just be a 200, 300 word story saying that a bomb blast happened, what's happening and things like that. And then there might be a map showing where the bomb blast happened. So the map is not the story, the map just helps you understand the story a little better and puts extra context to it. That's an example of. Got it. So when a subject matter comes in, how do you know what should compliment which? Like, should it be a text for a story and then some visualizations to compliment it or should it be graphic for a story and some text to compliment it? How do you take a call or do you take a call on that? And if you had to, then how will you decide which way should it go? My boss takes a call and if it's not a graphic for a story, then it's not for our team. Oh, really? Okay. So the next question that I have over here is what are some of the things that you'd keep in mind to ensure that the visualization works for both touch and non-touch interfaces? Because we talked about large screen and small screen, but what about touch versus pointer-based things? Any thoughts around that? So however interactions, of course I can't do on a touch-based interface, right? So we will check for that and that way the interaction will change. As I said on the map on smaller screens, I am giving you the way to drag and interact with the map in that manner. So yeah, we do take those into account. One thing that we might do on maps, for example, is that if I'm on a pointer-based thing, I can just hover and learn about it. But say I am on a touch-based thing, I might get the tooltip, but we put a cross on the tooltip to help you close it because we know otherwise it will get in the way. These are like small things that we keep into account or take into account when working with touch and pointer-based, yeah. Do you, as an organization, because you have access to what devices are mostly used for accessing your visualization, have you started prioritizing one, either the pointer-based or the touch-based over the other one? So as I was explaining this earlier, that because our business model is very different where we are selling it to clients, I might know about my organization, but I can't predict what is going to be with the other organization, the people we are selling it to. So we can't prioritize the assumption as it should serve both audiences. Okay, got it. In case someone else is taking your visualization, how do they add it to their site? Is it embedded in an iFrame or some other way? So both ways, when somebody buys a thing from Reuters, they get a full package that they will basically give them a raw code. So if they want, they can switch logos and things like that and host it on their own server. Or if they don't want to go through all that hassle, they can also just embed a graphic on it. So if it's embedded, there will be times where we sometimes make different versions for embeds. Like if it is scroll based interact, like scroll detailing, where if I scroll something moves and things like that, that is very hard to do in an embed and doesn't make sense as well. So we might do paragraph chart, paragraph chart, and you might make certain tweaks to make it more accessible for an embed and things like that. But yeah, most of the, it goes both ways. They sometimes will host it as like the raw code itself or they might do it as an embed. Okay, let me take this question from Nithya at this point of time. Do you experiment with using the newer functionalities of smartphones in stories? For instance, turning it into a VR headset or getting people to turn on their cameras and adding AR, et cetera. Have you experimented with these? My team has not done anything with this yet. I know the New York Times has a research lab. I'm forgetting what they call it, but they have a full team who's just figuring out how to make VR and ER experiences. We haven't experimented with that at all as of now. Okay, so participants, if you have any other questions, feel free to put it on chat or on the live chat on YouTube and they'll be sent to me. If you want to ask a question directly to Gurman, feel free to drop in a text on the chat or raise your hands and I'll patch you in. Okay, so another question that I had written while I was looking at your presentation. You had prioritized static, the static visualizations which have less interactivity and stuff. How do these static visualizations are, how are they generally implemented? Are they, are you still using D3 to draw an SVG or are they like pre-rendered images? Do you have any preferred approach? So my most common approach that ends up happening is I will generate it in D3. I will export it to Illustrator. I will add annotations there and I will AI to HTML it. That's the general workflow for the static visualization. So I'm... Then how do you take care of responsiveness? So AI to HTML lets you have different artboards for different screen sizes. Oh, okay. So I will have like four or five artboards at different breakpoints and the text in itself, if AI to HTML takes care of the response it would do it for that. That's why it is a whole script just to make sure you have responsive ways because otherwise say for example, everything is on, text is an image. It won't scale well across screens which is why they made this tool so that text would scale well across screens. Then how do you actually do any... Okay, so because they are static you expect that there'll be no interactivity Yes, there is no interactivity in these... Even scroll. I mean, scroll is on the page, right? So it's just an HTML div. So if it might be a very long divs I'm just scrolling through the div. So there is no movement. There is no movement. It's just pure static. For example, if you're looking at the plastic bottles piece. Yes, but... Plastic bottle piece is just AI to HTML. So now that piece, for example the images that you see of the pile and all of that that's generated in cinema 3D. So which takes time and it takes time to render and develop and all of that but it is outputted as an image then taken to Illustrator and added some annotations and just put on the page. So a lot more work and processing power might have gone into generating the image in order to not put load on the browser itself. Got it. So what this means is that you are providing a separate rendered image for that plastic bottles thing on the mobile and a separate one in the desktop. And if we are on the desktop and we resize the window the entire image gets reloaded and requested from the server. Got it. Got it. All right. So how do you ensure I'm going to ask a few things more on the technical side at this point of time? How do you ensure that the performance of these interactive visualizations are great and they are not affecting our browsers? You already talked about how performance is so different on iPhone versus probably a low powered phones and things like that. What are some of the things that you do and keep in mind from a performance point of view? Test and see what breaks where. So one, like I was talking about how I hate phones. I also hate the fact that all phones are so different. There are two things I hate about phones. The word of web. Yeah, yeah. I should have just written words here. Why did I decide to make graphics? Would have been easier. Scale across devices. But one thing that we did, some things that you can do, that if you have more than a certain number of elements, don't do an SVG, do canvas. If it's more than that, those elements don't do canvas, do WebGL. So there is that ladder you can climb to improve performance when you have too many recs and too many SVG elements moving around. That is something you can do. That's some visualizations that I have. For example, there is a globe. Sorry, we lost you at there is a globe. We lost you at there is a globe. So there is a globe on our coronavirus tracker that is done using SVG. Sorry, not SVG, sorry, it's done using canvas and it doesn't use SVG because there is, it has these animations and movement on all of that. But at the same time, it need not be interactive. It's just animation. So canvas is a better candidate. So we make decisions like these based on wherever we can improve performance. So that's the tree, decision tree, canvas, then, sorry, SVG, then canvas, then WebGL. That's something we can do. But other than that, it's just testing and figuring out if it's breaking, then maybe we need to do something else. Otherwise, does it even have to be interactive if it's taking us too much far? Can it be static? Got it. This actually ties in well with what are the things that a designer should be learning? Let me say that a large number of people who are trying to build these visualizations and all visual storytelling would probably start with static infographics at a certain level and then slowly graduate to build the kind of things that you're building, good one. What do you think are the stages of learning that you have to go through from a static infographic to the things that you have been making? In tech point of view or in any other form and where do you recommend one should learn these things from? So if you're talking about static business, if you're making good static visualizations, you're already, like most of your job is done because if you're able to make good static visualizations, that means you're able to think of visuals well, you're able to think of concepts and infographic concepts better. So I would say the first foundation is to just be able to make good visualizations. You don't have to know how to code. Being code literate is helpful for sure, but like my boss, Simon Scar, who is one of the best infographic designers I know, he doesn't write code. He mostly just does static visualizations. And that's great, that's his expertise. He's really good at making maps and say QGIS, something that does not require you to code, something that's point and click and can help you output things and you can do things in Illustrator and things like that. So I think really ace your static game first. To use other tools to get to that point, there are a lot of maps, for example, they're point and click tools that can help, like QGIS that can help you make maps that you can output and polish and things like that. There are tools like rawgraph.io that are again point and click that you can use to generate visualizations such as stream maps, et cetera. That may be your typical Illustrator will not generate. So use tools like these first and experiment with static visualizations. And once you have done that, then you have to, there are two ways you can go about it. One is if you want to do visualizations for the web. If you are doing that, then you go through the JavaScript route and you have to learn web development. So the first graphic that I showed you, those icons from pointer, that is just at that point in time, I only knew jQuery and underscore. So it uses those two things, essentially something that can help me load the data and something that can help me filter the data. And that's pretty much it. Those are the two functions maybe I'm using on that page. I did not know any B3 at that point. So it's more of a test of web development skills. So you can start there, you can start picking up web development skills and you can do basic things with things like jQuery and underscore. And then kind of level up with things like B3 because that in itself is, D3 is like learning a different programming language. It doesn't look anything like JavaScript. So it also has a very steep learning curve. So you can try doing that, but you don't have to, you can continue making amazing. Gurman, we lost you at, you don't have to learn D3. Yeah. And you don't have to learn that. You can continue making things in Illustrator and porting them and through things like AI to HTML, if you want to put them on a webpage. It's not something you have to do, but yes, if you want to make more interactive things, if you want pixels to move when you scroll and things like that, then you have to go to that route. Another way might be that maybe you want to generate more complicated static visualizations, but you don't necessarily want to do them in a browser. You can then that way, if you are someone who's comfortable with say Python, you can make a lot of visualizations in matplotlib as well. You can also make a lot of visualizations in R through ggplot2 and output things in that way. The routes can be, it can be n number of ways to do it, but it's super important that what you are trying to do is for an agenda. So like, which is why I came to like the idea of telling a good story is much more crucial to all these tools and tricks, because if that ability to tell a story is not there, no matter how many languages you write, it's not going to be helpful. All right, have you experimented with things that have come after D3 because lots of people find D3 very difficult and there have been tools and JavaScript libraries that have been created, including more recently, this Sweat and all that has come and have you experimented with these and any thoughts about them? So we have experimented with combining React with D3 and I think we are on our way on using Sweat as well in more of a graphic building, like in our toolkit, we are adding that. But the tracker, for example, that I've been talking about, that uses React. So it's a combination of D3 and React. So that, so those technologies can definitely help you in terms of performance, in terms of writing less code, et cetera, but you still need D3 to make the lines and the pixels and the circles for the chart. It can definitely help in the interactivity and dynamic aspect of things. Then there are other tools as well. There is something called Viga, that is another charting tool that require you to write relatively less code. And I have tried those, but I think after the point what happened was because I was so comfortable with D3, I did not go to anything else because I built that muscle already. I do agree that it's hard, it is quite hard to pick up in the beginning. Okay, I should do a time check now. It's already almost 12.25. Thanks a lot, Gurman, for to answer all the questions that I had, so patiently including the couple of questions that the audience asked. And I do want to highlight four of the tips among all the 10 that you have, which are something that are definitely very close to my philosophy of the web and all. Tip number five, which is if it works on mobile, it works on desktop, amazing tip. Because very few designers would think in that route. So this is really good. Tip number six, which is be selective with interactivity and interaction is an expensive at a cost. And this is something that, because I am a developer as well, something I have had to talk through with lots of people, lots of designers because the cost of the interaction is not easily perceived by everyone, especially not so when you are on a 27 inch iMac and working on that. The tip number eight was also amazing, which reinforces that scroll is the most basic intuitive interaction of them all. On that note, have you ever had anyone complain to you, this is too long, I have to keep scrolling, Gurman? No, because I think we've been able to use it smartly. And if I am making you scroll too much, I put markers or things like that in between to tell you that something is happening. This is for a reason. So for example, if you are making you scroll through 8,000 candidates, I put in my... Sorry, we lost you at, if you have to make us scroll through 8,000 candidates. Scroll through. I put in markers as you scroll. So I would say that you have scrolled to 2,000 candidates. Now you have scrolled through 5,000 candidates. Yeah, the feedback. Something to tell you on the way of scrolling that something is happening. And then finally, when you reach the first woman after scrolling for after like five, six scrolls, say that you had to scroll through 7,000 something candidate to get to a single woman. So you scroll here is long for a reason. It's supposed to build tension. It's supposed to build like, oh my God, this is not ending. So that feeling that this is not ending is point of driving the story. Yeah, yeah, absolutely. And scrolling is something that people tend to do as long as they're still engaged with the page. And these feedback points that you just said that tell them that you have done this or you have achieved this or you have learned this new thing automatically keeps the person still engaged in that. And maybe people are not even initially thinking that scrolling so much just because of that constant feedback that is coming in. So that's a wonderful tip. And the last tip that I found very interesting is that that mobiles are a great lesson in editing and it helps you focus on the most important bit which is from where all the mobile first movement in web design and development also came in apart from the performance bit as well the fact that in a constrained environment you focus on the prioritized the most important bits. So great lessons and great tips, Gurman. And definitely one vocabulary that I have added from this conversation is scrollily telling, right? Yeah, scrollily telling. Scrollily telling, never heard of that before. Thanks for adding that to my vocabulary, Gurman. So everyone who has joined in our live thanks for giving your Saturday morning to us. We are doing these content web series of conversations almost every Saturday at around 11 in the morning. The next two Saturdays we have one conversation around security and we had done the security conversation before but the network with the speaker was not great which is why we are having to redo it. So if you had missed out on WordPress security and how to make sure that your websites are safe and secure or alternatively if there is a security incident what can you do to fix it or at least curtail the problem or the issue at hand? Those are things that we will be talking about next Saturday and the following Saturday, Hamza who is also there on the call today is going to discuss more around modular typography and type scales. So more typography geekery around two Saturdays from now. And post that I guess going into the new year we are planning a few more e-commerce related conversations as well. So those are the topics that we have lined up in the future. If you want to discuss or propose a topic of conversation or would like to request a topic of conversation please go to hasgeek.com slash content web and put in your suggestions or proposals over there and we would definitely try to find the right speaker to come and discuss those topics with us. And with that, once again, a round of thank you to Gurman and all the people who attended today. Thanks.