 So, we're going to start the design talk, the design track in a minute or two. And just very quickly about the idea behind the design track, right? We've had design talks at DroidCon before, at the previous editions of DroidCon. And I think people are recognizing now that design is fundamental to any digital product. Whereas design itself is not necessarily well understood, but its need is understood today. I think we've moved in that respect. People don't think of design merely as what something looks like. But they think of it as an entire set of processes that occurs across a product, life cycle development. So I think these four talks today that we have will explore that in some detail. And I think that there'll be enough, there'll be a broad perspective. So we start with design by understanding by Pooja. And then we'll go into some amount of detail about what you can do specifically for Android. We'll go into some level of technical detail. We'll end with some level of technical detail. We'll go into look at how do you build complex layered apps as well. Yeah, I think that hopefully these talks will be useful for you. You don't need to be a designer to appreciate these talks, quite the opposite. I think they would add most value to you if you aren't necessarily a designer. But you're looking to actually build a design understanding. So this is something that I firmly believe. Design is too important to leave it to the designers, right? Regardless of who you are, what you do within a company. If you're building digital products today, you need to have a holistic understanding of the processes that go into building apps. And I think design is one of the underlying fundamental ones which will be useful. So our first talk, Pooja Saxena, is going to be, her talk is titled Design by Understanding. Hi, I'm Pooja or Aniksa Sajupan Twitter. I'm here to give a talk that's titled Design by Understanding. And I realize that the title is kind of generic and vague. And the talk sort of came about because of a conversation I was having with someone about simple ideas which could make the design process better. So in some ways, this particular talk is not specific to Android. And yet, you can apply it quite easily to an Android specific sort of situation. The first disclaimer I need to make before you guys decide to pay attention to me or not is that I'm not an Android developer. Neither do I design for Android. I don't do that. I do a lot of other things. I'm a type-fist designer primarily, so I design fonts. Along with that, I do some typography and graphic design. I'm a food blogger, and I'm one half of a small tiny collective called Paradolic, but yeah, no Android. That said, I do own a Google Nexus S. I've used it for about two and a half years, and I absolutely adore my phone. I honestly wish I could use it for longer. And apart from that, earlier this year I worked with some friends to design a book cataloging web application. And that was the sole time that I've sort of dabbled in design for Android. So that web application came with an accompanying Android app, and it was called Ex-LiPris. So knowing that, I mean, it's fair for some of you to ask why a type-fist designer is giving a talk at DroidCon. I mean, to be fair, it doesn't make a lot of sense. So bear with me for a few minutes, and I'll come to that. I want to talk to you a little about something that happened to me many years ago. So my father, who is also on Twitter, is a fairly interesting man. If you've read Richard Feynman's books, and in particular this one, Feynman talks about how his dad would tell him about things when he was a child that mostly people don't tell children. So he generally made him into a curious, slightly estranged, geeky person, which is what my dad was like. When I was about ten years old, my dad thought it was time to teach me and my brother, who was probably seven, all about HTML. So this was like summer vacation, people go out and play, but my dad thought the kids need to be taught about HTML. So he sat us down, he explained to us what hypertext was, he explained what markup was. My grandfather was a writer, so he could explain to us about manuscripts and how they're annotated, and where markup comes from. And then he explained to us how tags work and so on. And then he asked us to pick our favorite book and type set it from scratch using HTML. And basically that's what we did all summer. That was the book that I picked. It was a time in life when I was fairly certain that I wanted to be an astronaut. It would have been far easier if I had picked a novel then, because this was a book with pretty complex content. It was a book with lots of headings and subheadings and illustrations and captions and tables and charts and so on. And in the process of setting it from scratch in HTML, it was probably the first time that I thought about content. And I realized that there is someone out there who thinks about how to organize it and structure it, that it doesn't just come to us like that. Now of course, at the time, I thought about it as intelligently or as profoundly as a 10 year old possibly can. But for the first time in my life, I acknowledged that this was a real thing. Like someone has to do this, and because of that, someone has to think about it. And that is sort of the crux of my talk, the fact that content is really important. And a large number of apps that a lot of you design and a lot of us use are basically vehicles for content in one way or another. It could be an app as simple as the clock. And here the content is fairly straightforward. It is the time of the day, what day it is, and what date it is. So pretty simple content. When you use social media on your phone, that's again some kind of content. In this case, not just text, but also images or videos. Of course, these apps let you do more than just look at the content. But their very crux is the content itself. Or if you're trying to browse Reddit on your phone, again, content. The Google Play Store, for instance, is probably like a humongous repository of content, right? It tells you about so many apps and it is not just a lot of content, but it's also complex content in various layers and in various hierarchies and complexities. So if you really think about it, designing an app is, at some levels, presenting content. And unless you really understand what that content is, what's important in it, what are the relationships of different elements within that content, how can you possibly figure out how to present it? And that is what I mean by design by understanding. Really understanding what the core content of the app is. And then starting from there, rather than sort of starting to design an app just like that. So when you think about understanding and you think about organizing content, it's something that all of us do all the time. Like it's not something that happens rarely. It's something that we do instinctively more often than not. So for instance, we've all had situations where we had a dump of text in a word processor file. And we were supposed to in some ways organize it, make it look better, and so on. And it doesn't take more than a couple of minutes for any of us to go from here to here. We just sort of quickly see what the heading is, make that bold, add some white spaces, select a different style for your subheadings and so on. And it's quick. But when you really think about what is the process that went through in doing this, you realize that most of it is really instinctive. And when you do something as simple as just making stuff bold and italics, if this was HTML, you would realize all you've done is made stuff bold and italic. You really haven't codified why you've done anything. So when we do something like this in a word processor, it's quick and it's dirty. And it's quick and dirty in the sense that one, there is absolutely no formal codification of why something is bold and something is italics. So imagine if you started making a document, you made a page of it and then you had to go and leave. And some other poor fellow has to come and extend it to being 30 pages. They have to basically stare at the document and decipher why you made any sort of design decisions. Well still, now if the document is 30 pages long, and if you look at that heading which is part one, which is in capitals right now. You take this to someone and they say, you know what, I think this would be nicer if it was not in caps. So now you will have to actually go back to each of the headings, find them manually, erase them, and then write them back in, in lower case. So while this is a certain kind of structuring, it has major flaws. I mean if this was just HTML, it's easier to make it more sort of structured. So suddenly you have your heading tags and you have your paragraph tags. And now if someone is given this text when you're on leave, they understand how you've organized content. So the one big problem of lack of codification is sort of solved. It also solves the problem of extending it, right? Because you know all the headings have to become each ones. And then if you wanna change something in it, you just go and change how the each one has to be styled. So it's simple. The problem with this kind of organization is that it focuses on how things should look and not about what they are and how they relate to each other, right? So it's possible that there are two kinds of texts which are styled in exactly the same way in different parts of the document. And you'll just give both of them an each one because they look the same. So if you extend this metaphor to an app, for instance, it'll be about how things look or how things behave or how things interact, but not necessarily about what they are. And that's a slight problem because you might want to change how headings look, or whatever, how page headings look. But you don't want to change how chapter headings look. But you've put both in an each one and now you're sort of screwed if you want to change just one. So sort of bringing this, making this a little better. Look at this sort of hypothetical markup code which explains a house. So you see that there is like a house tag which has within it floors, within that you have different rooms. So you know this is a living room and a living room can be defined elsewhere as meaning X number of different things. It also tells you things about how it would be visually. So it tells you where the windows are. It tells you what its size is. It tells you what its height is and so on. So this is sort of another step of improving how we've organized things. Now it's codified, it's extensible, and it also instead of focusing on how things look, focuses on what things are and how they relate to each other. The trouble with this piece of code is that it tells you that something is a living room and something is a bedroom. It doesn't tell you that the front door shouldn't open into the living room and it doesn't tell you that the kitchen shouldn't open in the bathroom. So while it sets up these simple hierarchical structures, it fails rather miserably in telling you about relationships within the same level of hierarchy which could be something like dependency, which could just be a constraint that a kitchen mustn't open into a bathroom. That's a constraint or a dependency which says a bathroom should always come with a bedroom. It simply fails at telling you that kind of relationship. The other thing which is sort of completely missing in all the kinds of organizational structures we've seen so far is the idea of priority or what is more important in the content. So I mean, imagine you have to design an application icon, right? So what do you do? You think of all the various elements that must go into that icon for it to make a point, for it to describe what the application is about. But then you also realize that you're going to make this icon at four or five different sizes. So if you look at these four icons here, the first one is the icon that's supposed to be used at 256 pixel square. And the last one is what is to be used at a 16 pixel square. So you realize that depending on the amount of real estate you have, you have to let go of certain details. And you have to let go of certain elements. And how do you do that? You do that by prioritizing what is important and what must always remain in the visual. So in this case, you want to show that there's an open drawer and there's something going inside it. When you have the room for detail, you can make it look really realistic. You can show two drawers and so on. And as you are reducing in real estate, you just about manage to convey the idea. But you don't lose sight of what is the fundamental, highest priority, most important thing in making this icon work. So sort of having talked about these things, I have a sort of, like I said, prioritization helps you decide what is it that you want to show. Whether it's an icon or a website or an app or a book, it could be really anything. I mean, it works even for conversation. So, like I was saying, so yeah, I have a sort of humble proposal, which is that when we think of the design process, I mean one of the steps which thankfully has become really, which people have started to identify as really important is the wire frame, right? We understand that it's really important to put together all the elements of an app or a website. Think about how they're going to sit together way before we start to put any kind of visual effects or embellishment on them. What I'm proposing is that even before we make the wire frame, we add one more step. And this step is probably a step that is going to be extremely intangible. It's also a step that most of us do in part or completely already. It's just that we don't often do it consciously and we don't often do it in a manner that is easily shared with other people. So that process that I want you to add is the process of thinking about the content, understanding it, and organizing it. Because once you do that, I believe that even making your wire frame is going to be an easy task because you would have figured out everything that the content does and how it behaves already. So when you think about your content, there is basically four important things that I think one could keep in mind. The first one is to see what the hierarchical structure of the content is. So simply making taxonomies, understanding if X is an object, what kind of an object it is, and so on. So you're making nested hierarchies and understanding that. The second thing that I want you to take care of is to make those structures and then identify the fact that there are relationships which can't be defined in just that structure. There are more relationships, identify them, and make note. Make note that just like that bathroom kitchen thing, bathrooms in kitchen should never come together. Make a note that they must never come together. So any relationships that are non-hierarchical, make note of those two. The third thing is about sequence and continuity. Are there parts of the content which must come in a particular sequence? If you're, for instance, when you're writing a recipe, you can't give the steps to how to cook something before you've given the ingredients. It's extremely simple when you think about it, but the moment your content is very complex, it's hard to remember that there are 15 things which have fixed sequences. So make sense of places where sequence and continuity are really important. The fourth thing is priority. Identify what is most important and what isn't. Very often when we sort of make hierarchical structures, we fall into this trap of imagining that whatever is on top of the hierarchy is important and whatever is at the bottom or at a lower level isn't. But the hierarchy is just an organizational structure. It doesn't always tell you what is more important for that particular context. So take some time out, figure out what is necessarily important. And yeah, so think about these four things and then move forward to actually making the wireframe. So the way I structure this talk is to take a break for a minute here and sort of find out what you guys think about this. And if you have ideas about what else could go into this extra intangible process of thinking that happens before wireframes, anyone? Hello, yeah, we maybe find out who we are designing for. And there are certain set of questions that come with that. I mean that comes from priority, right? I mean you'll know what your priorities are based on who you're designing for. But yeah, that makes sense, yeah. I think on the same note, target audience. Right, I mean when I say priority, I mean you can only think of priority when you studied them. I assume that all of you do that already, think about the target audience. Actually, what you are talking about is just information architecture. Yeah, and most people don't do it, right? No, I believe that if you go to any organizations like I have been associated with SAP and another big organizations. They ought to information architecture before doing or developing any sort of products or services for their clients. Because- Of course, I mean I'm not denying that. But if you look at most things that we have to use, we all complain that they don't work well enough. And we complain that, why is this menu here? And why is there no button? Why does it ask me so many questions? Why can't I find what I'm looking for? That means that at some level, we're failing to do information architecture well. Don't you think so? Actually, it's information architecture with UX design. It's both, then only you can find what you need. That's why UX has become so important nowadays that whenever you design any product you think about your customers, target audience, and the platform. Maybe something is good for mobile, which does not stand for desktop. Exactly, yeah. So I think UX plus information architecture are the line to focus point. That's the thing, right? I mean, user experience, while it's a term that's used, I mean. So I design fonts, so in some ways that makes me a digital designer. But I really am not. And I've always found that the term user experience is kind of wonky. People have been designing user experiences for decades. It's just a term that digital designers use. But when someone designs furniture, you just call them a furniture designer, but they think about UX because they have to decide where the user's bum has to go. I mean, that's really important user experience, maybe much more important than the stuff that we design, or when someone designs a car. They have to think about user experience when someone designs a house. So that has to sort of always be a part of what we do if you're making anything for people, even if we make food for people, there's user experience. If I put too much salt, that's bad user experience. It's just a term that digital designers use. Anyone else? Yeah, hi. My name is Narendra. Hi. So according to you, what do you think the best three apps in design in the Android marketplace right now? Your favorite three apps. Yeah, your favorite three apps. I don't use a lot of apps on my phone. Okay. I mean, I use Gmail and Talk and Twitter and that sort of stuff, but I'm one of those people who doesn't populate their phone. Or how about websites? I mean, that's an odd question because every website ultimately has to do what it has to do. And so there can be a good, how do I put it? I suppose for one, it is easier to say what's bad, because making bad stuff is so much easier. Good websites. For all I care, the Gmail website works just fine for me. I wish putting labels was easier, but otherwise it's just fine, you know. What's your favorite font? Oh, like the same thing like I said, I mean, there is no, I can't have a favorite font that goes against everything that I work for. If I have a favorite font, then I use it everywhere and I design really bad documents. I can't afford to have a favorite font. If I have it, I can't afford to admit it. Have you come across any bad design? Bad, that's easier. IRCTC for instance. That's fun to use. So fun that I never travel on trains anymore. I think the improving now is it. The funniest thing I recently saw is now they have a store on which they sell clothes and books. I have no idea how that makes sense as user experience for IRCTC, but these are clothes and books and like bedsheets and stuff on IRCTC now. But yeah, so sort of, is there anything else or can I move forward? I think, you know, this framework, right? Now the gentleman there said that the information architecture and user experience is something which is a standard process. I'd like to highlight that as and when you acquire more users, you realize that some users are more critical than the others. So you have to constantly change these three, these four elements because they are bound to have different priorities in different life cycle of an app or life cycle of a product. And I think that's where it's critical because at that point of time, your organization is already used to doing things a particular way. And unless you have the flexibility to move these four elements, it'll be and understanding to move these four elements, it'll be a difficult exercise. That's a brilliant point. I mean, of course, I understand that information architecture and UX is something that obviously people do. I mean, that's why we have some brilliant websites and apps. But one must also understand that there is a more than one design process that works. So there might be people who would prefer something more formal and structured. There might be other people who prefer something which is more instinctive and more sort of organic. And I think it would be a complete shame if we thought only one process works and then completely disregarded sort of other processes because, you know, all sorts of different things work for the same thing. The second thing, of course, is that while it's been many years for digital design to be out there and for products to be made, very few people, I'm pretty certain in this room, have actually formally studied it. Because, for one, it's not taught formally too often or in too many places. So all of us have the challenge and the advantage of learning things as we go. Right? So I mean, how many people studied information architecture here? Like, studied it? Anyone? Did anyone like go to university and study it? Did anyone study like UX in college? One person? So yeah, I mean, while those things are really common, no one has actually learned how to use them. I don't know how to use them either. So, you know, all of us need to sort of develop ways of doing this better which, you know, work for us. So yeah, moving on. So what I thought would be an interesting thing to do is, you know, sort of take the structure that I briefly discussed and think about how that might help us design, let's say, a menu app. So when you're designing a menu app or when you're designing even a paper menu, you know that there is first sort of information about, you know, the restaurant and where it is and its phone number, address, email, so on. So that's one kind of information. And then mostly there is like a pretty simple division, right? There's food and there's drink. So that's one way of categorizing your data. Within food, it's possible that your food is divided into, you know, categories based on dietary preferences or something of that sort. Food could also be classified as, you know, different kinds of meals. And these are four, there could be more kinds of meals we could have in this. Can you guys think of any other ways in which food could be classified? Cuisine. What else? But this is bad and that is good. Spiciness, that would make sense. That would be cool, a menu which said in this restaurant all this stuff, bad, just don't eat it. So when I say that, you know, make hierarchies and structures, I don't mean make one kind of hierarchy and structure. I mean go out there and think of all the different ways in which you can possibly classify this. So you do that with food. Now let's say within this we go for dinner. So, you know, you could classify dinner in courses, for instance. What else could you classify dinner into? What else could you classify dinner into? Portion size. Anything else? Nutrition. Cuisine would probably be food, right? It would be a higher level, but yeah, nutrition. Light or heavy. Anything else? Sorry? Someone else was saying something. So yeah, something nutrition sort of based. So yeah, so those are all the ways in which you can do it. Then, so let's assume that now we're being the most intelligent we can ever be and we've come up with all the classifications. We realize that under any of these categories there's basically going to be a list of preparations, right? So that is going to have like, well, name, a description, a price, a dietary preference or restriction, then a whole lot of other things that you guys mentioned like nutrition, for instance. Is there anything else that could go in here along with in the chunk that's preparation? Sorry? Yeah, I mean, it could be the restaurants. I mean, it could say something like chef's special, for instance. So yeah, sure, so you know. So this is all still sort of hierarchical structures, right? There are different categories. Inside that there's going to be a preparation. A preparation is going to have X number of parts. Then there could be the kind of relationships which don't quite agree with the hierarchical structure, right? There could be some food with which this particular restaurant offers wine pairings. Or it could be a cheap restaurant and it could have like offers and discounts or something, right? But there could be all sorts of relationships which are not quite as direct as cuisine, Chinese, main course noodles. Or you know, it could say that if you buy noodles, we give you, I don't know, Manchurian free or something. So it can have like all these different things. There's also a sense of sequence. So you know, your menu might want to let people choose appetizers first. I mean, you don't want to go appetizer, dessert, mains, you know, side dish like that. So there is, in this case, a pretty clear sequence that the content must follow. And after that, there is the question of what has higher priority. And this is where like a lot of you mentioned, the user comes in. Now any menu is going to have all that information. But the moment you start to think about your user, you think about what is most useful for my user or what is it that my user demands and that automatically becomes your highest priority because you know, your job is to give the user what he or she wants. So now imagine this is a menu app for college kids. Chances are their highest priority is money, right? So then it's possible that your app starts off with first allowing them to choose how much money they have because that's the highest priority of your user. It's possible that you know, it is on the other hand a very, it's a rich crowd and they don't really care about how much the prices are. In fact, they don't care about the prices to an extent that, you know, they don't want it to be important whatsoever. So it could be an app which actually has the prices, but it has it in text instead of numbers. So the price is there, but it doesn't quite, you know, it just looks a little bit more posh. And maybe that's a priority for your users. It's possible that you're running a restaurant in India where people really care about whether their food has meat. So immediately you know that's a really high priority and that green dot and red dot is actually very, very important for your user. So after you organized and structured all your content, after you've established all the important relationships in your content, after you figured out what is the sequence or the best possible sequence in which the content must be shown, you think about what is the priority of the user, you set as a filter on your structured content and all of a sudden you are much better placed to think about how your app should work. So which is basically what I mean by design, by understanding. So yeah, that's that. What do you guys think? So you talked about how one must document the semantic relationships between different parts of your content. And so usually as you mentioned, when the person who's thought all of this up, when they'll go and leave, the bus factor is one for the person who's thought of this. So how do you document it? What do you think are the good ways of documenting it and keeping track of the semantic relationships so that it can be further grown as well as you define your priorities? Yeah, I mean if you're small enough and you're as technologically challenged as me, this is going to be something written down on paper but written out really clearly. It could be flow charts with lots of arrows. It really, I mean it doesn't matter how you document it. What is important is that you find a system which is correct for the scale at which you're working and correct for the kind of product that you're trying to build. Actually to answer his question, actually companies what they do, they have design documents. Like when you're designing your product, when UI is designed, you can say you have a heading, what will be the font size, font style, which element will go. So all these are documented when you design your product. He didn't mean documenting the design guidelines. He meant documenting the organization of the content. So documentation of the step before that. Yours is more like design guidelines, right? After the design decisions have been made. But before that. Yeah, hi. I probably should have asked this earlier. Oh, that's good. But basically you were talking about the four steps we should take before wire framing. That's structure, relationship. It's not so much steps, more like when you organize, keep these four parameters in mind. Yeah, so that's basically, I mean, that's what wire framing is about, right? These four things you spoke about. Mm-hmm. And I'm saying this is a step that needs to happen before wire framing. But that's what we think about in wire frames, like the structure and the hierarchy and you know the relationships and the continuity. I mean, that's, I didn't understand what. It's the same argument that we make for making wire frames, right? You see that you nail down functionality before you start applying visual embellishment. Right, that's the argument for why you should make a wire frame. Yeah, exactly. And it's the same argument for this. Think before you start making the wire frame as opposed to doing it while you're making it. Okay. It's exactly the same argument. Okay. We have 10 more minutes. Questions? And I can tell you guys how much fun it is to make fonts. Pooja, just maybe to clarify his question further, I was wondering if you could sort of just provide people maybe the steps a bit further, just from the start process through to sort of making the wire frames. Maybe go back to the previous question and maybe give him an example a little further. Okay, so for, I mean, let's go with the menu app for a moment, since we've discussed it. The way I would think of the design process is, you know, at some point you're gonna receive some sort of a brief which says, blah, blah, blah, wants you to design a menu app and so on. Then at some point you will get the actual menu. They'll send you all the content that has to go in. And that's when you'll start thinking about how the app should be, right? And after you've thought that, it's gonna be the step of making the actual wire frames. And thinking, and I'm saying that this step is a step that happens when you're thinking of what the app should be. Instead of just thinking on that level of what the app should be, first think about what your content is. Think about the content first, organize it, understand it. And once you've done that, how the app should be should actually be a natural step. Because once you understood the content and you know what is important in it and how it's organized, how to present it is going to be very, very clear. It's not something that, you know, you sort of have to invent out of thin air. It'll just be. And then of course you wire frame and then you iterate in all these processes and then ultimately add design and, whoo-hoo, release. Get some money. I have a two-part question. It's not really related to your talk, but since you're up there, I thought I'd ask anyway. Could you critically evaluate Android's typography? Second one is a bit of a, what are your thoughts on Android's typography in general? Especially the changes they made recently. Well, I have no idea about the recent changes, but. I mean, from 4.0 upwards, Roboto, et cetera. Right, okay. And the second one is, how does, in your opinion, typography, how can it adapt to devices with lower screen resolutions? Are there things that you can do specifically around that? Is there, yeah, is there a relationship between typography and, say, display resolution? So I'll answer your second question first. A couple of months ago, there was a conference in Amsterdam. It was primarily a type conference. And at that conference, Microsoft announced that they are coming up with a new sort of font for their platform, which will kind of replace Georgia. It's a font called Sitka. It's designed by the same gentleman who designed Georgia over a whole bunch of other typefaces. And that sort of puts into perspective the fact that, A, different platforms require different kinds of typefaces, because of simply what is the quality of detail they can show. So for instance, if you look at printed newspapers, and you look at the kind of printing quality they have, and then you look at a coffee table book and the printing quality that has, you know very clearly that a certain kind of fonts are simply not gonna work on the newspaper because they're very delicate looking, or they have tiny details, which the ink will smudge and you won't be able to see. So it works exactly the same way for devices and resolutions. That is to say that you know, I mean unless you're using a Nokia double one, double hundred, most screens are decent enough now that you can have something that doesn't look like a pixel font. But unless you're using like a retina screen, you can't really be using some brilliant, thin, calligraphic font either. So in that sense, yes, devices and what resolutions they have majorly constrain the kind of fonts we can use and that's something to be careful about. I think when we were doing Ex Libris for instance, I wanted to use SourceSense Pro Lite everywhere because it looks so beautiful, but it was not gonna look beautiful on half the Android phones because you know, the quality of the screens just wasn't up to scratch to be able to use something like that. And I'm sure I've looked at other apps which completely well-intentioned, completely good intentions, you know, use a really beautiful thin font. It sometimes craps out on even my phone and it's not one of the worst phones out there. Having said that, to go back to Rahul's first question about the state of typography on Android, it kind of sucks. There's just no better way to put it. There's a lot of really simple basic things that we've been able to do on CSS for very long that you can't do on it. It's not easy to adjust line heights or letter spacing. You can't have small caps. I don't think it allows you to use different kinds of numerals like, you know, the ones for tables and the ones which are not for tables, et cetera. So in that sense, yeah, it's not exactly ideal. And when Roboto came out, as happy as all the Android people were, the typeface designers thought it was awful. It basically looked like a Frankenstein's monster of a whole bunch of really good typefaces. It wasn't particularly well drawn and yeah, it's not very good. I don't know if one of you can fix it, but yeah, it needs some fixing. Who most certainly does. One last question. Hi, so I'm really fascinated by type, so I just wanted to ask you what your opinion is on this. So in the recent times, you know, with all the flat design and all coming into picture, I've noticed that like you said, you know, there's a high usage of thin fonts, right? So could you highlight some of the things, some of the probably overused things in type that, you know, everybody does or most of them do, but they don't really look good. They just do it because everybody else does it. Is there some set of practices like that that you think of? That's a very clever question. And I hate that I've already used the example of thin type because I can't think of another one, but I mean, really it's massively about trends, right? So if you've, I don't know, even remotely read about modernism and design or art or things like that, there was a time when people thought, you know, everything should be sans serif because that's right. Eh, not really. And you know, they just like used it all the time. And now we have understood that there is a time for this and there's a time for that. And that's true for pretty much all kinds of typefaces. You know, every now and then a new typeface will come out and it'll be really nice, but people will get obsessed with it and use it anywhere. I mean, Helvetica has been around for half a century. People are still obsessed with it for no good reason to be fair. Yeah, that's probably one thing. Not having enough contrast, making everything look too subtle. So eventually, no one can understand what it is. Yes. Okay, one more. I'll answer it super quickly. Now, like, now most of the corporate websites are designed or apps are designed like responsive web design, right? So in the RWD aspects, some of the people are using web fonts. So is it a right way to implement web fonts in the RWD apps or? Sure, I mean, for one, a lot of web fonts are designed to work, A, obviously better for the web, so they are better hinted, and B, because they are fonts made for different contexts, you know, they can be fonts which are narrower in width, which would be useful for mobiles, for instance. And you might be able to use a different style of the same font on the desktop or there's more space. So, yeah, I think that's a brilliant thing if people use it like, you know, intelligently. Thank you, Pooja. Thank you. So you can connect with the speaker. You can connect with the speaker offline for more questions. Thank you.