 All right, good morning. Good morning, guys. Early morning in Bangalore, trying to figure out traffic and stuff. Too scattered, but that's all right. Thank you, Zainab, for the introduction. And pleasure to be here this morning. Today's the talk is a front-end architect's diary building, rebuilding a website called FreeCharge.in. And that's a company that I work for. Before I start, how many of you have heard about FreeCharge? How many of us have used it? Good, so before I get started, I just wanted to set a small little context in terms of what I'm trying to do in the next 35 odd minutes over here. So this session is actually a very hard-to-hard conversation about what I and my team went through in rebuilding FreeCharge.in as an application from what it used to be to what it is today. So what this session is really not as to how we change the world by applying crazy front engineering technologies to build something which nobody else has built. This session is not about that. This session is also not about how we have solved all the problems that any front-end engineering team will have to solve. This is more of a dialogue, more of an honest confession of what really went into building a website like FreeCharge.in. It's a startup. It's a small company. It needs to do certain things at a certain pace in time. So this is sharing mine and my team's experience in what went into building FreeCharge.in from what it used to be to what it is today. So let's get started. And I'm just going to wait for the people that are getting in to settle down for what a minute or so. So till people settle down, my name is Harish. I sort of take care of UX in front-end at FreeCharge. Most of the work is done by my team. I tend to bring coffee and help them out to do what is needed for the company. And I also play music with a bank of Agam. And like Zainab says, I'm a very nice guy overall. And before this, I did some front-end geekery at Minzra.com. And before that, I spent a whole lot of time in Adobe doing a whole bunch of things, the last one being web and open standards evangelists across doing general web and open standards goodness. That's what I was doing before this. All right. Can you read this at the back? Is it clear? The text is clear? Sure. So I just want to start by sharing a couple of thoughts very quickly. If there was one right way of building a front-end system, then you actually need just one guy and just replicate his work. And most of us can actually go find other modes of employment. So there is no one right way of doing front-end engineering. So that also sets context in terms of, that's also my defense. So I chose to do it one way, but that doesn't mean that's the only way. But that also doesn't mean that it is a very debatable topic in terms of how a system should be engineered or architected. That's the first point that I wanted to make before I get started. And the next one being, there's a code of conduct. So please read it. So if you actually know, once we have set these two contexts, I think we are ready to get rolling. So let's see. So I'm going to get started by speaking a little bit about the free charge world, the world that I am in, the world that my colleagues are in, the product that we're trying to build. So free charge, as we all know, is a website that helps you expedite or do your utility payments, your recharge bills, your DTH bills, your postpaid bills, and so on and so forth, and do it pretty quickly and more reliably. That's our world. But having said that, it's a very, very polyglot, amazing world. So the typical free charge customer is somebody that we all need to understand and kind of move forward. I'm just going to pause again and let these guys settle down. OK, guys, let's look at the typical free charge customer. So let's look at the exhibit A. That is the category one. You can't read that blue too well. It is the typical youngistan, oh yes, a B generation of our country who are always short on balance and significantly short on patience. And that is how they typically write back to you. Can you read that? So that's how they are. That's our first category of users that a product like us that needs to cater to and kind of support. The second category is the larger majority in cities and small towns, which is the working women, men, and the awesome people who pretty much have a lot of things, computers, iPads, tablets. I don't know. So they are looking for speed, a very good experience, and generally awesome. They look for things that are awesome and things that really work and just get their work done. The third category, which is the most common category, is what the typical common person who is eternally skeptical about spending money online. He would actually, while pulling out 10 rupees from his wallet, he would actually lose 5 rupee coin on the ground, and he'll forget to pick that up. But the same 5 rupee, if I ask him to spend on my website, he will not. He'll say, nahi chuna laga diga. So that is the main larger subset of people that we are dealing with in a business like us. So even if that money costs less than a cigarette or a chai, they will be very, very skeptical to spend their money. And we have some other generally awesome categories of people that could prospectively use our product like. So yeah. And what's also important is the choices that they make. Like you don't know what their product usage or design choices are. So you want people that actually want this, and people that are actually having this. So this is why building a front end system, architecting or designing a front end system for a product like free charge becomes an extremely difficult problem, because there is no one right way of doing this because you have all sorts of people, literally all sorts of people recharging their phones or doing utility payments. So that is the challenge that we are attempting to solve as we move forward. So for the tech geek, it's like, you know, like your own version of WebKit or your own version of Chromium versus somebody who just says IE6 just works. And I will just continue using that. So both of them are very valid pertinent choices. How much ever we frown on somebody's choice of what runtime he wants to use, the world is really like that. You cannot really force people to one way or the other, right? So clearly one size does not fit all our users. So which also means we have to now prioritize on the user's success, the speed and the ease of use. So what that uses is the very, very simple three points. And if you speak to any product that gets built, they all, after all the ceremonious intro will come back to this point or a variant of this. Everybody has to focus on these three points and we are no different. And from there, I'm gonna start jumping into a little bit of what went into building. So when we started rebuilding FreeCharger IIN, we have to look at what we had before. So what we had was a classic old website which really, really worked. We were servicing a whole lot of transactions a day. But it was built on Java stack. It didn't have a whole lot of front-end goodness or front-end engineering that went into it. It was a typical HTML website that was driven by a Java back-end, HTML gets back from the back-end and gets stuff. So where we wanted to go was to build a service that's driven single-page application which is fast, snappy, no nonsense and it should sort of work and feel like this. So considering that is our aspiration, it's very important to now start looking at three main parameters. One is, well, we have decided to become a front-end heavy company. We're gonna actually go and do all this magical front-end stuff and then build a great product. But then look back, oh, we have three engineers and two months to ship. So which is my world. I don't have, we don't have 10, 20 people that we are deploying to work for months to get this product. So making a technology-staffed decision is also driven not only by what technologies are available but what is it that we can adopt and what is it that we can reliably adopt and use. So it's a constant battle that we fought to figure out what, what is it that we want to do? So the questions are like, oh, you hired a guy that is not using backbone here? Well, he must be one of those guys. So this is the typical world, right? There's enough support for backbone, there's enough support for Angular or probably, there are tons of other frameworks that's coming forward but the larger question for a person like me have to answer with my team is, well, all that is there but is that what we will be able to use? Is that what we will be able to put forward to build our system? So we ended up doing our front-end stack by hand-rolling stack which does not create technology lock-in. So this is something which people from smaller agile companies would really understand. So it's very important to keep your technology stack a little agnostic to any specific platform. Even if you speak about backbone or Angular, see I came from Adobe. So before I, so I would clearly know what lock-in would mean and what that would call. So I was working on Flex and what Flex typically created was a whole bunch of developers that just knew how to build on Flex. So the moment that technology papered down a whole lot of people didn't know how to program because they didn't know the stack. So for a company of our size, we were very, very particular that we create as much stack agnostic programming structures as possible where if we have new entities, new bodies coming to the system, they'll be able to pick it up and start running with it. So for that, this is our first component. So we are using a framework called tapes.js. Stapes is relatively new. I would say a fairly new library. I don't even know if there are a whole lot of applications that is running on tapes, but then now we are running on tapes. It's a fairly supremely lightweight, very known on-sense MVC container. It's 2KB minified in G-SIT and what it gives you is MVC custom events and classes and it is beautiful in a way that it's got a very, very low learning curve. You actually work with jQuery and if you actually work with classic JavaScript, it hardly takes your time to ramp up and understand how to build a very simple application and get started on state. So the reason why we did that was that whenever we actually acquire new people into our team, whenever we actually have more and more people working on a project, we wanted to create a base stack that does not require people to be sent to trainings or sent to ramp up and all that would mean is we have a lot of traditional engineers who are not your front-end engineers. These are people that code in PHP, people that program in Java and they don't necessarily have a whole lot of understanding or appreciation of the cutting edge front-end and not do they really care whether something is moving the needle or not. So it is important to build a framework or choose a framework that allows them to very quickly jump in and add features and don't necessarily rely on the three or four front-ends. It's a true front-end engineers in a company. So a whole bunch of people work on front-end at free charge, not just the front-end engineers, the people who are actually writing some of the code functionality who still can't do the front-end. So this was a choice that we made and of course re-charge utility payment application would typically mean you have tons of form and tons of validation, literally tons of them. So a sun-direct DTH starts with a one and has nine characters and won't accept numbers between X and Y, between a certain period in time for the matter. You have postpaid numbers that will allow decimal points that don't allow decimal points and you have all sorts of crazy matrices of validation that you have to write. So the choice really is between, okay, let's write a validation or the choice is to go and choose a library that would do it for you. So we ended up choosing falsely.js. Anybody who's used falsely, okay, just one person. You should actually check this library out. It's pretty nice. So it actually pretty much does everything that an average internet application validation scheme would require and it has got some really, really good API support to write your custom validation and kind of make them into your code and it kind of just works really, really well. So, and it's not a very, very big library. It is not small either, but it's a very nice library to look at. So just circling back, so we have tapes as our backbone, like our MVC, our classes, the whole control and the model layer is actually written in this. Our validations are actually triggered by falsely.js. Templates are red and butter. So we are on moustache.js. No specific reason as to why moustache, but then moustache is worth for us, but there are tons of other templating libraries that you could possibly look at when you're building a system. So moustache is what we are using and there's a jQuery adapter on top of moustache, which kind of plays really nice with jQuery. And of course Bootstrap. So Bootstrap powers, free charges, layouts, UI and all the visual components. And we started out with Bootstrap 2.3 and soon we moved to Bootstrap 3 and most of our, pretty much, almost all our UI on, what do you see, on free transfer runs on Bootstrap. So question time. Anybody here who has built a full responsive website, I want, has to go up. Yeah, I know. So I'm not gonna ask you. And so what was it like? Can somebody very quickly tell me what was it like? Was it fun? All the hands that went up kind of went down. I'm gonna ask, have you built a full responsive website if you have? Was it fun? Yes, sir. Was it fun doing it? Sometimes it was a pain as well. And it had its own pain in the, in certain anatomical reference is what he says. So he says it was fun, but it was also difficult. Somebody else, I'm just trying to understand. And also for me to gather in terms of what it really meant, who else put their hand up? Here, gentleman here. So you are mobile first, and you have to understand and the whole lot. But then, full responsive is totally awesome. See, a whole bunch of people in this room will surely say, like, I've been reading about it, and full responsive is the thing. I agree, should totally do it. Actually, should we do it? So this is exactly where we were and we are. I mean, actually, a part of my brain says that, like, you know, everybody is doing full responsive, and I've been reading, we've been reading full responsive is the thing to do. So we said, we're not sure. So let us actually go the full distance. So we sat down and said, okay, stop all this. We are gonna take the website, full responsive. It should work on all conceivable screen sizes, and it should just work really, really well. So we spent quite a bit of time actually making our site go full responsive. And we just realized that there are a whole lot of people who are on 2G networks in our country, at least our customers, a whole bunch of people who recharge are very, very quickly out of balance. I mean, I don't know who can resonate with this. People are what's happening like nuts, right? People are, like, estimating like crazy. It depends upon what age group and what category of user that you belong, but people are always, always running out of balance. And when people run out of balance, they try to open the website on the closest possible device, like it is their mobile phone. They just want to add more balance, so they want to add more data, bytes into there. So building a full responsive website, the way we built it ended up being a completely sluggish, sloppy, just does not work website on mobile devices. And it totally did not work, it was embarrassingly bad. So we just realized that the battles are sometimes as small as connectivity and sometimes much more complex as to, I don't understand how to use this. And I am sort of used to using a mobile website in a certain way and the responsive website that we built probably did not make the cut in terms of whether that, and this is in all honesty. We tried, but then that's what we realized. And when we realized that we quickly decided to, what, if you're building an M dot site, you should be an idiot, right? Yes, no? Give some opinion, man, Bangalore is known to be an opinionated place. How many of us are building an M dot site for your respective companies? Do you have a something.com slash M? Dude, it has to be one of the two. You don't have a responsive website. You don't have an M dot site. That means you don't have a mobile website. That's what it typically means. So if I'm just guessing the rest of you have some sort of a mobile website that works on the smaller screen. But apparently they are very old school and uncool and it is hard for you to keep your job if you're actually building, that it actually screws your resume. So in your previous job, you actually built an M dot site and didn't go full responsive. So damn, that's not good. But then sometimes you have to step back and see what's right for your customer and not necessarily what is right for the front engineering team. This is a difficult, this was a difficult battle for me to internally fight and also for my team because we want to do something but the customer needs something entirely different. So it is very important to kind of step back, take a deep breath and say, build what the customer really needs. And that's not like a good idea. And we looked at solving the most common problems for the customer using a desktop web browser. So I'm gonna skip through. I was flying to show a demo over here but then some really good stuff happened yesterday night when Rajesh and I were sitting in the free charge office yesterday night. So I'm gonna skip this demo towards the end. So I'm just gonna skip through and move forward. Customers use all kinds of browsers, all kinds of browsers, it's crazy. I mean, when you just open some sort of an analytics tools and just do a slice and dice across the browsers that people are using, you will be very, very wildly surprised at the sheer cross-section of browsers that your customers tend to use. NB has experienced building for all browsers. Somebody who has actually killed the problem. I just wanna see how. Anybody who was in this room solved the quintessential browser problem? Anyone? I is six onwards and all the way out to Chrome. Anybody know? So, but then I, I don't know, man. I think we totally need to support all of them because that's what the business tells you. Because if you don't support one browser, it's X number of transactions on a small company or a company that's trying to build the business moving forward, losing even one transaction is potentially not a good idea. But then, honestly speaking, in the years that I've spent building front-end products, I quite don't know how to build for all browsers. This is why I asked that question. I just do not know how that is done. I mean, I'm being confessional here. So we asked that question back to us by saying, what? And started to take some really, really hard calls and this is important to kind of convey to you guys because companies of our size, people who are actually bootstrapping new products, this becomes your hardest battle to fight because your multiple stakeholders working and pushing you to make decisions that will actually support and help the business. But then some of these are significantly, significantly hard calls. So, we said this. IE8 plus only and we just looked at the funnel and said that makes sense. So again, let's take a quick step back and see, so what does this leave us with? So our desktop website will run only IE8 and above and of course, your Firefox's content suffices of the world, which is fairly easy to engineer, by the way, compared to IE8 minus. So what does this really mean? So if we had gone full responsive, what we are typically saying is we will not have a website that will run on IE7 or lesser. See, while that is a very, very good call to take, it typically means people that are using those browsers are not gonna be. And that's where we took a step back and said, running an m.freecharge.in website, freecharge.in slash m was a good idea because it was built on a bare minimum HTML, JavaScript only tech stack where it pretty much runs reliably across all these unsupported browsers. So the reason why I'm stating this is because sometimes we get a little carried away in terms of what tech stack or what kind of front part that we want to build. But it's very important to take those periodic intercepts to understand that maybe building it top of the line might not necessarily solve your business problems. Sometimes keeping those checkpoints and understand that keep a certain thing as is and move one of your project needles forward which actually help you build a more rounded product that will kind of work for everyone and experiences ranging from not so good to good but you won't have like a terribad experience for any user. So that is the core point that we're trying to thrive in. Now some very interesting anecdotes. So I want to, we are very awesome, like we are free charge. So I mean, sometimes I just take the liberty of saying, I mean, the most awesome people that I have seen are pretty much concentrated and free charge. That's a very modest statement to make. So by that logic, what do we build and what do we have kind of engineered should perform awesome. So by virtue of us being awesome, stuff has to perform awesome. And this happened. The performance, sorry, performance sucked pretty bad the first time we put it out. It was slow. It was not doing anything that we wanted to do but we were like in denial, almost all front end projects go through this denial phase. We're saying, yeah, most of this best practices have been kept in mind. They have already made sure that we are not writing junk code but then the experience that we had in this project was that come what may, whatever you do, your first ever iteration that you're gonna put out is actually going to be, I don't know, it's gonna be pretty suboptimal. I mean, sometimes you do pull stuff that is fairly good but in our case, no, we weren't doing any good with our runtime performance the first time that we put it out. And the reasons where the first one, the first and most critical one we identified was we had shit loads of templates. And in the hurry of shipping and writing features, what we did is we just went on an overload of creating templates. Just to understand how many of us are actually doing some serious template based work on handlebars, mustache, knockouts, anyone in the room? So how many of us know what templates are before I even move forward? How many of us do not know what templates are? Let me just ask that question. Come on, guys, this will help me. There are a whole lot of people who, okay, so templates are actually code snippets that you can reuse in your HTML layout. So basically if you have a component that gets, gets rendered in runtime, in olden days we used to write JavaScript code that concatenates HTML tags and then do a finally a document or write kind of a notion. But templates actually allow you to render data via layout elements via our program. So basically this talk is necessarily not about templates, but if people are interested in knowing what this is, I will very humbly request you to take a look at some of those templating languages like mustache and knockout. So for want of time I'm not gonna run. So that would also mean a lot of us wouldn't know what partials are. So, but I'm just gonna say it again for the people that know. So writing partials is very, very critical to keep your overall template sizes really small. So if you actually know a piece of HTML markup can be reused, please, please go ahead and write them as partials. This is something that we learned the hard way because we just went to engineering and we were not really looking at what was happening to our code in the appropriate time. So we moved some performance needle by doing this then we didn't put any dependency management, none. We went that classic old school like start linking your JavaScript in your main HTML right at the bottom, one after the other, absolutely no dependency management. This is how we will, I'm not ashamed about this. We all knew what dependency management systems were available, but we did not do it for whatever reason and it came and bit us pretty, pretty hard because they were caching troubles and even more terrible troubles that came because we were not really managing what sort of dependencies are needed. So what this ended up being is that the site started performing unreliably in certain situations. I'll take you through them. And also it started behaving reasonably sluggish despite being engineered as a single page application moving forward. So considering we hadn't done dependency management using require or anything similar, we said, at least let's minify. We all know what minification is, right? Minification can be done multiple levels right from removing your white spaces to changing your variable names to something which is significantly more deep. So the need to minify came and another assorted build steps like concatenating your CSS, minifying, eSipping and boom, this is where we ended up. So we have a system which doesn't, so I mean as front end guys, we use grunt for our task running and we just realize our build system doesn't support it. So, and again, we came back to the same route of saying we need to shift forward. So what really happens is you still have a system where you do a right click and open. You can pretty much see all the code that you've written. And secondly, they are not compressed and they are not performing well for your website. So let's say let's go with versioning, at least the caching issues that we had because of the dependency management not being there. So typically what happens is in front end projects, you keep changing your JavaScript, right? Every day when you're fixing bugs, you keep changing your JavaScript. But most of the modern browsers cache your JavaScript, right? So when the next time you do a release, your new changes will not be available for a certain set of users. This is what we mean by site breaking because of changes. So when you have a dependency management system, it will internally take care of that. But here we said we don't have that. So let us go version every single reference that we have on the website from templates to JavaScript to CSS. That's pretty terrible. Because your cache is always busted. So the performance gain that you will get by actually caching a resource is completely lost because every single request will fetch a new copy of your JavaScript template. So that's pretty terrible. So we pondered this. How about we do a manifest driven versioning where you have a manifest file where you tell what are the files that need to be picked up from the cache and what are the ones that you need to redeploy as new versions. And every single time you do a versioned manifest file, you have to version the manifest file now. And the manifest will actually parse the templates and the JavaScript that you need to load and then a property load to start. So all this is happening primarily because we moved the feature development needle in a way that we didn't factor in dependency management as a first step. So my key takeaway was that if you understand that you're gonna build a full blown single page application, it is important that you get some of these thoughts going in your head. It could be any one of these, but not thinking about it, which is a mistake that we did for whatever reason, kind of cost us pretty dearly. And we had to kind of literally spend time to kind of go back and fix that. So that is that SEO geeks in the room. How many of us are, let me see. I mean, guys, come on. How many of us have built a single page app that has SEO support here? Nobody, one person? How many of us are building single page apps? Entirely JavaScript driven. So no SEO support, sir? No, okay. No SEO? All right. So there's a very interesting anecdote, right? So I mean, when I was working at Adobe and then I took the job at Mintra, I quite didn't know what SEO really meant for a company because I came from a large company and SEO was taken care of. But suddenly I came to e-commerce after a very long time in a shrink-wrapped product software company. SEO became such an important facet that for front-end engineering teams, it almost pushes you to a level where you cannot even build a single page app because your SEO will be broken because your business is driven by SEO. People are actually coming to your website via Google searches and you just cannot build a single page app because it doesn't play really well with search engines. And it's a terrible, terrible place to be and I'm hoping the leading search engine service providers are actually listening and kind of put an end to the situation not having front-end engineers struggle through this. So we started solving this by asking this question. Let us set up phantom.js. So who knows what phantom.js here is? That's pretty good. Anybody who has set it up in their workplaces? Look, I have. And it's monumentally difficult to maintain that thing. It is pretty good. It will allow you to do your stuff, but then 10, yeah, I saw zero. 10 more minutes, okay. So we set up, setting up phantom.js and phantom.js, what it typically does is it's a headless browser which actually renders your HTML and hands off the control to your search engine crawlers, a pre-rendered page while Ajax single page applications are rendered after the page is loaded. So you don't have any content for search engine which is why SEO breaks. So we asked this question to ourselves, why don't we do this? It sounded like a plan, but we just realized it's gonna take a whole lot of time which actually ended up us researching and finding out what other solutions are there. So there is a product called SEO.js. It's actually free. And it's doing what it's like a phantom.js on cloud which will actually do your SEO page generation on the cloud and it was free. And we thought it was awesome. While it is really awesome, it did not work. And there is clearly no support for this thing and the emails went to some mailboxer. I'm sure that the developer does not check and there was or a special folder called trash. I don't know what that is, but then that didn't work. So that took us to the next available option which is called brombon.js. Urge you guys to go and check brombon.js. It's not a free service. It's a subscription model which actually SEO enables your single page application. It's Rajesh Kinkal, it's like 39 bucks a month. It's about $39 a month for a set of pages, the number of pages that you have on the website. They have other plans as well. And that worked and we thought that was very important to kind of put into our system. So we did that. The mistakes that we made were that we think that us thinking that we got it right the first time and subsequently, sorry, what a bummer, the second time and third time. So we continued making mistakes, but the point was that it is important to realize that you're making mistakes. So when you're actually building, this is not even from a design standpoint, it's from an engineering standpoint. It's important to understand that you are making mistakes. When you make a mistake the first time, you have to still push a second time, still make mistakes, push a third time and still make mistakes. The problem that's happening is if as front-end engineers, we start getting a worse to making mistake, it's gonna be a little different. So we made several mistakes and all we did is we started learning that we haven't gotten it fully right yet. As of today also, we have a product out there and we clearly know that we haven't gotten it entirely right, but then we are making everything in our capacity, we're gonna do that. So iterating quickly and failing quickly is another very, very key learning that I personally got, that iterations are painful. It's painful for engineers, painful for designers, painful for everyone, but it's very important to iterate, iterate quickly and fail quickly. So we did this attempt and we had issues. We did this attempt and we still had issues. And then we did, so this is where we are as free charge right now and it takes care of a whole bunch of things. It takes care of our SEO, you have a whole bunch of very useful user cons. So one important thing about SEO is like nobody wants to keyword stuff. Your customers hate websites that keyword stuff. Your customers actually need useful information while still contributing to the SEO value of your company. So that's the reason why we ended up building a multi-store website. It's live at freecharge.in right now. I would request you guys to take a look at that and I have like five more minutes to go. So I just wanted to show you one small little demo of what we have been doing post all these exercises and post all these learning and we're just going to show you a small demo on how we are pushing the front and needle forward helping the customer building a front application. Let me see the internet is working. Otherwise I'm gonna, I will have to run it off my local. This is gonna give you a shot. Is that a good thing or a bad thing? Is that running? I can see it as terrible. So I'm gonna, so what I'm gonna show you is already available on the internet once we're done with this talk you guys can give a spin to the new freecharge.in. And the demo that I'm gonna show is you have a freecharge account and we also have a concept called freecharge credit which is similar to your Flipkart wallet or any of those cash holding devices that you have. So I have, let me just look. I have some money in my freecharge credits. So let's see how much I have. I have about 850 rupees in my credit and I also have some transactions that I have done in the past in freecharge. So what really happens is we are trying to reduce the number of inputs that the user has to do when he's recharging. People hate typing in numbers. People hate choosing their operators. People don't want to do any of that. People just want to recharge. So if let's say you have already recharged I'm just gonna recharge this number again. So when I click this you get something called the freecharge turbo and all you need to do is click the recharge now button. You're paying, your payment is done. We are waiting for recharge. It actually will recharge that phone. So we're still waiting for the AG to send us a response back. There you go. Done, done. So this is what we're trying to do with freecharge. So if you are trying to recharge your out of balance there is no time for ceremonious typing, validating. Did you enter your number right? Are you sure this is there till? You don't have time for that shit, right? Nobody wants to do all that. Or looks like I got your number wrong. Looks like your number needs 10 characters, none of that. You just click a button and the beauty is like I said when people are paying money, see in reality you saw that rocket flying and one pop up, you don't need any of that, really. But what really helps people in an online transaction space is to tell them that, look, I know what I'm doing. Look, stuff is happening. So it's very important to tell the user there's something which we learned and soon after this, Rajesh is gonna come and talk to you as he'll actually throw in more insights in terms of why some of this UI patterns are important. It is because it induces trust in the user that, hey, I am doing something right now and that's finished. I am doing something else and hey, your payment is done. You could just simply show a spinner and say paying and then send him back. Sometimes these kind of small little nitty gritties help the user feel very, very confident about the product that they are using. And we are doing, this is how we are pushing the feature needle forward. This talks real intention is not to pimp what free charge is doing and it's an open public website. I recommend you guys to go and check and give it a spin and let us know what you thought about it. And let me quickly move forward. I am done. I just have two more slides. So our mission is to always build a product that delights your customer and not just your boss. Typically, it's something that my boss believes in. The whole company, I believe in and the team that I work with. Some of them are already here. I mean, I'm gonna, those guys are, the guys who built free charge are in the room. I'm gonna point you guys to them at the end of this talk. So this is something which is very important that we realize to keep your egos as front-end engineers aside and build a product that is good for your customer and not just your boss. The peak to the future is done. Do I have time for like a couple of questions? I have two minutes. I mean, I'm happy to take questions. Yes, sir. It didn't work in a second attempt. It also didn't work. What is the definition of work? So what really happens is, so products of our nature are typically evaluated on what it is doing for the customer. So anything else actually comes far lower in your in your pecking cycle. So when we put the first version out, if you, if such a pity, I can't put the screen back again. We did a whole lot of things there. So we had like a mini dashboard on the left, which actually gave you all the recharge tools and we actually built a place where you could actually see your account data, a whole bunch of recent transactions. And what we realized is that we provided everything for the customer, but he clicked on nothing. He just didn't get it. So you could argue that it was basically probably a UX problem. Let's say if we can argue that it's a design problem, but design problems are never isolated from front-end engineering problems. I believe they are, they're very, very complimentary. They don't run an orthogonal trajectory. So that didn't work. The second one that we put out was a very clean, white, big forms website, but people didn't know why should I recharge in this website. So largely things like simple value proposition, trust symbols or like, you know, certain responsibilities when you click a button that stuff is happening, all those things were lacking and the site had some of the performance issues that I mentioned, like I had cash bursting issues and so on so forth. So when we iterated, we started looking at each one of these and started figuring out what else can we do and so the definition of working is your customer being successful. So we don't even know if the third one is working on or it is like two and a half days old, but we're hoping it's gonna work slightly better than the previous one. We'll learn moving forward, so that's that. One more question, I think I can take one over here, sir. How do you use a test to your... So how do we use a test? So we recently started AB testing and as much as I am ashamed saying that we were not AB testing since a very long time and we started doing fairly complex AB testing and feature gating only recently. So we do two things. So basically we have a simple AB test framework which is a standard A bar where you get version one for a set of users and a version two and we also have a feature gating system where you have an internal code element where you can actually gage features on login information or based on which browser he's coming from. So for example, a whole bunch of people will get a different UI with both postpaid and prepaid but you can actually give the same UI which is actually sliced and diced across multiple features or multiple trajectories through a feature gating mechanism. That's what we are doing and we're still evaluating what are the other AB testing or feature gating methodologies we can drop and we are still in the infancy of figuring out. I have been in the past in a very significantly strongly instrumented organization but we are trying to build that feature right now, still in the infancy. Thank you very much. Do we have one more question before I sign out? We have, sure. I'm coming to you, I just, sure. Question is more on the philosophy behind going for a one-page app. Did that give you anything significant? What was the decision process in going for that? I'm really glad you asked that question. So his question is why did we choose to build a single-page app in the first place and what was the, was that just a choice that we had to move? So I will answer you in two parts. So basically a company like FreeCharge, the UI is actually just the carriage that takes the product to the customer. So basically what really drives a product like FreeCharge is the ability to do a successful recharge. So there's a whole bunch of backend geekery that goes on it, kind of. So what really happened is servicing that backend is absolutely required because FreeCharge is diversifying itself into web, into mobile, web, into mobile apps and probably into tablare. And it is absolutely not possible to run with a system which is hard to handle. So when you have a service-oriented backend, when you have an entirely serviced backend, you will be able to build very componentized to digitized products as part of your larger system. And at that instance, it makes a very, very strong case for moving your entire thing into a single-page application because eventually, ReCharge is the following. You click a button, you should get a recharge. So people don't want to see pages, really. People don't want to go from recharge page to coupon page to payment page. People don't want to do that. People just want to recharge. It's like how you go to a shop and say, give me 20 bucks and you use 20 bucks. So even in, when I say that in English, it makes a whole lot of sense to say that it eventually becomes like one single rectangular screen where stuff happens and gets done. That's my good for a long time, Rofi. Thanks, Rofi. You mentioned that Grant was not working in your case. Can you detail it? Yeah, so what was happening is we had, so we use a Jenkins-based build system, which is internally configured to build files and minify and run. And it is just that in the kind of timeframe that we are operating in, we just couldn't get. So the answer is, we don't know if it will work or we just couldn't get it running. So whenever we actually brought Grant into the system, all hell would break loose and our releases started getting moved out and pushed out. So we still do not know what we have to do in our build engineering system. The real thing was still figuring out to do that. So I don't have a largely useful answer for it just that we couldn't figure out how it works. And there was one last person that has to ask a question before Rajesh takes over. Thanks, Rajesh, for waiting. Yeah, so I have a small question regarding your responsive mechanism. I checked your website on mobile and it's all good. And then I checked it in the browser. I resized the browser, but it didn't work out. I mean, it's not responsive in the browser. So is there, we have done something like exclusively for mobile and... I'm going to answer this question in a very, a brutally honest way. If it didn't resize on the browser, you most likely found a bug. Okay, fine. I'm on Chromium, right? A pretty shameful one at that, which we will fix. But we haven't done anything specific. We do have a separate mobile site, like I mentioned. So if you're actually hitting the website from a mobile device, it will redirect to a mobile installation. Actually, you're not redirected. It's your normal free charge.in only. Because I'm on iPhone, so it's not an M website. I think you just found it's a bug. Okay. Thank you so much. So by the way, I'm on Ubuntu 12.04, Chromium 32, right? On top of the line, so before I walk away, so thank you so much. And over to Rajesh, Rajesh is my compatriot at free charge. He helps build the free charge product though. We will be out here hanging out trying to take questions. Before I go away, I am Harish underscore IO on Twitter and Harish hyphen IO on Github. So Harish underscore IO on Twitter. He does that for anything, any questions, any feedback, anything that you want to ask. Have a fantastic rest of the day and thank you so much. Big round of applause for Harish.