how many of your designs that would yes how many of your developers so I'm going to be talking a little bit about a process that I'm trying, you know, it's a process that will help designers and developers work pretty much in parallel right so as we go through the session we'll just cover it so let me start with a little bit of me that's my online one you know I had the front-end team in HP right now that's pretty much my background the presentation there and the controller there are my life most of them at least so prototyping what I know most of you know you know how difficult it's for you know for me to get a job right I don't have a role wherever I go but yeah in my product I think is about making ideas and design right because when designers put the put on their imaginative hats and now like start working you know pretty cool stuff but around 60 to 70% of it usually ends up being just a rainbow which can never be this is cool this is nice looking but it can't be done not with the technology that we are working right this is something that most designers are involved in their daily life so that's what prototyping is about. So in this session we'll talk a little bit about how designers can use some prototyping techniques to actually generate and all be in front-end without actually doing it. So what would you say is a good prototype? I mean I have seen people call photoshop marks the prototype photoshop marks tied together with hotspots they are also called prototypes anything done with dream people is called a prototype, anything done with actual is called a prototype. People do prototypes with power pointers but are those the kind of prototypes that we are talking about? I'm going to be talking about in the within the context of software I'm going to be talking about real prototypes which are high-fility prototypes which have got production quality code. So how do you like judge a prototype? A prototype generation has to be real. If you're trying to generate a prototype and it's going to take two months for you to do that it's not a prototype. You're writing something else. It has to be quick. An average span I would say is one to two weeks for any prototype for a prototype to take design to production. To make that they shouldn't take more than one to two weeks and if it's not done within one to two weeks it's not a prototype anymore. So the turnaround process should be very quick. It should be iterated. You should be able to go back to the drawing board at every stage and make changes as the designers themselves. You build something and the designer comes back and says oh that blue color is bad. We should try out a different shell of blue and you say it's difficult to do then it's not a prototype. Your prototype should be iterated. It should be quick. It should be developed in one to two weeks of time. It should be iterated. Now it should also be pixel-perfect. You should be able to open up a Photoshop block in one screen and the actual prototype and another screen and it shouldn't be able to tell anything. It should be pixel-perfect. Every pixel on the screen should match. If you've got a header there if it's 12 pixels in the Photoshop block or the PNG file that I'm giving you your prototype should have 12 pixels. If it's 12 pixels it's not a prototype. I'm just going through the kind of list of things that I would judge a prototype based. And then let's talk about how to get there. Yes. Not Photoshop file loaded into the browser. I'm talking about Photoshop file or illustrated output and written code. HTML, CSS, JavaScript. We are talking in the context of the web-based user interfaces. Now you should be able to take this and apply it to any programming language. Even if you're building something in C-Sharp or in a document platform. If it's thick line you should be able to apply the same principles. But most of the time I keep referring back to the web because this is metamorphosis. Most of the guys here are working on web-based products. But that's all right. It should work with real data. This is very important. Unless your prototype works with real data as in the data that you put in, laura-mepsum is not real data. If you have a list of employees listed in the user interface, it should actually have a first name, middle name, middle password. If it doesn't have that, then you are playing with imagination. Because the moment you take this UI and plug it back in code into video, it breaks. It will break because you have the right amount of space. Things like this would happen. So it is very important to use real data. Now how we would use real data? We'll get real data. It's very important to use real data. The flows should be complete. If it's a login flow, it should have login fail, login success. For God's sake, even sign up quickly. The flows should be complete. It is important that you have the flows to be complete to be called a prototype. Otherwise, it's still somewhere in the realm of low fidelity, high fidelity. It should be small and portable. So this is where I will say a classic engineering prototype differs from a design prototype. Now if you look at an engineering prototype, what will happen is you find that engineers have built something, but and you send it, you want to send it to a customer or a marketing person who is like, you know, in some other country. You have to set up a server there. You have to set up a database.  If your prototype requires that, then it's not a prototype. Your prototype should be, you should be able to pack it up, zip it up, mail it to somebody and they should be able to run it locally. Now imagine I've been talking about full flows, real data, you know, working code and I'm saying that we should be able to pack it up and send it to somebody. Now this is not really possible. Engineers understand that this is not really possible without a web server in the future, but there are ways to do that. So that's what we'll be talking about. It should almost be production quality. Your HTML that you write in there, it shouldn't be dream be work quality. That's what I'm talking about. It shouldn't be the drag and drop machine generated HTML. It should be standard compliant HTML. Why? Because unless you're writing good code, your prototype is really not reflecting the actual product that you're going to be. So most time when prototypes are built, I've seen people cook up something with dream beaver with whatever you say and then somehow package it itself. When engineers start to write code for it, the whole game changes because when they write status compliant code, there are browser compatibility issues. When you write CSS, they stuff that wouldn't work in all browsers and all that. And eventually what is compromised is the user experience or the design. So your product type shouldn't have any of those additional stuff, which means the designer has to understand the domain, the requirement, the client and the infrastructure that the client has clearly as much as a guy as an engineering architect does before building or designing an application. Right? This is even more important in the context of web applications and the device applications. I said a bunch of stuff here, right? So we cannot get there with just static HTML with some images, we can't get there. How do we do that? So back there in the last like four or five years, we have seen we can move the framework emerging temporary. So what's a templating framework? Templating framework is just any third party library that's available on the web. There are billions of them. It's a library that allows you to write HTML code with a little bit of placeholders for real data and generate a prototype which we use and behave just like the original without actual data talking to the world. When you pull out the dummy data and plug in the backend, the UI should just work. If you have a user interface which has got a which has got like, for example, a phone book, you have a list of, you know, people with their phone numbers in it. In your dummy data, you have got a list of 100 people, you know, with their phone numbers and the UI, the prototype. The moment the engineer pulls out the dummy data and then plugs the actual backend to you as in he makes a hijax onto a server which returns a list of user names and there's no number. The UI will be touched. The engineer should just make the changes in the Java group layer and the HTML layer should just work. It should just work. No changes there. No copy paste business. It should just work. That's what a templating framework helps us do. So now let's look at how that really affects design a little bit. So two types of, you know, templating variables that I think are commonly around right now. There are server side ones and there are client side ones. The engineers don't know. You would have heard of this, there are templating agents like smarty, which actually provide server side templating. But that's what we are talking about. We are talking about client side templating. When we say client side templating, we are talking about templating using HTML, CSS, and Java with a little bit of stuff. So there is something called Logitless, you know, what are Logitless templating variables, frameworks which do not have business and do not force you to put business logic inside it. Where you can extract business logic completely from the presentation. When you talk about the screen, let's talk about the phone web example for example. There is a list of employees. You click on one of those employees, you get a details of them. This is a very master detail type of screen, which most of you would have worked on. Now if you look at that, the business layer all it does is it gets the data from the server. There is a bunch of stuff that's happening on the UI. What pops up, you know, what happens when you recall it as a low color change, these are the challenges that the designers usually face. And these are the challenges that the engineers are disturbed with usually when, you know, when the designers are trying to evaluate the prototyping. That color has a slightly different shade in Photoshop. So you should spend more time looking at that. While that's not the priority for the engineer. The engineer is more concerned about 100 rows of data models because of those of data, how do you add them? The wrong shade of, you know, Meravala thing is not really the concern that the, you know, engineer has. So that's the most important factor for the designer. So templating engines, logicless templating engines actually allow you to abstract the back can be completely different. When I say even now, when we write HTML and JavaScript, there is often, there is a fair amount of business logic. There are isolated loops put inside the HTML layer, HTML or the JavaScript layer, which actually represent business logic template engines actually force you to not use that. When we have a look at the actual template code, I show you that. Data features. What is data features? Data features is a gummy data. We have data which in the form of JSON or XML residing locally will be loaded into the program. Now, partials. I should probably touch partials a little bit later. Design of engineering This is what I'm talking about. The engineer is quite different. So what is the standard design engineering in DHK? The standard model is the designer will something for 3 months and then, you know, creates a PDF file out of it or and it is locked up with a reviewer code sent to engineer and then the engineering starts working. Right? So this is kind of time-based engineering has to wait a little bit till the designer has done their design. If you could run this in a path, if there was a way, I can actually get the designers to start working on the same way that I start writing my engineering code. When I run control of code in the design, I can start writing the front end code at the same time and then check it into the same repository. If I go and make changes to the design code or if the designer comes in and makes changes to the HTML code, my engineering layer of the business logic is not affected, then there is a huge spike in production. Right? So templating engines frameworks allow you to do that as well. There is more design, innovation and experimentation. Let's take the example where you have, you have started working and you are like 8 months into production or 8 months into development and one coding has already been delivered or it has been live on the platform. Now the designer comes in and says, you know that time we check that they are on the site, we should try to change it into time. So the usual response is, oh we can put that into our next release which is in 2018. By then the technology is obsolete, the requirement is obsolete, the user is affected. Right? So how can I let the designer go and experiment with his stuff while ensuring that my engineering code is not affected? My business logic is one affected. Right? A framework like that allows you to do this. Let's take a simple example. Let's really get down to it. Most of you understand HTML, right? Anybody who doesn't understand HTML? Thankfully. This is a classic, right? It's got a first name, second name, city. It's enclosed in a dip, three spans with the BI approach. Standard HTML code. Nobody has any complaints about it. Now what would the data for this be? Simple JSON file? First name, Uday, second name, uncle, city, Danu. Right? Now how do I tie these things together? Let me go back to that. You see this code here? There's curly braces. First name, second name in city. Now you'll see that these are the same variables that are used here. Right? Now when you compile that template, when I say compile, it sounds too technical, but it's just about including what JS library in the file. Okay? When you put that in, the return of output would be this. Generated in HTML code. Right? Now this sounds, this is the output that you see on the web browser. Right? This sounds too much complicated for just printing two lines of data. Now I can do the difference. Let's go back to code. So this is the same thing that I showed in the PowerPoint. Okay, let me clear up now. I'm sure there's a bit to it, but I have no clue. Can I see this one? Oh awesome. So this is the same thing. I've got a template here defined here, which is just HTML code. Right? It's a string, a simple string of HTML with some A's olders put in. And then I have a separate JSON data here. Now what happens when I do a compile here is this data gets converted to it. This gets merged and then output is what you see here. Simple stuff, but it's way too much for to print two lines of data. But imagine a situation wherein I have to print a list of data. Now let's look at how you now also JavaScript, they talk about it if you look at this, look at this part you've got a header on the screen. UL and then in a line, another header to here and close in a script. And I've got a bunch of JavaScript code here. And this sometimes I get this. Why is this powerful? Because now if I want to build, so if your entire UI is generated with JSON data which is like outside your HTML code, you can actually go in and make changes to the JSON data and populate dummy data into your UI. It makes a huge difference in your UI. Now even though in the script that you saw right now here, have the script, the HTML and all of this in the same code. But technically you can supply this into different machines. You can have a JSON file in the machine. You can have a template and then you can have a HTML file which will call that template and say that is the data. This is the template, put it together and print the script. This is in the bigger world where you are building two or three queries. Now if you realize what's happening here is your template is also an internal file. Now think about a situation where you have yes no button on screen. Your button screen which has got a workflow of, you know, steps and all the steps have got a yes previous back and yes and cancels button. Now the standard way of doing it is putting in that HTML code in all the places. Now what you can do with the framework like this is create one template with all the four buttons in it and then reuse that template. For designers, the power is you can create one component which is properly designed on the slides of time and then reuse them from the screen. All of a sudden we have the power of including file in HTML. Because something in here is always done in the document. We have always included content component somewhere. Now we can reuse chunks of HTML code especially in the context of an enterprise application and you have like several screens which are using the same template and the manager comes in and says I want this button to look like something else or I want to change all the checkboxes in this in the entire code to be radio buttons. You can't make this child change the CSS change. You have to go through the code and make that change. If it is coming out of a single part share or component in the world of templating, the component is called a partial. It's a partial part of the code. If you make a change in the partial, that change is reflected across HTML. This is very powerful. This way of actually being able to drill in dummy data, split up the UI into multiple components like if you have a left pane the left pane is one partial, header is another partial and each of them are populated with different buttons of JSON data. Now if you are the business of building prototypes, one of the most common requirements is the marketing team coming and telling you is that product is built for the last month for that American client we need to make it work for the Chinese client. So can you change all the blue color to red color? This is very common. Change all the names John Doe to do a change. This is a very common thing and we end up creating more and more and more of these products. Now you can just tell them, there is a file with an extension .json. It's English. Go ahead and change it as you need in the prototype. Now if you see I can just make it easier. I can change this to I can go back and change the page I am not touching the HTML engine. I am just changing to JSON data I can do a lot of these. This is just a plain part of it. The company framers actually give you more power. They do a lot of stuff and if you repair the code here, the focus of this one is Reynolds. This is specifically for the developers. They don't say got it. This is where you write for I am going to write to 0 I less than the layer, I don't worry about the layer. Repeat that thing. All that is taken care of by this called denotation. Now where is this powerful? This is something a designer can do. It won't find it difficult to write this. I know because I have tried this. Because when I outside I found it very difficult to get the right kind of frontend people to write. So I have to resort to getting interns to actually work. Interns who have got absolutely no background in time. So anyway if you are not going to do it, you have no background in programming and try to tell them there is something called an array and there is a way you can iterate through an array your boss. They don't do it. But if I tell them that all you need to do is this, write this and if you have a list like this which is the same variable and each item in this list has to have these variables here. So what happens here is now I have got a bunch of code which my designers can work on comfortably. They can make changes to it. When I say engineering all they do is the only thing that engineering does is pass a variable from the return function or result function of an intern. The UI works. They don't go and change LI here. They don't copy paste UL there. They don't do any of this. The styling, the layout, everything is done by the designer. It's within the control of the designer. The designer continues to own it. If the UI looks bad it's still the designer's problem. It's not the developer's problem because the developer has never touched that problem. The developer has focused on the back end, the control layer and in the presentation layer they have just ensured that the same variable name is being used when they send the result back. How much time have you as engineers wasted trying to get that one pixel line at the right spot? Most engineers don't want to touch it. Getting that one pixel line should be slightly towards the left you waste time. The designers are used to that problem. The designers will spend 3 days trying to fix that one pixel line. They don't have a problem with that because that's the job that they enjoy doing. For an engineer it's a pain to fix. The important thing I am going to most often figure out. Now with this kind of a mechanism in place. You can say hey designer, you take care of the points. One of the updates is that I don't want to touch that one. So there's no question of you fixing that and putting in my conditional loops in between your HTML is doing a good job. My business logic will reside completely outside your screen. Your HTML is intact. You just keep on checking in HTML, CSS, HTML, CSS. And I'll check in JS and at the end of the day it will just work when it comes to the actual code. Now it's somewhat of a difference. Slightly different scenario. This is a very common problem that we face. We are 6 months into production. We have the buildings breaking today, for example and we are not able to compile this. We are the director of your organization when there is no business from your organization. Somehow get that running. I want to show you. Your entire backup build is broken here. This is something that I face today. If I don't send the data, we are going to find it. The UI is still working because of the data fixture. If I don't send the data variable, the UI is still working because the data is running out of JSON data and it's still there. So what it gives me is a sign-off and I can share it with everybody. It's been 10 years of the status of the current app. You don't need a fancy server environment. You don't need anything. All you need is a browser and you copy this zip file somewhere locally and open it and run it inside your browser. It's a very powerful tool. Now let me go back to the slide. So this is the second example I showed you. I showed you the string test example. Now what I showed you was two examples. In the two examples I showed you, I used two different labels. One is called mustache. One is called mustache and the other one is called handle boss. Now when I say mustache and boss, all these are JavaScript. All these are JavaScript open-source languages. You just have to include these files in your HTML file and this terminating will work. Just as a use case, I don't know how many of you, do any of you use Yahoo Mail or Calendar? I wrote the front-end code for Yahoo Mail. So we have used this terminating mechanism for that. Then you won.  And in the enterprise applications that we are building in HP right now, we are using a similar process. We are using a different bunch of frameworks but the process is still the same. We have interaction designers, we have visual designers who turn out the PDFs after PDFs of wirefix and based on that we have HTML designers, front-end designers who take, look at the visual design in BSD or Illustrator 5 and turn out HTML code. We are re-checking this code directly into the same git repo as the engineering and the engineering all they do is they replace these variables with the data and in a day, the UI still continues to work and my team can continue working. So this was another problem that we were having in many companies that I wanted to develop when in the back-end race, the whole team has to sit down and wait till the back-end is fixed because they can continue. Now they can. So handlebars is one, this one is one and then this third library. So I just picked up the three most important ones. Just JS, Handlebar, JS and Mustache. Now Mustache was built based on the principles of closure to place. See it's a place that Google has created. Mustache is logic-less, it's very simple very easy to learn. To give you examples of where you can find Mustache, you could find Mustache in Storify.com in many of Yahoo websites. Now, that's still what is being used by LinkedIn. Handlebar is used by, I believe they are used by AOM and HM Corporation. So these are like the three most popular frameworks. If you see the list from top, this is because I got tired of copy-pasting. But the list is like three times of this. There are so many templating libraries out there. Each of them do the same thing, but with some bells and whistles. Now, why did I pick out Dustin? Because LinkedIn did a benchmarking of all the available logic-less templating languages and kind of published an article on what does work better. Based on that, I felt these are three engines that will work. Now how do you choose a right templating engine that is only used? Like there are six or seven of these types. The first principle is drive. Drive means it's a principle it's called don't repeat yourself. As in one piece of code that you write, if it is used anywhere in a six-centre screen UI somewhere, it has to be reusable. If it is not reusable, then use of code is a wastage of time. So you choose should support that kind of passion. It should allow you to do stuff drive. It should be designer friendly as it should be very simple for the designers to figure out because that's what we're trying to do. Get the designers to do what they do best. Get the engineers to do what they do best. Don't try to make sense. I mean there is this philosophy that I'm hearing pretty recently where people say be a jack of all trades. We need designers who will prototype, we see who will prototype and who will do visual design. No. We don't need to be jack of all trades. We need to do one or two good stuff. We should do it best. We should design it. If you ask me to draw a cat on the board, I will sign it. But I'm good at writing JavaScript. But another guy who won't be able to fix the problem with jQuery language, he makes no. I'm not that good. I'm good at building many designs into design. That's what I do. I understand the difference between a one piece of line and two pieces of line. I'll spend three days trying to fix a line with. So that's about design friendly. It should support multiple languages. So internationalization should be supported. It should support hot reload. Hot reload is what you saw. You make a change in the code. You go to the browser and do an application code. It has to go through a build mechanism. It should just work if you do a refresh. The loading speed shouldn't be hampered just because you want to use it. If you look at Twitter, it uses a template called Hogan. Hogan is just a combined version of moustache. Why it's important is because Twitter found out that when their engineering team found out that their UI is getting slowed down because of the amount of data that's coming in and the whole JavaScript file trying to render data live on time, they realized that this is not going to work for us. So they wrote a compiler for it. What the compiler does is during the build process, the compiler takes all these different templates that have been built, takes all these JSON files, compiles them together into a native JavaScript code. And that JavaScript code is used by engineers. So this whole bundling up is done by engineering automation. It's not a human being doing it. So designers can still continue to work on the templates. All they have to do is before, as part of the nightly builds, these templates are tied together, stitched together and compiled into native JavaScript code. So Hogan does that. So learning curve should be less, I've already solved it. Productivity, I've already covered it. It should be actively developed. This is a major point. There are so many libraries out there. It's very important to ensure that the one that you choose to be active has a community around it that people are developing. If nobody is developing it, then you should probably choose it because three months around the line, it's probably going to be obsolete. And you won't get support for whatever. So find whether it is just Google for whether it has got an actual community around it. When was the last chicken made into GitHub for that project? If it has been done in the last one month, yes, that's a good option. But it was done in 2007, then maybe you should look at some other engine. Community support, it should be library agnostic. It's very important. If the templating framework says, if you want to use this templating framework, you have to use JavaScript MVC, then it's a barrier. Because tomorrow you will move away from the control, JavaScript MVC for the control engine. So you should use a templating engine that is completely JavaScript or library agnostic. The last point is you should find one which has got an editor support. Check whether there are, what do you call it? Code inside available, plugins available for Coda, TextMate, Notepad++, Sublime Text, whatever you use. Check whether there are plugins available for this, which will make life easier. So final, my recommendation is just so, I'll be putting this PowerPoint on the Metamorphose site or somewhere. And it has got a URL here in this slide here which points to the LinkedIn article that I was telling about why they chose dust on what principles, on what benchmarks. It is very important, go through it, if you are planning to do templating. And that link will work first. Yeah, that's pretty much it. If you have any questions, please. It has just been simple, very simple, you know. You can have, you can have, you can have, you can have, you can have or there is some value for you. Yeah, so you do not have to do that kind of thing. You do not have to do that kind of thing. How do you do that? So why do you have to do that? Most of these are available for you. So you do not have to do that.