 Right now, I'm with HP. I have the front-end team here, so it's a group of designer development guys, people, so they have the skillsets of a designer as well as development, front-end development. So, this is something new we are trying here, you know, putting engineers into the design group and actually getting them to write front-end code. Usually, the standard process is to get engineers within engineering to write, right? So, the priorities of an engineer obviously is different. It's scalability, architecture, optimization and all that, but when you put them under the context of design, the priorities change. It's more how pixel-perfect can you make the design to be and all that. So, it's an experiment. We have tried it. I've tried this in past in Yahoo. It fairly worked out. If you look at the latest Yahoo mail-in calendar, that's where I learned this model of working and I have had the opportunity to work with some of the best guys in the industry, you know, guys like Jonathan Snooke who is a known guru of CSS and prototyping and all that. So, I learned some of the, you know, tricks of trade from them and now I've tried to improvise on top of it and try it here. That's great. That's exactly what we're trying to do at the conference because we deliberately didn't try to sort of polarize in one direction but we intended to understand how you build things and not just how you imagine and sort of put it on a paper or on a storyboard. But tell us what you're going to speak about. So, you know, in the context that I'm talking about right now, so it's, so when you're getting front-end engineers to think about design, think about pixel-perfect designs and all that, there's a lot of effort and there's a lot of change in your shift in thinking pattern that's happening, right? Now, traditionally there's a way user experience designers engage with engineering. The way is they design something and then they throw it over the wall to engineers and the engineers try to make some sense out of it and then they do something and then end result is a faculty monster, right? So, you know, we are trying a model where, you know, we, you know, kind of build a, you know, kind of a bridge between engineers and designers and that bridge takes care of a lot of, you know, design perfection and stuff like that. So, for that we use a bunch of new technologies and frameworks to get there. It's not just, you know, human beings, right? We need the infrastructure to support us get there. So, I think it's this bunch of frameworks and technologies. So, a lot of people have heard about it on the internet. I'm pretty sure a lot of people would have read about it on smashing magazine and all that but I've rarely seen people actually using it. So, for example, when I was trying to hire here, I spoke to like 200, 300 people in Bangalore and none of them had used any of these technologies. So, I thought, you know, this is one of the good forums to actually, you know, familiarize the community towards such frameworks and technologies and how to use them and get off effectively transition the whole prototyping mystery out there into a proper scientific front-end development process. Right. And will this be a lecture, a demo, a workshop? What format you have? I was thinking of a 80% lecture, 20% code kind of thing because I have always felt that, you know, if you do slides, people get it then, but then by the time they are out of the room, it's washed. Right. So, I often get mails back from other conferences where people go back and ask the same stuff that I have, you know, told, covered in the slides. So, I think a little bit of code would help. So, that's my plan. You know, like, you know, like a 80% slide deck model where I talk a little bit about process, you know, kind of familiarize people with to a little bit of technology, you know, the different frameworks and then actually take one example and, you know, kind of either walk through it through slides or, you know, walk through the code in an, you know, coding environment and show the results on screen. So, that's what I'm hoping to do. I've still not figured out which is the right way to do it, but that's, that's kind of what I'm doing. No, sure. It sounds good. I guess the question I have, I'm curious about is how you, when you hire people for your team, how do you kind of bring them up to speed with where the team is and how they do business as in how you manage what your process, the design process as well as engineering process for the team is, how do you bring them up? Right. So, one of the first things I have to fight out is here kind of, so I get two kinds of people, right? When I try to hire, since I'm part of this user experience studio, it attracts a lot of designers who are from either school of arts in ID, ID, IDZ from ID Kanpur, Mumbai. And then there's other bunch who, who are primarily engineers in some by education and they have spent the last three, four years doing front end work. And there is this group who are like completely back end guys. I mean, they don't really care about the presentation layer. They think about the controller, they think about the database and that's where they're comfortable. So these are three kinds of people I usually who apply to this job. And so the first step is to actually convince them, you know, that they are nice niche area. Because most guys who are in front end, I've seen that the HTML series of us, they're trying to transition to the front end. And if you talk to a bunch of designers, you'll find them trying to transition to front end work. So it's a very niche area, right? So you're ideally positioned between, you know, technology and creativity. I mean, this is the best place in the whole software industry you can be in, right? So it gives you the power of actually building something new, you can influence the product, and you can make it work. So you won't get that you're working very closely with product management. And you can actually shape the product. Back in engineering guys rarely get that chance to do. They can improvise, they can make it scalable, they can, you know, make make it work faster. But they can't make the user go off. Yeah, you know, I recently read this quote that the UI or the user experience is actually a product is that's what the user sees and uses. No matter what's happening in the background, and that's your engineering genius, it could be, but the user doesn't see and doesn't care. So do you kind of feel the totally totally that that's absolutely to see feature is a given, right? Without a feature, it's not a product like let's take the key that you have, for example, if it won't unlock a car, the key is useless. It's not a key, right? The feature is a given. But the question is, you have these kind of keys, and then you have the micro kind of keys where you just have to put the key in your pocket and press the button. So these are this is user experience, right? The feature unlocking the car has to happen. Without that, there's no product. But once you have the product, how do you differentiate between product X and product Y? If you take the example of MP3 players, this is what I, you know, obviously, you know, MP3 players have been there since the 90s, 94, 95, not of MP3 players have been there. But in the late 90s or early 2000s, Apple came with an iPod. Now, what was an iPod? It was just an MP3 player, but it redefined MP3 players, right? So that that that user experience what makes a product. So I totally agree with the idea. This has been great. Thank you so much.