 Good morning. It's a fairly empty hall, fairly full as well in clusters. I think people are sitting with their friends at this point of time. And welcome to Meta Refresh. And thanks Hasgeek for having this conference. And thanks for putting me up first on the stage so that we are able to see lots of sleepy faces. And I like, but I relate to you guys because I, I, how many of you think that you're like Yoda's? Has anyone felt like Yoda ever? Like every morning I do feel like Yoda. Right? So I always take these little more time to wake up. So let's just do a little bit of a warm up before you write. How many of you relate to being designers? We are going to do a round of this. Like starting the meme. How many of you relate to being designers? Right? So repeat after me. Who are we? Who are we? You have to make sure the people next to you are also waking up. Okay? Who are we? Right? And what do we want? You want more designers, but what do designers want? So designers say coffee, flexibility. Okay. I, if someone asked me this, how many, how many designers agree with this? How many designers agree with this? Absolutely. Some people. Okay. Those designers who agree with me say I do. Thanks. Let's start with the talk. My talk is on architecting content-driven websites. I am Sovik. I run a web design studio in Delhi. It's called Mirange. And we architect information and we design radically simple future-proof websites. That's the work that we do. And I want to start a little bit about setting the context of web. Like historically, web has always been a communication and a publishing medium. Right? We have always wanted to put up information on the web so that lots of people at scale can access it. And that has in turn led to what I would like to define as websites which are informational and content-driven. So much of the things that I'm going to talk about are going to be relevant if you're doing informational websites rather than transactional though it will be applicable very much on transactional things as well. But I'm going to stick to primarily informational websites. And what do I mean by these content-driven websites? It could be media publishing, knowledge banks, resources guides. You might have your organization website. You might have this event website that is trying to give a lot of information about, hey, what is MetaRefresh? What is it about? When is it? Where is it? How do I access? How do I buy tickets? So all that information being given out to you, it could even be your personal website. Right? Now, informational websites need to be designed keeping flexibility, scalability, and how long will it last in mind? And why do I say so? And the reason is simple because flexible because information can change. Right? And scalable because information keeps growing over time. And lasting because information is there to stay. And probably even 10 years down the line, even today, most of the resources that we are referring to for our day-to-day job on the web, there's a good chance they're written over a decade back. Okay. And if they were no longer there present for you to be accessible today, then you wouldn't be able to write your lines of HTML code as well. And the reason the entire context of thinking about architecting a website from a design point of view primarily goes back like three years back, we were doing the website for JS4. And at that point of time, we had done a few websites for events related to Hasgeek. And we had to, we were thinking that we need to come up with a good framework or a solid framework so that even websites can be made, new event websites can be made, and the information can be given following very simple frameworks and paradigms so that information can be swapped or even if information grows, the paradigm still sticks. The architecture still sticks and it goes on to be extended to other events that are going to come up in the future. And that's when we had started thinking of a paradigm or a process. And I'm going to talk about that a little later in the talk. I want to start off with what is how does the information website look at the start? And tell me if you agree with this. Has anyone worked on information websites which at the start looks like this when the information is presented to you? Not on the web interface, but when you actually look at the information where there are 20 different types of categorization of information, there are 20 different forms of content on the website. So in a typical portal, you might have a blog post or article, different kinds of opinions coming in or different forms of news coming in and things like that. And it's all like a mess initially when you're looking at it. And from the mess, if we actually put the same mess onto the web, who does it affect? So we need to know who it affects. And it affects first and foremost, the website users, right? And it affects because they can't find what they want. And findability is something that is more important or it proceeds at least usability, because what you can't find is what you can't use, right? If you can't get to the content that you're after, you won't be able to use it in the first place. There's a second set of people when we are designing that we often overlook completely. And that is what I'd call as content managers are people who are creating the content because they need to understand how they are going to create the content for the website that they're after. And when they don't understand it, they make things messier without even realizing that they're doing it on the website. And that is where there's this concept of information architecture that comes in. It is like a skeleton right at the beginning which will try to organize everything. And this is how it's defined. It's like the information architecture is the practice of deciding how to arrange parts of something to be understandable, right? And I'll move on to a diagram and there was a talk given by Abby Covert a couple of years back. And you can go to this link and there's an entire transcript of the talk. But more importantly, I want to just focus on this diagram that was there in that link. This diagram has been tracking as a simple way information has been getting really complex over time over centuries. It is no longer something that is a simple list, right? The relationship between information. It's not simple tables. They're getting interconnected more and more. And therefore it's getting more and more complex to manage. And as a result, IA is evolving how an information architecture is done is evolving. And it's more relevant than ever because come to think of it, we have always understood the architecture that we can process. Think of system file folders. It's like a hierarchical tree, right? You know, there's a top level. There are a few levels inside it. There are a few more levels inside it. And websites also thought of that. Oh, there's a home page. There'll be five sub pages. There'll be sub sub pages. And that's how it gets organized. But you know, the reality is not something like this. And today, if you start drawing lines and connecting information, how, how is this piece of content related to that, that piece of content related to this, it'll look like this. You will have external systems talking to your pieces of information. You will have it end up looking like this. How many of you have ever tried to interconnect content relations and seen such a messy diagram happening? Any, any show of hands? Would you agree with me? Okay, those who agree with me say I do. Thanks. So this is how it, it ends up. And when we say that we want to do an information architecture, we want to get away from such a mess. And this kind of things that there are just three things that we need to do. One is structure, organize and label the information properly. And what is structured content is something that we need to understand first because in, and this is a Wikipedia definition. It basically means information or content that is organized in a predictable way and is usually classified with metadata. So what do you do is you, if you say that X is a piece of information or a knowledge or say a blog post, you want to classify, break out all the metadata inside it. Say, Oh, this is the author. This is the date. This is the tax. These are the categories. And this is the heading of the post. This is the body of the post and so on and so forth. This is the conclusion of the summary of the post. So you want to break it down into a structured content. And what, yeah, so as I said, it's all you need to do is keep calm and break it down, break down any piece of content and information. And you're trying to make it, give it a more structured shape. And how do you start off? You start off by primarily talking extensively, like whoever you're building the, the, your website for whoever is the audience, as well as whoever is the creator of the content, talk extensively and put everything on the table that these are all the set of information we are talking about. And I'm going to take a very simple example in my talk. And let's, let's just look at a conference website for, for an example. If I, if I have to build a conference website today, the kind of questions that I have to ask are like, what, when, where, who, why, and you'll get, start getting answers like, Oh, it's an event on a certain subject on a certain date and times. And there are when you, there is, there is, there are speakers at NDS organizers who are responsible for it, for it, for the success of it. Why is this happening? And these things will keep coming and you might get all the words that come out and just throw it on the table. So you'll have things like even name date, when you speakers, organizers, attendees, topics, talks, schedule, sponsors, hotels, policies, we have a great code of contact for this conference and all other hazy conferences. So there'll be blog posts, local information, ticket information, and there are many more. I'm just taking a very small subset. Okay. And when we put everything on the table, there is a new paradigm of, we don't want to immediately classify or it in a hierarchy. A new paradigm is evolving over the last couple of years. This term has come up, which is called object oriented UX. What all it means is you're trying to organize this intentionally around real world objects so that people can understand these as things, as objects. And, and therefore you also can clearly define what kind of things make up the object, what kind of relationships behavior they have with this. And what we need to do with the things that are there on the table is we need to identify these objects. What are objects out of this? Questions like this have to come up. Like, is it real, real world thing? Is it a noun? What are the attributes will this have? Will it make, will it be made up of lots of something? Or will it be, will this object talk to that? Will this thing talk to that? Can they be grouped together? Is it chronological, spatial, tabular information? Does an alphabetical listing sense or should it be a database listing? Is there a hierarchy? How can it be archived? And finally, if to arrive at this answer, are these very good definitions? Do they fit these definitions of being an object in itself? So again, come back to this. We have this entire set of things on the table. And what we are starting is, so there's even name, date, venue, date in itself doesn't probably make an object, but surely some things are clearer. A speaker is a thing. A attendee is the living, moving thing. So I can always say, oh, you are an object or I am an object. Or, or the, the, a blog post you can say, oh, it's a very clear, very defined thing. So it can be an object and we can take it. But you have to sometimes group things together to make an object. So you can always say, oh, even name, date, venue, they combine to become the event itself. It's a meter around the event. So we can call even the, an object. Speakers, organizers, attendees are all humans, right? And then you can also break things up. So a schedule is probably something that combines rooms plus time slot plus what talk is happening where room time slot talk itself might be loosely classified as objects and, and a schedule is a combination of this forming a larger object. And sponsors can probably further be broken down in certain classifiers. They go, they're a platinum, gold, silver, silver things. And the next step that we need to do once we have organized these things is basically naming the object. Okay. And this is extremely important with, because you really can't call an object in the system humans, right? It will not be, it's not something that you can use to talk or even to represent and, and reach a common understanding. You'll probably want to rename that as person and this combination at the bottom, you'll probably want to rename it as a session. So a session is basically a room time slot and talk information combined becomes a session and that you can call this an object. A person is an object and so on and so forth. The next step that you'll want to do is you want to define the objects better, right? Now, when you say a person is an object, what does it mean? And again, when I say defining, this thing is going to come up a lot. You have to keep calm and break it down and repeat this over and over. So if I break up an organizer, if I break up an attendee, if I break up a speaker, it's going to boil down to an organizer. Probably you want to show in the website things like, what is the name, designation, bio, contact number. Attendee will probably just be a name, organization and designation. Speaker will probably have further details because you want to give more social contact information. Also probably feature a photo of the speaker, but for all attendees, it might not be necessary or possible. And once you break these things down, you want to probably chunk it together and form a more defined object like the person. And you say, oh, finally we have person as object, which is all the fields where only name and role is essential, and everything else is optional. And the role can be an organizer or attendee or a speaker. So this is the way you can probably chunk it and frame it as a solid object together for the system to understand, for everyone else to understand, oh, we have to create a person in the system or we have to retrieve the person's information from their system. And once you have these objects forming up, you need to organize them better. And how do you organize them is by primarily identifying relationships between them. So if you say a talk is an object and a person is an object, then you might have a connection between a person and a talk in terms of who's the speaker and that's the relationship in between. And this is like a relationship between two different forms of object, which where one is a talk, the other is a person, and you might have relationships between similar objects as well. So how is a talk related to another talk? So you'll come up with something like this, a speaker can be a list of persons. So for a talk object, you can have a related talks to what some talk is being talked about. So that is another relationship that gets established for that object. And you also see for the talk, I've put something as type and you'll always have things like, oh, this is a full talk, this is a workshop and so on and so forth. And traditionally, we always understand these as taxonomies or categorization of information. And here's the thing that I'm suggesting, treat taxonomies as an object itself. And what does it mean when I say treat a taxonomy or a categorization as an object, which means again, this again, break it down. So something like full talk, flash talk, workshops, you can create an object called, okay, this is a session type and it will have a name. The name is full talk or Christophe or flash talk. It will have a duration of full talk is probably for 14 minutes long. It will probably 15 minutes long. It'll have a format. You'll have number of speakers and more information associated with each of these individual types of talks that are there. So yeah, so these, what we understand traditionally as taxonomies or just, we have always been, oh, tag this or categorize this, break the category also into an object so that can completely be understood. The next thing that you want to do is probably review the entire thing. And once you review it, you look, oh, my system looks like this, but I never saw this before that a blog post will also have a relationship, which is like an authors, which is also a person and it may and the author may not attend the speaker, may not be one of the speakers or organizers or attendees at all. So there'll be new things that will keep coming up when you go and when you review the system. And you have to repeat it over and over until you have an aha moment that yes, I can understand the entire set of information that is there on the table. This entire thing can read into a very complex diagram. It's up to you how you want to represent it. But essentially it can be a finally a single list. It can be a flat list of things. It can be an index of things. It can be a daisy chain set of objects. There may be a strict hierarchy or something, a very multi-dimensional hierarchy and it can look like a very complex diagram, essentially. So I'm not going to complexity of the final diagram, but what we want as an outcome of this entire exercise is objects, collections and relationships in a very well-defined and labeled format. One note that I want to put in between is IA is not your navigation. When you look at a website navigation, you might think, oh, this is a structure, but that is not your navigation. Sure, your IA will inform the navigation. It will be a decision taken that how the navigation is through the IA and the structure that you have. But more importantly, a navigation is merely a window into the IA and it's based on completely user needs. You might have something which is deep in the level, but you want to expose that right up front in the navigation simply because users need to access that more frequently. Those kinds of considerations might come in. So we shouldn't confuse navigation with what is in commission architecture. I'll quickly run through this. Watch the role of the IA. It's primarily to focus on the structure of information and sometimes the design of the actual user interfaces, which is the wireframes. You want to understand how people actually use content and how the structure should function and support that. And to grasp the range of content and functionality on a project, how that needs to be structured. So the entire range of content you need to grasp that as well as a part of this. And once you've achieved all these three things together, what you have is a very robust mental model, and that's what we are after. A mental model that the user can understand, that the person who's creating the content that I can understand. As a designer, you can understand, you can talk on the same page. And the developers and people who are implementing the system can also understand. So it's like this blueprint that everyone understands and agrees upon through the length of the project. Through the length of the project, this might change. Things might get added or removed or altered, but you should have this blueprint in place. And I highly recommend you to read the eight principles of IA. There's this link for that. Just go ahead and read this. I want to jump to the next step once you have the IA. How do you capture the content? And traditionally, we have always used the system that we use to capture content is called a content management system to manage all the content that's there in the system. And here's a commit strip. And I really love this because it says, oh, uh, you know, 10 years ago when we wanted to make a website, we just took any old PHP CMS and we used to Google something like what's the best CMS of 2016 2006. And the answer was WordPress, Drupal and Jumla. Right. And the next step is, you know, when I typed best CMS of 2016, what came up, there's still WordPress, Drupal and Jumla. And can you imagine what is going to be the case in 2016? I don't think it can remain WordPress, Drupal and Jumla, because the information is getting so complex. And, and it's, it's, it's real because today if you look at the use of CMS is about 51% of the internet is built on WordPress. And it is so hard to believe this. But I know that there are reasons why this is true. And one of the biggest reason is developers are comfortable with WordPress. And it is an open source. It's there in the community. But from, really, from an information architecture paradigm, you're talking about posts and pages. And that is not the level of structure that exists today and going forward in the world. And that's why you need, there might be simple sites that can do with it, but more complex websites will need more complex CMSs. And when you're picking up a CMS that, what you need to just make sure is that you're able to capture and represent the entire IEA you have as accurately as possible, which means the entire content types, the models that you're talking about, the relationships that you're talking about, it should be represented in the system as accurately as possible. With the minimum amount of hacks that, oh, a post means this, but a post with this category means that. Should be that, that confusion should be as less in the system as possible. There should be a complete, don't repeat yourself philosophy that even you create a piece of content, and you don't have to create it again under, when you're creating a talk, you shouldn't have to go and create a speaker there, as well as create a speaker separately in the system. And, and you need to also embrace the create once published everywhere philosophy, which is you make the content once, but you can publish it in different ways and different forms everywhere on the website, as well as release it externally for the external system. Okay. And when you're talking about CMS, what we have to always do at that step is a step called data modeling and well, how is it different? How do you translate a content model into data models? And how are these two different? It's very simple. It's like content models is how a content is understood and used. And data models is how is the content stored in the system? They are two different things. And what this means is another round of keep calm and break it down. Right. So let's look at this. We have the event. That might be the name of the event, but on the data model, we might want to store the title as a string and the addition as a number. Right. When you have the date, we want to make sure that the data model is the day. The entire thing is the day by day and number. I mean day one of the event, day two of the event and things like that. And when does the day one start and end as a proper date time object in the system? And what do you need to do is you have to always separate semantics and style like this. Keep them away. You might represent the 12 13th of September as a presentation, but in the system, it should be stored as the day one starts at this time, ends at this time, the system day two starts at this time, ends at this time. So that programmatically, you can generate any combination. You can present it always as 12-13 September. You can also present in the schedule as day one, this day two, this at some other place and so on and so forth. What it also means is that you need to as much as possible move away from rich text, which is like, I'll give you a big box to create the content and just put in all the things in there because then it's not structured. Right. And you will not be able to reuse information in different ways throughout the system. Taking a look at once you've done these things, how do you present the content? And we have always imagined presentation of a content in terms of pages. Like as a web designers, when a client comes to us, hey, I need five pages designed, please, can you design five pages for me? And we have always scoped things in number of pages. And that's a problem because pages cloud information, you don't know how complex or simple a page is. How many objects does it have? You don't know how to scale pages without creating a mess out of it. It's a very big challenge. And pages, the thing, the manner to think as pages is turning obsolete these days. What we need is broken unit. I mean, our pages is a broken unit today. And we need to take a broken unit and break it down further, which basically means what we need is patterns based on a very solid design system, which will compose a page, essentially. There is a pattern lab based on atomic design principles or design system. You can just go and look up pattern lab. It's a very robust system that's there. But I'll come to a similar alternate system or a paradigm really, which can use the atomic design systems as well a little later. First, I want to also talk about discovering content because when you're presenting information, you need to make sure that the more information is also discoverable. Now, traditionally, we have always thought that how will content be discovered on our websites? Of course, we have the navigation. We always had this, let's give a navigation, which let's say for again, for an event website that what is they went about? When is it? What's the schedule? What are the responses? Talks and things, those things and people will discover content through that. That's what we have always been thinking. But as I've always been saying in this, we're moving away from that kind of a hierarchy. We are no longer in a hierarchical system anymore. What it means that we are moving away from deep drill downs one level after the other to like laterally hop from, oh, I'm seeing a talk. Let me see more about the speaker. Oh, I'm seeing a speaker. Let me see more about the sessions. He might be attending. Oh, I'm seeing some schedule. Let me go and see some other related content. What are the related talks with this thing? And that's how you are hopping and always discovering information today, which basically means that navigation is undergoing a fundamental evolution and we have completely not been able to solve that and reduce down to this, right? So this today in most websites is how navigation comes up. No longer a tool to discover content as well. And then we also had a home page, right? We have also seen a home page as a place where you come and discover all the things that are going on with the website. But you know what the reality is that too is going. People don't land up on the homepage anymore. People land on the internal page and keep going other ways. And I've seen like again, a design studio, design agency website completely drop homepage. Their website is simple. When you land on the page, what we traditionally call home page is about, you can see the projects that you have done. You can contact us for more projects, just three things. So when you are in a contact us or a contact or to hire them, you can see the other two things, which is you can see about the company or you can see what are the projects that they have done. There's no clear homepage anywhere in the website. And the concept of homepage is slowly going away. We need to understand that to different kinds of users, people who know what they're looking for on the system. So they are going to hunt for that. And many such people are going to start at Google and directly land on the content that you have. They've found what they're looking for. The other set of people are exploring the system. So what do you need to know that both set of people are really happy when they discover related or relevant content for them. So once they're at some place, they want to see related and things to go to the next thing, hop onto the next thing and learn more things. And how do we facilitate discovery? It's a very simple points have written over here that you make sure everything is addressable. Make sure there's a URL for every speaker, every talk, every session, everything on the system. There's a URL for that. And you make sure that you aggressively expose all the relationships. So if you're seeing a talk, you should have a link through which you can go and see the speaker and you can see all the other things that the speaker might be doing in the system. And you always show examples or teasers whenever there's intellect content is there, which basically means that you don't say just speakers. Say there's a list of related content. So it's not going to be simply link view related contents. You want to show three of them and see view more and give that teaser right there that they are. This is what you're signing up for. If you go through this link and want to discover more content. So by putting in these small things, you put it together. And what we need eventually is a design system and be able to identify design patterns. And I'm going to talk about this. What is a design pattern and primarily it's derived out of two different things. One of them is purely stylistic. It's like the, what's the color? What's the text size? How will a box of text be shown? The other set of things is the different ways and forms an object is represented on your website. So what are the different ways a speaker can be shown on the website? The same speaker object or the different ways in which a talk can be shown on the website. How will a talk appear inside a schedule, but the same talk, how does it happen on its own page? And these are the patterns that needs to come out. And I think every pattern should be reusable across the system. At the pattern level, it should be recursive. That means you should be able to show a talk within another talk. You should be able to show a speaker within another talk. So a recursive application of the pattern should be possible. And it should be responsive at the post pattern levels. And you make it responsive at those pattern levels, then the entire website will automatically be responsive at the larger level. So here's a simple paradigm. So let's look at what are the different, there are three ways in which broadly we want to represent an object or a collection. This is how is that object presented on its own URL? The other way is how is that object presented inside a collection? So if I have a list of speakers, how will one speaker look there? If I have a page for a speaker, how will the speaker look there? And if I have to present it as an association to another object as a relationship, that means a talk has this speaker. This speaker is delivering this talk. Then how is that association represented? And with this, we have come up with these are the kind of patterns that you need to come up with. And it's as simple as that. How do I represent the object in its own page? And that's a pattern that you create. The other is, how does the same object appear inside another pattern, which I said as recursive use of the thing? The next is, how is a collection represented? And now a collection can be, can be object agnostic. It can be a collection of a speaker and a talk and a post. It can be a collection of three speakers. How are they represented? It can be things like stack one below the other or put it as cards one beside the other. And that's the paradigm that you bring in as how to represent a collection in the system. The next thing is how do I represent a collection of collections? So what if one of the items in a collection is another collection itself? How do you give a teaser of that? So that is another pattern. The third and the next one is that how is an object represented in a collection? So if I have a list of speakers, how will the speaker itself be shown there? And there's one more thing, which is how is a collection represented inside an object? So if a talk has multiple speakers, that means a collection of speakers have to be associated with our talk. How is that a paradigm also? So these are the six things. If you are able to solve it, you have a very scalable system visually as well. And make sure you give labels to all of these views internally at our work. We call these things as the object on its objects page is going to be called the detail view. And we call it embed when there's an object inside another. So it's like, oh, embed a speaker into the talk page or embed the talk into the speakers page, right? The other is we call it a list when you have to show a list of speakers or a list of talks and things like that. We call it a teaser when inside a collection, one thing has to come out. So if you're seeing a schedule, which is a list of talks, you want to give just a teaser of the talks over there and not the entire talk details, right? So we call that thing as a teaser view. So give names to these things so that you can communicate effectively and create templates and patterns accordingly. All right. The other two things to make it scalable is anticipate empty attributes as well as which basically means if you have a speaker and you may have the photo as well as the first and last time designation organization, make sure that your template works. Even if the bio goes away, the organization goes away. The photo goes away. The template should still work. So make these things as optional. And the other thing is have very graceful fallback templates, which can be traditionally opposed to a page page as we traditionally understand it so that if a new object comes up, then it can still be represented in the teaser by just showing the title or something like that have these fallbacks in place. Finally, a page is the collection of these patterns put together, then that becomes a page and not as a whole. So this entire paradigm is simple, pretty scalable. But there's one more problem. Content managers and authors want flexibility, right? We want, like as a person who's creating an article or a post, they'll want, I want to make sure that the page looks like this and works like this. And you know, what's the problem? This and that's when we again come and know we will keep the control of how you want to show these things on the page and we won't let you do it. And how do we balance these two things? And this, this authoring flexibility and the way we are going to show things, this needs to be balanced at some point of time. And balancing this means again, keep calm and break it down. And how do you break these down is make sure that the authoring happens in chunks and not blocks, make it granular, make it small, cut things into pieces, don't let them compose the entire post, break it down into smaller pieces so that you can control how visually they'll be represented, as well as they can and extend some of this control to them. So one of them is expose the content types, which is make sure that they are creating a person as a person in the system rather than a page in the system. You expose those details. So you take metadata separately, you can capture them separately. The other things while capturing is also expose some of the visual patterns and make a compartmentalized styles and expose that to them so that they can use switch between patterns if they want to switch. And here's one example. So this is again something that we had done two years back. And I'll just run through this page. Is it for a design studio? And this is a case study of what worked there, a project. There's some metadata. There's a full video there that goes to see. There's a two column background of what gets shown. There's a challenge. There's a pull code that spans across the entire page. There's some bullet points that again spans across the entire page. There's an image that spans across the entire page. There is a two column piece of text, then three columns of videos. Then there's a big ass video right in the center. Again comes down to again two columns, a single big image comes in. There's a two column text where one text is bigger than the other. There are three columns with one icon there, one piece of image. And that's the three of them repeated. And there are two columns of images as well as some text over here, some dark background text, some related resources being pointed out, some related projects. And this is what I call as a teaser, which a related project will show some metadata. This is a case study. There is who is the client? What is the project like? There's an imagery which makes it look attractive rather than simply say click here to see related projects and things like that. So how do we make sure that people author this well? And just to highlight on this a little bit more, what we make sure is you capture very small pieces of content. You ask them to put in the body of text. You can let them choose what you want, large, small or big fonts or what you want, multiple columns, and you let them stack one below the other, these contents. And for every piece that gets added to the stack, you ask them, do you want to add a one column content above it, a two column content, a three column content or a pull quote above it? And like this, at the authoring level, they can compose this stack by stack in small chunks and the entire page renders out as a one piece of content, giving them some control over when they want a two column, they want a one column, when they want a big piece of text, when they want a small piece of text, whether they want a pull quote at certain points of time and do they want to switch certain things here and there? It gives them some control over this entire thing. And that's what gives us a very tight visual guideline as well as some flexibility extended to the authors to be able to come up with multiple case study pages. Some have videos, some don't have, some have three videos, some have multiple pull quotes and et cetera, et cetera. And so the same form of content can be represented differently, giving some control to the authors. So IA is presentation agnostic that way. Once you've created a very solid IA, information can be truly a very living thing, right? And everything like, for example, JS Food 2016, like the one that just happened, might be represented like this in the system at some point of time. It's like, oh, 15 to 16 September, MLR Convention Center, JP Naga, JavaScript conference in Bangalore. But you don't store this in the system as 15 to 16 September, you have the proper dates. You don't store this in the system as just conventions in JP Naga, you have the location coordinates. And therefore now you can make content living. So today you show it like this. And then you realize, hey, there's someone from outside India who's seeing it, you can change the location to it's in Bangalore, India, because no one cares where MLR convention center is. You can switch it to Bangalore, India, if you know that the person is viewing it from some other country, if you know that the person is viewing from the Bay Area, Seattle, you can drop Bangalore. They'll just say, oh, India must be Bangalore. They'll probably recognize that. Anyways, then if there's someone from Bangalore, you might want to show number Bangalore. Or I should have made it number Bangalore. Anyways, and then if there is someone from MG Road, you might want to change it to it's just 10 kilometers away from you, right? If the date of the event is coming close, you can change it to a two days to go. And if you, if the person from where you are sourcing the information has a great information architecture, that person might be able to tell you that it's from MG Road or say Silk Board. And if the person is in Silk Board, you can directly see, say, well, see you later in the next year. You're not making it this year, right? So you can make it living that way. Well, that's where information is. Everything I've told you is comes in from a solid information architecture background. And we need, we have a very solid mental model. That's what we want. The information architecture is like a bridge between design and implementation, so that we are all talking about the same thing. And a good IA is robust, extensible. It can get your system talking to other systems and vice versa makes information findable, understandable, living as I talked about, powerful, timeless, so that it can just stay on, take on different forms of content, future friendly. All you need is basically a free mind to approach an information architecture. And well, that's all. Thanks. Questions? So the section where you mentioned that, say a speaker's bio is there, like his photograph, his name, his designation, some other details around that. And you mentioned a great point that okay, either of these can be taken out. And still they can live standalone on the page. That definitely is a great point. But what I usually observe with like an editorial driven websites or content websites is that they don't exist on their own. They are in a part of the collection, which are the, your next slide, like a piece of jigs opposite. So what are like, you know, usual strategies that you will suggest when you have content, which is tightly intermingled with some other sections of the page. Okay. When you're doing a pattern driven design and development, what you'll realize is the strategy that I suggested, think of something as an object. How do I represent that in different forms? And how can, and when I said a collection, which is what you're talking about, that it doesn't exist on its own. There are other things around it. How does that collection paradigm work? You have to make sure that the way in which you show collections, that is either one below the other or one beside the other and things like that, does not break even if the content is gets optional. So separate these two things out. How does, how do two content, how are two content or 10 different content shown one beside the other has to be separate from how does the content look within itself? So if the content that looks within itself doesn't have the image, doesn't have that thing, your paradigm of collection still should work. So just separate those two things out. Okay. Thanks. So when you say navigation is not information architecture and it's not necessarily findability. In your own experience, how much do you find content managers getting this point? Most of the things that I'm talking about, in my experience, I don't get, I don't have content managers getting the points, which is why I'm talking about it. I want you all to make sure that people under, people who don't, who are purely focused on creating the content, understand why we are saying these things and then don't demand a Microsoft word like experience where you can write a line, something, and you can add photos wherever you want, however you want, and they don't have to go through, go through and honor a content model, essentially. This paradigm, the fact that navigation is no longer information is not an information architecture, I think is understood by people. But the fact that navigation or the homepage is not something that like about most people like 50 to 60 percent people don't even enter your website through a homepage today. And the fact that from whichever page they enter, every page becomes a homepage for them to discover content for the other parts of the system. While content managers understand that, they still put the homepage right up there at the level. Oh no, that's the entry door to our website, which no longer is the reality. So those are the things where I feel content managers are yet to understand that well. And purely from a navigation perspective, I think that is okay. They understand that the navigation can be simple, has to be simple. But it may not always translate to the fact that what is the advantages of a simple navigation versus a complex navigation? That's something that we have to talk to them a lot to make them understand that. Hi, great talk. Thanks. Yeah, hi. So it works. The things that I mentioned work well when the user is the traffic is mostly first user where he doesn't need to know what was the previous one. But consider a situation like Netflix type of content where users come repeatedly. So how do you communicate this change in information architecture effectively to the user and make not make him lost in the new design? Okay, as I said, first, information architecture stays the same. No matter, it doesn't change when the user context changes. As a matter of fact, information architecture cannot be perceived by people on the website right at the beginning on the first screen or even on the 10th screen. The thing that comes closest to explaining the information architecture of our system is probably a site map if you have created one. And if you want to give that to Google and things like that, that's and but that's an extremely complex piece of thing. And so users don't get it. So information architecture stays the same. The things or the philosophies that you follow what changes in this case is how is a object represented or how is a collection represented that will have many forms. A same object can be represented differently for different users. And therefore you'll need two different templates. Sometimes use the repeat user template to render an object and sometimes use a new fresh user template to render an object. And within that you would and a page level IA when you do that page level IA is something that can be different for different audiences. So when you come create a homepage or a dashboard page as an example over there, the objects that make up the collection or the list of videos or the list of information that you want to show will be very highly contextual and relevant and different for different users. So you might have to employ two different collection or two different object templates and split them into break it down, break it down and break it down further. But the core information architecture doesn't change. How many slides did you have? About 160. Okay, that's all the question was. Yeah, hi. So I want to know how we can make it really easy for content managers to change content quickly on the site. Okay, and just going back to your slide about this admin interface where you add one column or two columns and so on. Have you experimented with a more direct editing interface where for example, if I'm a content manager, I go to a site and I click on a section I hit edit right there and I edit in line. So I just want to know if you're experimenting with that. The admin interface that I showed a disclaimer here, the admin interface that I showed is not something that I built. As a part of when we are doing web design, we are mostly working on what the public facing side of the website looks like. We reuse a CMS and therefore we are restricted to the admin interfaces and the capabilities of the CMS. This was a CMS called Kraft that we had used and we are restricted to the admin capabilities of that and that's what you have seen there. Now, if we are to theoretically design an authoring interface, at that point of time, you can always have, you can always go, these are the multiple approaches that you can follow where there is the main content is there. You see a section click on there and that started hitting over there. That's a perfectly valid paradigm as long as the pattern cannot change. If the pattern can change, that means that at the point where you're editing the content right there, you want that out and want to put in a two column image over there. How do you bring that in? And that's what this thing solves in a way in which it slices into sections along from page into sections and you can insert a section between two sections and choose. I want a two column, three column, four column or something like that. And that too, we had architected. How does a person choose that? This system gives a very generic. So I'm not saying that the interface that is there is the most usable interface, but it's within the constraints of the system. We have tried to give out the options to the content authors. You have the capability now to choose between some font, some columns, as well as whether you want to pull code or not and things like that. That's all. Okay. Thanks a lot here.