Hi, and welcome to the course, build your first web app here on Microsoft Virtual Academy. You might be here for one of many reasons. Maybe you have a great idea for an app that you want to build, but you have no idea where to start. Maybe you have some programming knowledge, but you've never done anything for the web, or maybe you're just a lifelong learner who wants to pick up something new and learn what web development is all about. If any of these things are true, then you've come to the right place. I'll be your instructor for this course, so let me start by introducing myself. My name is Brianna Dean. I'm a content developer for the Microsoft Learning Team where I create online courses like this one to teach computer science and prepare students for careers in software and development. I love teaching computer science so much that I also volunteer teach at a high school here in Seattle before coming to work every day. I've received my Bachelor's in Computer Science from Georgia Tech, Go Jackets, and prior to joining my current team at Microsoft, I was a software engineer on the OneNote team. I learned computer science in high school. That was my first introduction to it, and it wasn't the greatest experience at first, and that's what kickstarted my interest in teaching computer science because I love teaching it in a way that excites and engages more people. I hope you enjoy this course. So let's talk about what we're going to learn. First up, we're going to start with how to determine what you're going to build and why. So we'll talk about how to identify users and the target audience for your app and things like that, and then we'll go into how to actually build webpages. We'll learn a language called HTML. From there, we'll learn how to add style elements to those webpages using a language called CSS. Next up is manipulating web content, so that's adding behavior to webpages, and that's using a language called JavaScript. From there, we'll get into some back-end web development concepts, and then we'll learn about databases so that you can store data for your app, and finally, we'll learn how to put your app out to the world using Azure. So by the end of this course, you'll have designed an app for something that you're interested in. You'll learn how to build it from scratch, and you'll have it up and live on the Internet for other people to access. Now, those are a lot of topics to cover. So the purpose of this course isn't to cover each of these topics and languages in detail. That would be a lot of content. Instead, you should approach this course so that you can get an understanding of each of the pieces of building web apps and be able to build upon that knowledge from there. So we actually have some other courses that would be a good next step from here. They're listed here. These are our courses on edX.org, and they'll be linked in the resources for this course. So the first course is designing a technical solution. That will cover a lot of the User Center design, HTML and CSS principles that we talk about in this course. Next is a course called Building Interactive Prototypes Using JavaScript, and that will cover all about basic programming in JavaScript and client-side development. Then we have a course on building functional prototypes using Node.js, which will cover all of the back-end web development concepts. So I'm glad you're here and I'm excited to teach you about web app development. So I'll see you in the next video. Welcome back and welcome to module one of the course. So we know we're here to build web apps, and you probably want to build something that people will actually want or need to use. So in that case, you should start by planning and figuring out who will use your app and why they will want to use it, and how you'll make sure that you add value to it. With me, talk about this. I have my co-worker Adrian. Do you want to introduce yourself? I would be happy to. I'm Adrian. I'm also a content developer here at Microsoft Learning, and my expertise is in the design thinking, user-centric design fields. So I'm happy to be here and talking to all of you. Cool. So as I mentioned, the first thing we'll start with is figuring out who our users will be. But before we do that, let's just define what exactly it is that we're building in this course and what a web app is. So an app in general, first of all, is a software program that allows a user to complete specific tasks or achieve specific outcomes. So two things that stand out from that definition is that has to be user-centered. You want someone to be using the app on the other end, and it runs on some sort of device. That distinction about what device an app runs on is what makes it a web app or a mobile app. So in this case, we're focusing on web apps, which means that we're creating things that a user will access via a web browser. That's really common nowadays, but the internet being so widespread. People can access your web app from their mobile phone, from their desktop, from any device that has a web browser. So now let's talk about who those people are that will be using our app. How would you describe user-centered design? What's the foundation of that? There are two main principles. I think you know what they are because they're on your slide. But those two are user feedback and iteration. And these are two things, a yin and a yang, that can't exist without each other. Because to iterate, we need to know what the users think, and to actually find out what the users think in a meaningful way, we have to make something new for them to look at. So user-centric design is a cycle between building something, showing it to the user, and then taking feedback, and then improving upon your original design. Right, so you don't want to spend a year building something in isolation and then show it to your users and see what they think to you. No, it's all about rapid iteration, rapid prototyping, and most importantly, rapid failure. You have to sort of learn to embrace failure because every time that we fail, we learn something. And those discoveries can lead to the creation of a better user-centric app. Cool. So before we can build something to show them, we kind of need to figure out what they need, what we can build for them. Sure. So as we're designing and building software, you kind of want to create a user experience that it draws people to your app. And the foundation of that, as represented in this pyramid that you see here, is something that satisfies the needs of your user. So that's why we're going to start with user needs in this module and figure out, talk about how we can figure out who our users are and how we can address the things that would benefit them. So how do you figure out who your users are and what their needs are? What are some ways that we can talk to our users and figure those things out? Well, most of the methods can be categorized in two categories, quantitative investigation and qualitative investigation. The most common in the quantitative category are user interviews, sometimes called contextual inquiry, where a designer will go into an environment where the user is doing whatever they do and just observe them and sort of see, look for pain points. They have to work around something with something difficult for them to do. And that'll inform our decision on how to pick a problem that we want to solve, really, because that's what this kind of comes down to. Yeah, and I think some people don't realize that they can simply go to where those people are and talk to them and observe them. People think that we have to do these high-level research methods when really it's all about the user, so you really want to be with them as much as you can. That's true, and I think one of the most important things that we can stress right now is get out of your office and actually go talk to users, because that's how you learn, that's how you get better at design, and that's how you ultimately make a better application. Right, and then another way to, once you've done this research, to kind of synthesize that information and figure out your high-level groups of users is to create what are called user personas. And that allows you to kind of think about all of the things you learned about your user and create a fake persona that will represent all of the important information that is relevant to how you'll address their needs. Sure, like you said, the user's not gonna be in our office working with us all the time, so we need to create this user persona that we can consult, and we're not actually able to speak to the user. So that's kind of how you can start with identifying user needs and synthesizing them and making sure that everyone who's working on your product knows what you're going after and who you're building for it. And in the end, the goal here is to identify your value proposition for your app or your product. So that is, you should be able to, at the end of this process, summarize who you're targeting and what value you're bringing to them, and a single to sync statement both for yourself so that you know what you have that in mind the whole time and both for the users who will want to use your app. So that's the end goal. Right, and these statements are sometimes called how-might-weave statements because they combine the user, who they are, and what they need to do. So you might say, how might we help airplane commuters get through the airport more efficiently? That sort of encapsulates who we're talking about and what we want to help them do. So the essence of what we talked about so far is that you should be building what people need and not what you as a developer want to build or what you think people will need, but what people actually need based on user research and actually getting in front of your users and talking to them. Hey everybody, I'm Ian McAdsel. I'm a product manager on the OneNote team at Microsoft. I studied usability design at the Rochester Institute of Technology in Rochester, New York, and I've been at Microsoft for six years. And I'm William Devereaux. I'm also a product manager on the OneNote team, and I went to school at California State University, Sacramento, where I studied computer science. Now I've been on the OneNote team for about three years where I lead all of our Windows apps. Ian, can you tell me a little bit more about what it is to be a product manager? What do you do? That's a really good question. Product managers are essentially CEOs of the product. And so that means we wear a lot of different hats and we do a lot of different things. But overall, we need to determine things like the product strategy, what we should build and how we should go about it. We need to think about things like the roadmap and prioritization of features within that roadmap and determining what we build. So those are some of the things that we do as product managers. Yeah, it's always really important to, we're kind of, like you said, we're the CEOs, we have to look at the whole thing end to end and we talk to customers, we work with the engineers and the designers and marketing and support and really make sure we deliver a complete experience end to end by the time it reaches customers. And so I think it's a lot of fun because we get to wear a lot of hats and do a lot of different things. Yeah. And really get to experience all the different parts of the whole software development process, which is really cool. One of the big aspects of our role is customer engagement. This has been a huge area of focus for the OneNote team in the last year and a half or so. Definitely. And so do you want to tell some of the unique things we've been doing that we didn't do it previously and now I think it's really helped the team a lot. I don't know if you have anything to share. So some of the things that we've done since turning into a more customer-centric focused product is really getting out in the real world and understanding what our customers want and need. And we do that both through the real world, like going to, for example, for OneNote, we're focused on education. So we go out to schools and we do a lot of customer visits in person. And so I've done a bunch of that personally and want to talk a little bit about the things we've learned from that. And a lot of times we actually use the power of the internet and we go out on the web and just there's so many places these days where people can provide feedback on a product, right? So there's things like YouTube. There's things like Reddit. There's so many online communities that you can go to. Store reviews. Store reviews, app store reviews is another big one. And so I know you've done a lot of that as well and looking at the totality of the feedback and figuring out what we should do based on it. Yeah, we get a massive volume of feedback. It can be overwhelming at times. But it's good. We like hearing from the customers and talking with them. And as you said, we'll be online all the time looking through the forums, reading reviews of the product. There was a time right after we shipped our Windows 10 app where we knew there were a couple of features that we didn't quite have yet that we wanted to get added. And our users knew this too. Our users also noticed it. And so I think over a two or three month period I responded to every single review that someone left us in the Windows store. And every single one, I reached out to them and said, hey, thanks for using our app. Want to hear what you like, what you don't like. And then we had this one-on-one engagement with every single person, people that had issues. We actually connected them directly with the engineers. Not some support team often, some other part of the country or the world, but our engineers who sit in our building. And that's a really good point because one of the things that I think is a common perception when I go to schools and talk to them about product management or working at a tech company is, oh, so you just write code. And that's what a computer scientist does. But we both went to tech schools. We have tech degrees. Yet we're not writing code day to day. We are doing the other things that make a product, right? So, and again, it's not just designing either, right? People think of the classic thing like, oh, there's a design and then there's people who build it. But pre both of those things, you need to have someone who says, what should be designed? What should be built? And that's really what we do, right? That's exactly correct. I mean, I'll provide feedback on the design or the code office, hey, we can try this or that, give my ideas. But in turn, when it comes to those things, I actually don't do any of the work myself, right? We have specialists who are, they're skilled in engineering or design or marketing or whatever. And so we actually just get to partner with all of those people and make sure that the end result meets the goals and the needs of our users. And I know another piece that we wanted to talk about was this notion that there's, in the world, we talk about it as qualitative and quantitative information, right? The qualitative is the numbers. It's all the data of the feedback and the metrics and there's either, there's business metrics, like how many monthly active users we're getting, but then there's lots of kind of telemetry based, like data on crashes and bugs and things like that. How often does someone click a feature or all that sort of thing? And we have great data scientists these days and that's a whole nother field in technology you can go into. But as product managers, we kind of sit on the other side of the fence and we've really focused on kind of, I would say the qualitative, the kind of art of it, right? If there's a science half to it, there's an art side of it. The quote I love is Henry Ford and he used to say, like if you just ask people what they'd want, they'd say faster horses. But they didn't know that a car could exist. And so what I was gonna mention was when you went through all that feedback, part of your job, I think, was to actually prioritize and figure out what should we do with all this feedback? It's not just about answering everybody individually, but it's about kind of correlating all of that together to mean something, right? To figure out what the plan should be. You're 100% correct. I mean, a lot of times people will say, I want feature X and you could just go build it, but that's, yeah. It doesn't scale. It doesn't scale and it's not always what they want as well.  What are they trying to do and that they're struggling with? And sometimes it is exactly what they wanted, right? For example, they wanna be able to highlight text, maybe a text highlighter is probably the right thing to do. But if maybe they're having issues with constantly bumping something in the interface, instead of just fixing that particular issue, which is important to focus on. So you're not actually bumping the page list or something, but maybe you, they want a special full screen mode where they can ink without any distractions and have easy access to all of the things they need, all the tools. And so it's really like thinking through and figure out, okay, what do they actually want? And as you said, it's kind of an art. We definitely rely heavily on the science side as well, like the data, right? To tell like, do people use a get feature? If they don't use it at all, well, chances are we probably shouldn't build it or something similar. There's a lot of things. I think we wanted to wrap up by telling a couple of real examples or stories from our own experience of kind of how we took input from the real world as product managers and made it a reality, made something, a feature out of it, right? And so behind us, you actually see this is one of our Surface Hub products. It's an amazing large screen device and it's running OneNote, our Windows 10 version of OneNote. And it's the, you'll see, there's digital ink written on the screen, but one of the things that you see there is what we call rainbow ink. So the ink actually looks like the colors of the rainbow. And this was a super interesting project that I was able to lead and it came out of doing those customer visits to a school. When I went into the school and I asked the class, I said, if you could have ink do anything in the world, what would you want, right? And I remember this so vividly, there was this girl in the back of the classroom and she was very like, they were younger class and very timid and a little afraid to speak up, but she raised her hand and she said, I think it would be cool if the ink looked like a rainbow. And immediately the rest of the class erupts, right? Like they're like, ooh, ah, oh my gosh. And so I put that in the back of my head. I went back to our design team and our engineering team and I said, guys, this is what we have to do. There's something here, right? Like that reaction is the art. That is the thing. I didn't need to see a million users of data. All I needed was a small sample set of kids' faces, right? And so I took that back to the team and then it was a fun process working with design. We actually were able to create four different versions of these ink effects. So you're not seeing them up here right now, but there's a rainbow, galaxy, gold and silver. And since we shipped it this summer, in one note, it's just been one of these things where the feedback that you mentioned has just been through the roof. Like people find it really fun and engaging. And I like to tell this story mainly because it's a really good example of product management, both taking a small negative insight, but also I would say bucking the trend in a way because this was something that was not on our radar for the product roadmap. And we were able to be agile and just be receptive to the information we got and actually change our course and for the better, right? Like this produced a feature that was really valuable. But it was a fun story and I like to share that with folks. So it's a good example. And I love that we were actually able to build this because I mean, or even some people who kind of doubted, is it really that important on the team? But the feedback has been phenomenal. I forgot the one part of the story I loved it. Which is the first day we had the prototype of this, that you're right. If you think of the boardroom setting where people are using one note for their meeting notes, there were some doubters about, would this make any sense? Why would you use a rainbow ink? Right, right. And the first day we had a prototype, I walked into an executive meeting and I just handed the rainbow ink to one of our execs and didn't say anything, I just gave him the pen and saw him start writing with it in the middle of the meeting and his face went from this to this. And it was the only thing I needed to see, right? It was the best reaction. Exactly, and even, you know, we go to conferences all the time and talk to customers, teachers, students, all sorts of our users.  It's a demo pleaser. It really is, but it also works in the real. It's not just like a flashy thing on the screen, you know, when you're actually using the product, it's exciting as well. And I know you have an interesting story to tell too.  It's a bit harder. You might be able to go to a coffee shop and talk to people and maybe show them something, but it can be a bit harder. But you can still do it from the comfort of your own home by engaging with users online. And we kind of talked about this a little bit earlier where the whole team actually engages with customers and provides support directly to them, which is fairly uncommon, I would say, where you actually have the people who actually build the product working on it. And so it was that time when we were responding to customer reviews through the Windows Store. I think we actually, we almost broke the tool. We responded to so many users over such a short period of time, but we got fantastic feedback and the ability to engage one on one with these users just over email was amazing. And we're constantly on Twitter as well, responding to users there. And that's important for folks listening to this, right? Because you don't have to necessarily find a real world place you can go. We have the power of the internet and power of communities online. And you can learn a lot just by trying to listen and observe what is going on. And that was the last part I was gonna mention was it's the observation. It's the taking in of the input. Don't necessarily take every word, exactly what they say, but be able to listen to what's being said and interpret what that might mean if you're designing a product. Exactly, because it's definitely difficult to, you have to take all these different sources, all these different inputs, and then when you're done, actually prioritize a list and figure, okay, now what do I actually need to go build? And that's the trick, is figure out which sources are the most important or which ones have the most weight given the current dynamics on the team. It could be something that's very critical that you need to do, but we can actually do it in six months versus something that maybe needs to be done more immediately, it's a more of an urgent issue or something that will drive the business.  So at this point we've talked about how to identify who your users are and what problems you'll solve for them. And you might be tempted to just, once you know those problems, jump in and try to figure out what your app will look like and what features it will have to solve those problems, but it's important to slow down and really make sure that throughout that process you have users in mind the entire time and you take it step by step to figure out the best way to address their needs. So we'll talk about how exactly to identify and define the user requirements for your app. So are requirements the same thing as features or what exactly does it mean to define user requirements? Well, I think requirements have a more of a nebulous definition. It's more about what does the user really need? I think a feature solves a requirement. A feature gives you the opportunity to get over your requirement, right? But I wouldn't say that they're the same. Yeah, and most software companies, we typically define these requirements in a document that we refer to as a spec, really is a requirement specification. And in that document we kind of talk about there's two kind of broad categories of user requirements. On one end there is what does the user need the app to do for them? So we talk about what the software will do and those are referred to as functional requirements because it's functionality based. And then we also have the softer side of things is how much do they care about how fast it is or how much do they care about how accessible the app is. And those are non-functional requirements that focuses on the qualities of the software. So you wanna kind of think about both of these but for now we're gonna talk more about functional requirements and figuring out the functionality of the app. And what's your favorite way to define user requirements? There are a lot of ways out there, so what do you think is the best way to approach this? Sure, sure. Well coming from a user-centric design perspective I really enjoy the user's story which is essentially a way of getting to understand who the user is and what they need in a way that's a little bit more personal than something like a system requirement where we're just talking about what are the different features that the user might need. We're trying to understand the user a little bit better and then maybe we can make some choices that we wouldn't be able to see or even understand if we didn't really know the user. Right, so just to walk through a couple of these types of requirements. System requirements as Adrian mentioned kind of focus on things from the perspective of what your software will do. You might say the system should accept input for user account, something like that. And that's just focusing on functionality in a really specific way. Use cases are pretty thorough and you kind of break down how a user will encounter a certain scenario with your app, what will happen throughout that scenario and what the outcome should be. So the good thing about use cases is that they learn well to the development phase because everything is pretty well laid out. But I also prefer user stories because they won't change as much. You know what the user wants pretty much and you're focusing on what they want as an outcome and not necessarily how you're going to address them. So an example might be as a, what kind of app could we talk about? Like as a student, I want to... Find cell textbooks. Yeah, so that I can make money or make the most of my resources, right? So you want to make sure that you talk about what their end goal is and why because those will really help you make the best decisions during your design and development phase. And the end goal here is that, or the thing to keep in mind is that users don't always know what they want. So you can't just take everything a user says for face value when you're in your research and interviewing phase because as we kind of talked about, users know the end, the outcome that they want but they don't necessarily know all that's possible for how you can address them. So in the next video, you'll hear more about how you can kind of interpret user needs based on what users tell you and you'll hear from product managers at Microsoft who do this on a regular basis. So one of the most critical things that we have to figure out all the time is when somebody tells you something, do they actually mean that or do they really want something else? Right. You have an interesting example of this, right? Yeah, so one note for Windows 10, we released it when Windows 10 came out in June of 2015. But there was a lot of feedback because we had an app on Windows 8, one note app on Windows 8 that had a radial menu which was like a circle and with a bunch of commands. And it was very, it was cool. It looked great. It was fun to use with a pen but there were a number of issues with it. It didn't scale well as we added more features. It got really cluttered and you'd have to like dig under multiple layers and you wouldn't necessarily know that oh, to get to font color, I have to click on the edge of bold or something. You wouldn't think that. And so we redesigned the interface and came up with what you see here. But there are a lot of people who still love the radial menu. And so that was probably the- And they actually were like super, super passionate about the fact that we took it out. Yeah, they were very disappointed. And you know, it's hard for us like we lived it as well. It just, there was a number of reasons why we just couldn't continue to use it. But if we had been listening directly to, if we were just taking what customers said at face value, we would probably would have just, you know, built the radial menu and called it a day. But that wouldn't have worked for a number of reasons. You would have a radial menu plus the ribbon. And you know- And I think that that's what you're highlighting is this notion that a product manager oftentimes sees the product in a way that the users don't and we know more kind of the guts and what's going on inside the product. And we also know where we wanna take the product. Exactly. Right? And so those are inputs that a customer or somebody that our audience may be talking to, the folks that you talk to in a coffee shop, they have no idea about those. And so you have to kind of take what they say as one input, but not the only input, right? Right. So then the problem we had to solve was, okay, people love the radial menu because it's fast, it's easy to use. How do we make the interface just as fast? And we kinda look through everything and we came up with the full screen drawing modes. You get all your commands right away. And we got to a spot that I think was pretty good, but there was one key piece that was missing. And I think, and that we believe was the custom pens. With the ribbon, you could have multiple different pens. You customize the thickness and the color of each single, of each one. And we didn't have that today when we switched this one. You could change the color, you could change the thickness, but you couldn't save that. Right. And so I like that, we believe is like what the users really wanted. It was those custom pens and not the radial menu itself, which also has, there were nice things about it, but it wasn't the fact that it was round and small to people wanted. It was the fact that they had those custom pens and it was fast and easy to access. And so it's that kind of thing. They're really a piecing apart. Piecing apart, like what do the users actually, why do they like that thing? Why are they asking for it? I think there's like a great quote by Henry Ford. Yeah, like he used to say, if I asked people, Henry Ford, right? The founder of Ford Motor Company, if I asked people what they'd want at the time, back in like late 1800s, early 19s, they would want faster horses. They didn't know that, you know, we were trying to build a car. Right. And so you have to, again, take what people say and then think about it more deeply. What do they really mean when they tell you something exactly? Welcome back. So now that we've talked about how to identify the needs of our users and define those requirements and figure out what features our app should have, we can start getting into designing the user interfaces for our app. So how the user will interact with our app to achieve that functionality. So first let's talk about what is a user interface? What does that refer to? That's a very broad question. But a user interface, essentially, is just what the user interfaces with. So what do they touch? How do they interact with the application itself? And that can be something from a scroll wheel to a button that you might click to maybe touch controls on a mobile tablet or something like that. Right. And in this case for web apps, our user interface would just be those web pages that users access to interact with our app. So some things to keep in mind at this phase when you're designing user interfaces back to our user-centered design approach, we want to always be iterating and getting things in front of users quickly. So we want to prototype our app without focusing on too much detail in the beginning just to make sure that what we're thinking works for our user. So some things to keep in mind is design as quickly as possible. Don't waste any resources or too much time. Sketching is good at this phase. Get feedback and iterate. That's gonna be kind of the process of designing at this phase. Yeah, and I think one of the most important things that we can stress is do this all quickly because it's all about rapid iteration. If the user doesn't like something, change it. Right. And then show them the new version. If we spend months and months creating this perfect application that we think is great and the user ends up not liking it, then we've just wasted a bunch of time. So like you said, don't focus on the details, how it looks. These things are just gonna be distracting for the user once you talk to them. We were much more interested to know if we made an entirely redundant page rather than whether or not the user likes the blue color that we used. Exactly. So with that in mind, the thing that is most important to identify first are the things that everything else will be built on top of. And that's kind of the core functionality that your app will have and how users will interact with that. So with web apps, we kind of wanna keep in mind that users will be performing actions with information. They will be inputting things, viewing data, modifying and deleting things. So you want to think about which of those operations your app will emphasize and how you can support those operations with your app. And from there, you can start designing the layout at a high level to support all of those, that functionality. And then at that point, you can add the finishing touches on top with color and style and all of those visual details. So one way to start with that interaction is by doing what's called interaction design. You identify what requirements your app will support. You figure out what visual components and layouts can support those features. And then you can just sketch out a high level visual to depict that interaction. So let's look at an example of how this will look with Adrian. Sure. So let's say for example, that I want to create an email application. Fairly simple. I would assume that everyone knows how that works. Essentially you can receive emails, you can view your emails, you can send them out. Maybe there's some other features, but let's just focus on those simple ones as of right now. So typically you want to start with a landing page or your home page. So we'll start out with a simple rectangle that represents our home page. And maybe on this home page there is an inbox button and there's a compose email button and there's a check your drafts folder. So there's a bunch of different buttons that will take us to different pages. So let's say for example, we have an inbox button over here and that'll take us to the inbox page. So you can kind of see generally what we're doing here is mapping out the style and the structure of our application by representing each page with its own little box. So let's see. We also want to have a compose email button. So from the front page, maybe the button is down here and it'll take you to the compose email page. So now we have our inbox and we have our compose email page. But sometimes if you need to respond to an email, there'll be a reply button in your inbox page, right? So interestingly, a reply is just composing an email. So we'll see maybe we have a reply button here and that'll take us all the way down to our compose email page. And you can sort of see that as you get more and more into the details of how your design will look, you can start seeing that these maps will get a little bit more complicated as you go on. But keeping it simple with just boxes and maybe some very rudimentary button icons, you will be able to create something and see how it looks and keep it simple without actually going into huge amounts of detail. Right, and this is pretty easy. You see how quickly you were able to do that. It's a good starting point once you identify like what user needs you're addressing and the features that you want to support in your app. This is a quick and easy exercise. And as Adrienne mentioned, that's what we want at this stage. So from here though, we can start to fill in. Once we've gotten this in front of users and other stakeholders and tweaked it as necessary, then we can start to fill in what each of these pages will look like and talk about the layout of those interfaces. And we can do that with what's called wireframe. So a wireframe, just going back to the user-centered design approach, these should be low cost, low fidelity, meaning they don't need to represent like how the app will look in its final phase. They really focus just on using lines and boxes to depict the high level visual elements. And we don't include any color in wireframes usually. So the goal here is just to quickly sketch out what the visual components react might look like. So we'll continue with this email example and let's look at what a wireframe for this could look like. Sure, sure. So the difference I would say between a wireframe and just the interaction design is that our wireframe is gonna have a little bit more detail. For example, we're gonna see where on the page exactly should this button be because stuff like that is important to know early on because the entire structure of our web application might be changed by a user's, how the user uses it. Right, we wanna figure out those structural components before figuring out. Early on, as early as possible. So we'll start with a little bit more of a detailed landing page here. We'll just call our email client in look. Perfect. Very creative, I know. And in this page, let's just say we wanna keep it very simple. The user has three options. So here's a big button in the middle that takes you to your inbox. And we'll have another one for composing. And the final one, let's just say to view the deleted items, the emails that we've put in the trash can. So we have our three buttons. And now we need to map out what the other pages are gonna look like. So in the same way as earlier, let's just use the inbox as an example. That'll take you to another page. And maybe your inbox looks a little bit more like a conventional email. This landing page isn't really something you'd see in a lot of different ones. But we'll have maybe a bar at the top that'll tell you some information about your inbox, how much mail you have, maybe do a nice picture, keep it visually interesting. And after that, we'll have a series of emails in a list-like format. So we'll just, we don't actually have to fill these out with too much detail. They have all the different words and stuff in them. We'll just say, here's the subject line, here's who it's from, and here's a button on how to view it. So we have our inbox page all sorted out. That looks great. Now let's design the view email page. So this view button will take you down here to this view email page. And we wanna decide how this is gonna look. We want it to look clean and easy to understand. And the best way to do that is just to workshop some different ideas for the layout and then show them to users, see how they think. So we'll just start this out, maybe at the top we'll say, who's this from? So we'll say, this is from my coworker Bree. You have a little picture of her. And we'll have a subject line, and down here will be a box containing the text content of the email. So you see that this is a little bit more detailed, a little bit more in depth than the interface interaction design that we were doing earlier. And this gives us a little bit more room to be creative about how our application is gonna look. Now, I would really like to stress that this shouldn't really impact your final design. This is something that's gonna come over rounds and rounds and rounds of iteration and testing. But this can be sort of the skeleton that you build off of. So it's important to build something that the user really meshes with and is able to use very well. Right, and I think the details that matter most at this phase are identifying what data is necessary, because at some point you need to figure out how to set up your database and the structure of your app. So what matters more are the components that are database, not to say database, but how you'll store information, what information is necessary for your app so that you can start designing the technical side of it. And what matters less is exactly how what text you'll have at the top of the page and things like that. You wanna focus on the right details here so that you can figure out the most important technical pieces of your app in the next phase. And what you can do from this point as well is if you look back at Adrian's wireframe here, you have different boxes and you could draw each of these on a larger sheet of paper and maybe get them in front of users and actually have them click through by kind of just touching on different parts of the page and make sure that they understand what they could do from each page. Without even having real words or images on the page, they should be able to understand kind of a high level flow of what they could do with your app. Yeah, that's really important. A lot of times there are things that we don't even think about or can't even see about our designs that might be difficult or unclear to the users. So actually going out, showing them the physical paper representation of your prototype is a great way of finding out maybe this button is unclear, what does it do? Or maybe this should be higher up on the page because the users aren't seeing it until too late. Right, or there's not a button there and they don't really know what action they can take from your page. Things like that. And we talked about sketching on paper. You could sketch on electronically like we've done here. There are software and tools out there that are made for wirefaring specifically. You have a lot of options, but the point is don't spend too much time trying to ramp up doing something new. Just do what you can do quickly and get it in front of users. So to summarize the goal here is to, as always, keep users involved in your design process, sketch things out quickly, figure out the high level things before you get into the details and get your ideas in front of your users as often as possible. So thanks to Adrienne for helping us with this module. Glad to be here. We'll see you in the next video. Welcome back. Now that you've completed module one, you should have a clear understanding of how to go about planning and designing your app in a user-centered way. The user-centered design process we introduced you to should take you from the idea phase through user research and you should end up with an initial prototype in the form of wireframes. These wireframes give you a good starting point for building the layout of your app without focusing on the visual details and that iterative nature is at the core of user-centered design. Now in this module, we'll finally start writing some code as we introduce your very first web language, HTML. But in this video in particular, we'll start by reviewing some web development concepts and making sure you understand what tools you'll need to start writing code. One of the first things we should get out of the way is what exactly we're building and the proper terminology to describe various types of web technologies. So what is a webpage? A webpage is simply a document that displays web content via a web browser. So anytime you access a document on the internet using your web browser, that is a webpage. And many web pages are just static. They present information to the user as is. Like the page that you see here, this is text information and images and things like that. And every time you view it, it's not changing based on any interaction that you have with the page. It might change when someone updates the files. But overall, this is not a dynamic page. And since we mentioned web browsers, let's talk about what exactly a web browser is and what web browsers do for us because web browsers are important to understand when it comes to web development. So the web browser is the application that allows users to view and interact with content on the web. Web browsers are behind the scenes retrieving the content that we request. They send the request to web servers once we type a URL or once we click on a hyperlink, they're sending those requests behind the scenes. Once they receive those files back from clients, from servers, browsers know how to interpret the code, which is HTML and CSS, to display those web pages appropriately. And in addition to that, when it comes to developing for the web, web browsers have built-in tools that we refer to as developer tools that help author and debug code as you're working on your web pages. So browsers play an important role and there are several browsers to choose from. Everyone has their own preference and there are some differences between browsers. But it's a good idea to have at least a couple browsers installed, different types of browsers so that you can make sure your app or your web pages work and are displayed properly across browsers. So we talked about web pages, but what is a web app? So a web app is, the difference is that we add functionality and dynamic data. So a web app is a software program that is accessed via a web browser and allows a user to complete specific tasks or achieve specific outcomes. And this goes back to what we talked about earlier in the first module. So when it comes to functionality, web apps are presenting dynamic web pages. So they're presenting pages that contain data that changes as we interact with it that stays up to date automatically, things like that. So for example, being here that you see on the left is a search engine that is a web app because we use it for functionality. We type something in, the web app searches for that, those terms and presents information to us. All of that is dynamic information that's working with the database behind the scenes. Similarly, Stack Overflow. Stack Overflow, we answer questions. Stack Overflow, by the way, is a website that software developers use pretty heavily to share knowledge about software development. So people can post questions and other people can post answers to those questions and you can vote on answers. So all of those things that I just mentioned are functionality. We're adding questions, we're viewing questions, we're adding answers, we're voting for questions and answers. So that's the difference between a basic static web page or a set of web pages and a web app which is something that has functionality and deals with dynamic data. And that functionality that we talk about with web apps revolves around CRUD operations and that stands for being able to create information, read, update, and delete. So as I just mentioned with the Stack Overflow example, we're creating questions or even creating answers. We're viewing those questions and answers. Users are updating that information if they want to change their question or answer and they're deleting those things. So functionality revolves around these four types of operations with our data. So keep that in mind as you start thinking about the functionality your app will have. So how exactly do we program all of this? There are a lot of different layers and they work together to create the functionality of a web app. On the front end we have languages like HTML, CSS, and JavaScript. HTML is responsible for defining the content of your web page. So that's the first language we'll learn and for that we were just marking up the contents of our page and creating that basic structure of our documents. Then we add CSS on top of that and that lets us style and control the layout and presentation of our web pages. Then we can use JavaScript to create scripts that control the behavior of these web pages. So all of these languages work together but they rely on the HTML to create the content and then CSS and JavaScript modify that content for style and behavior purposes. All of these languages create the user interface of the web page or the web app which we refer to as the client side or the front end. Then when it comes to working with dynamic data we need a database to store that data. So the back end of our app has this database and then it has some code on the server that works with the database and sends this information back to the client side. And finally all of this code has to live somewhere and the server has to be hosted somewhere that people can access over the internet. You don't want people sending requests to your computer every time they want to view your website. So you host your website or your web app somewhere on a server and that's how people can access it online. So we'll talk more about each of these components throughout the rest of this course. When it comes to writing our code all of the code we write in this course will be written in a code editor in my demos. You could write code in a basic text editor but you should think about it like writing a paper or a document. You could always write a paper in a basic text editor that comes pre-installed on your computer but if you're writing a 30 or 50 page paper you don't really want to have to deal with spell checking and formatting and all of that handling font all on your own. So instead you might use a specialized word processor like Microsoft Word. The same thing is true when you're writing code. You don't really want to have to deal with all of that on your own. So code editors are specialized text editors that make that process easier. They automatically format code for you. They complete statements and make suggestions that make it quicker for you to write your code. The code you write might be highlighted in different colors to make it easier to understand and read at a glance. And there's even a lot of plugins and integrations that extend the functionality of your code editor even more. There are a lot of different code editors out there. Even more for specific languages. Some code editors are general purpose. Others are for specific types of programming. The code editor we'll be focusing on in this course is called Visual Studio Code. This is different than the generic Visual Studio editor. This is a lightweight free code editor that is available on all platforms. So you can access and download this code editor at code.visualstudio.com. As I mentioned, code editors are really helpful when it comes to writing code. And in the next video we'll talk about another tool that is extremely helpful and useful to software developers that you should consider using as you start developing for the web. Welcome back. So at this point, you should have a basic understanding of what components make up a web app and how web apps work and have access on the web. And you should be set up with a browser and code editor to start writing code. But there's one more tool that's extremely useful for professional developers and that's source control. And with me to talk about this, I have my co-worker Andrew. And we'll let him introduce himself now. Thanks, Brianna. Hello, everybody. I'm Andrew Byrne. I'm also a content developer here at Microsoft Learning. And I have some courses on edX as well. So I've studied electronic engineering in college, but I've spent my entire career in software engineering. It's been a long career and I've worked for many different companies. And it's great to be here working at Microsoft. I've been here for 12 years. My motto is always be shipping. So I'm big into shipping code. And I also love to help and people learn. That's why I'm in this group. And so it's a real pleasure to be with you all here today. And yeah, let's talk about source control. Yes. So why do we even need source control? Great question. So I put together this slide, being there done that. So how many of you have been in the situation where you're writing a paper or maybe you're already doing a little bit of coding and you want to make some changes but you're nervous about making updates to the files you've just created. So what do you do? You copy and paste and you create my file too or my code page number two. I think we've all been there. We've all done that. And so this is not really the version control we're gonna talk to today but that is kind of what we're doing. It's the idea of managing changes to files and that you care about. I'll give you another example. If we switch over to my machine and I'll open up my browser and if we go to a site on my machine, let's say we go to Wikipedia and in there, take any page. Maybe we're in edX. This is a course, I've done courses on edX. So if we open up their page here on Wikipedia, it's a public page. And the way Wikipedia works is a lot of people contribute to these pages so the pages are changing a lot. And over here on a tab, you see view history and when you look at view history on these pages, you see that there's an awful lot of changes have been made to this particular page. The revision history talks about who did what to the page. So that's just another example of version control and so it's all around us and when you're building code, when you're writing code, it's very important for you to understand that when you make changes, why you made those changes and be able to go back and forwards to code changes that you made so that you can maybe change direction in your code. And so that's what version control and version control helps you do along the way. And I think going back to your Wikipedia example, it's a thing to point out is that since so many different people are collaborating on the same code base, maybe we're text based, maybe if someone makes a mistake and puts something that's completely inaccurate, if we didn't have that version control system, you would have to just manually go and figure out what they changed. That's exactly right. This lets you quickly roll back. So let's take a look at what we're talking about when we mean version control systems on this court. So this is something that most developers use, right? And like we talked about, the most fundamental thing is that version control systems allow you to keep track of sets, versions of your code or any type of set of files over time. That's correct. And again, bringing it back to the developer space, the majority of developers in a recent Stack Overflow survey all claimed that they check in code multiple times a day. And so what is this check-in process they speak of? Well, that's source control. And also, just to be sure, the terminology changes, so source control, version control, revision control systems, they all are interchangeable and we'll probably use the terms in this course. I didn't even notice I was using them differently because they pretty much mean the same thing. So, but there's lots of options for this and there's lots of tools available. I mean, Microsoft has had many versions of tooling in this space. If you've heard of Team Foundation Service, which is TFS or Visual Studio Team Services, VSTS, which is the more one that's come out in recent years, and Open Source has done a great job in giving developers tools in the space. Mercurial, subversion, and last but not least, Git, which is what we'll talk about today, is an Open Source version control system. And that's been really that evolved in a very open source community fashion it came. It was driven by the needs of the Linux kernel project. Linus Torvald himself got involved in the design. And so it's evolved because of its speed, its flexibility, and ease of use, I suppose. It's now widely adopted across the developer community. And that's why we're gonna give you a brief intro to that today. Yeah, so we'll talk about the workflow of using version control within the context of Git. And some of these things are similar with other systems, but there are a lot of differences. So in this case, we are focusing on Git. Yeah. And the first thing you would always do is create a repository, right? You want somewhere to store your files so that you can work on them, make changes. And then the checking in, as we talked about, is sometimes called committing changes. So you make a commit of a set of changes that you want to store as a complete version. And that's pretty much the poor functionality of Git on its own. Yeah, that workflow works in tooling that we'll see.  So, but it's very important the terminology you brought up, Brianna, is kind of the core terminology. There's a thing to store your code, which is a repository. And we do commits, which are these check-ins where we're actually committing our changes back into this storage. And we're rinsing and repeating this process as we write more code, as we fix bugs, and so on. And as we progress in this part of this course, we'll show you what that means when we're doing working together, collaborating, and sharing code. Because now this first control becomes really important, because as you said already, I want to see Brianna's changes and my changes, and we need to be able to go backwards and forwards on that. Exactly. So we won't demo Git on its own, but we will, as Andrew kind of talked about, talk about another tool that works with Git, which allows collaboration with code. And you can also use GitHub on its own individually, but the core of this is collaboration. And you can think of GitHub as kind of a cloud that doors get reposed online, so that people can access them. That's exactly right. And I think, again, it's code hosting platform. But people, I've used Git to store text as part of my work. It's used by open source projects, companies, and individuals, and it's really a great platform to share code and contribute to other people's code. And the contribution piece is really important as you're starting out in your career as a developer. Developers work in teams. It's a team sport. I like to call it. And so GitHub and places like GitHub, there's other vendors do stuff, Bitbucket is another one. But these places online where you can contribute to other people's code, it's a wonderful way to learn how to write code, to get well known, to build up your reputation. So I think I'll jump in and maybe start there. Why don't we show you what it looks like to be on this site called GitHub and to create your first code repository or repo? I'm going to use that phrase from here on. It's easier to say. Sounds good. Let's take a look. Okay, so let's go over to my machine and go back to my browser. And I have an account on GitHub. So we'll start there.  Now, this is the public view. How do I know that? I know it because I'm not signed in because on the top right, it says sign in. And so this is what you would see if you go there now, you would see this. All it's showing you is a picture of me wearing shades which you can change thankfully into anything you want. It's a little bit of profile. Some organizations I belong to on GitHub. So I'm in Microsoft, I do a lot of coding there. But a lot of the, in the center area here, you see some repositories, repos that I have pinned just to make them more accessible to people if they come to my site here on GitHub. So again, everybody who gets an account on GitHub will have a github.com forward slash username as their landing page. I really love this view down. If I scroll down, you see this contributions dashboard. So the geek in me loves to see how much coding I'm doing. And so the darker the green, the more check-ins I've done that day. So let's roll over. July and August was actually very busy for me. I was doing a lot of work on one of my courses and happened to be just merging a lot of code. And so you can see like on the 17 of July at 23 contributions. So a lot of cool info along here. If I scroll back up, that's my overview of my presence on GitHub. If I look at the repositories tab, it's a list of all the public repos that I have available for people to consume and we'll show you how to consume those in a while. And then people who are following me is in the followers tab and then following is people I'm following, et cetera. And I think it's worth emphasizing the community aspect of GitHub and sites like this. Like you mentioned on both the collaboration front being able to find something that someone built and you want to contribute to and you don't know the person. And also to just showcase your work. Employers ask for GitHub profiles sometimes. So it's really good to- Absolutely, I spend a lot of time on one of my courses explaining that and the fact that it's a great way to go and learn and contribute. And when you're ready, you're not always going to be ready to contribute to these online places. You might feel you're not ready just yet, but when you are, it's great to just get in there and there's sites that you can go to that will show you what repos are looking for contributions and you contribute straight away to someone else's code. But for now, let's pretend, let's go back to the idea of creating your very first repo and I'll use my account because it's simple to do that.  So under the repositories tab or back in the overview, sorry. So the first thing I forgot to do is I'm not signed in. So as I said, I'm not signed in. I can do nothing. This is the public view, but I did open up earlier on a view of me. I think that's signed in, yes. So just to save some time, I don't want to take out my phone and do authentication and all that stuff. I've just logged in already. And here I am and my little profile picture is up here in the top right. I have a different view now if you know, what you see here is the repo count has gone to 35. That's because it's showing me I have private repos as well. So when you're in and you're logged in as yourself and you go to your own profile, you get a bit more information about your presence. So let's create a new repo. I hit the new button and because we're going to show you maybe GitHub and source control in the context of these web apps, why don't we just name this repo something like hello web app. So here I've typed in a name that's unique to my organization, to my account, Andrew J. Byrne. So I'm going to create a new repo called hello web app. I can put it in the description. No need to do that now because of time. I'll keep my repo public. What does that mean? It means as soon as I create this, Brianna could go straight to my account and see this repo, which is probably what we want to do here for the demo. And then you can also make them private. You can initialize the repo with a readme. A readme is just a text file. I'm very handy. Everybody expects when they walk up to a repo, especially a code repo that it hasn't readme file because it's there they'll seek first some information. They'll go there to see what the developer has said about what's in this repo. So this is where you put useful information. So I'll initialize and have GitHub create a readme for me. Now I'm going to hit the create repo button. And in no time at all, there it is. It's created. So the repo was created and it's launched me into that page. So I have Andrew J. Byrne. Hello, web app is my repo. Here we are in the default view for the repo. It's because I only got one file opened. It's shown me by default that file open, which is readme.md. And the contents of that file is just hello, web app. So I have one file. You can see I've made one commit, which I'll talk to you about in a second. And I can do lots and lots in this particular view. And we'll do lots and lots in this view right now. So the first thing I want to do just to bring this back into the idea of writing some HTML is to upload some pre-canned HTML again to save me some time. So I'll click on the upload files button and I can drag them over or I can choose them from my browser. So I'll open up, I'll do choose your files and I'll select hello.html and hello.css. Now it's early in the course. We've gone through some very early stuff for you and we haven't delved into what HTML is in detail or CSS. Don't worry about that, this is just a demo. I'm uploading files. I could have uploaded hello.txt and it would have been a text file that I would have uploaded. Here I've put those two files in and I'm going to commit those changes again into the repo. Commit is me saying basically, yep, I'm ready to store those in my repo. I'll commit those changes using the big green button. And once I do that, it's processing my files, which means it's uploading them into my repo and the view changes and updates to show me these two files. So now in my list I have a read me, I have hello.html, I have hello.style.css and if I click on one of those files, like hello.html, we see voila, we see a little bit of HTML code. So the next thing I'd like to do is let's take that down onto a machine so that we can run or preview this HTML so you can see what this is actually doing. I think if you're any way familiar with HTML, you know exactly what this piece of HTML is going to do. So- And also right now, I'll just, before you make any more changes, I'll, to be a good team player, join your repo. So I've navigated to your GitHub page and now I see your HelloWeb app uploaded 34 seconds ago. There's just the top, okay, cool. So I'll go ahead and clone that down too just so that from this point on, I can have access to your repo. Okay, so we're both going to do that. So from my machine to do the same action whether I'm the owner or not, both of us are going to do this action. So from the main page on the HelloWeb app page, we'll click this clone or download button. And there we have this ugly enough URL or address for this repo. And I'll just copy it so I can click on copy to clipboard, which it's done. And then I will open up one of my favorite editors, which is Visual Studio Code. And you're following along, Brianna, I presume. Yes, I am. Okay, and now we are in here. I'll just remove some stuff and then I'll close this one I have open. Let's have a nice blank start to my Visual Studio Code and close that message. So here I'm going to, in the welcome page, which you can get to by going to help and then welcome, okay. There's many ways to get to this page, but this is one way. Go back to the start page or the welcome page in Visual Studio Code and click on clone, get repository. And all it looks for is that address, if you remember I said copy to clipboard, so I will paste that into this particular command bar. And it asks me where do I want to put it and it doesn't really matter. I'll put it under C, C code demo and hit return, hit enter. Would you like to open the repository? You see it's been very helpful. Visual Studio Code has been very helpful to me. I could do all this in the command line, but it's doing it for me all in. That's the code editor. That's what code editors are for. So I have this big open repository button. I will click on that and it launches what I downloaded or what I cloned, cloned is another word I suppose for download, although there is a linkage back to the original, but think of it as just, the files are now coming down locally and they're in my Visual Studio Code. And I have my hello HTML, hello stars at CS and readme.md. There's my HTML file that you did see up on GitHub. I've installed a little extension for Visual Studio Code which allows me to quickly preview this over in my favorite browser. And we'll show you or we'll give you a link as to how you can install that extension as well. So if I do control, sorry, control KD, well, control KD, it launches into my browser. So again, very early days for you understanding HTML and CSS, but take your time and we'll explain as we go. And again, we're just showing you the version control which you'll get familiar with as you progress. And all we've done here is we've opened the browser, we've given the browser that address to that page that is local and the browser has requested that page. It's uploaded, it's consumed that page and rendered it for us using the HTML that was in that page. I could do all kinds of stuff here. If I view the source, for example, you'll see down here, it'll show that exact same code that we've seen. But we won't get into that now. That's going a little bit deep. All I wanted to show you was that the page can be previewed now very easily from VS Code and it's local. So how about you, Brianna? Do you want to show that as well on your side? Sounds good. Okay, so I have your GitHub profile up and I see that you've uploaded this, created this repo HelloWebApp six minutes ago. So I will go into that. So long ago. I know. So I see your files here and I'll click the same green button to clone or download. Copy that URL over and switch to Visual Studio Code which I don't have open yet. Have Visual Studio Code open and I'm on the welcome screen. So I'll use this clone get repository prompts, paste that URL that I copied from Andrew's profile and I'll save it in this folder. And it's asking me if I want to open the repository which I will do. So now I see those same files that Andrew created and I also have the plugin installed to preview. So I'm just going to use that shortcut to open this in my browser and we see the exact same. Great. Yeah. So there you go. Like what we have so far what we've demoed to you today is there's a thing called a repo. There's a place called GitHub. We store these there and other places. That's just, that's one of the places we can do it but that's good for you, for examples. I created some text files which is a HTML file which is going to be used in our web apps and then cloned.  I'm going to show you that next but I've basically cloned the repo and Brianna was able to do the exact same thing even though pretend we don't know each other she just found that cool repo online and liked it and started to look at the code and that's what sharing is all about. There's no blockage if once the repo is public anybody can take the code and use it. So here we are and the next thing I'll probably show you is what happens if I make a change. So I prefer a much more personal touch so this says hello world but I'd like it to actually say hello Andrew because you know that would be nice. So I'm going to go back into my machine and here I am still in the code. I'm in the hello.html page and again we're going to cover all this HTML in detail later on in this course. For now just focus on the text that you see in front of you which is hello world and all you need to know is that that little tags that it's between tell it to display a render at a particular size inside the web browser. So I'll just change that to say hello Andrew. Actually I'm going to say hello Brianna. How about that? There you go. And then I can save that on my machine. When I save it watch what happens so I don't know if you saw that but on the left hand side of Visual Studio Code it went from showing me an indication up here in this unsaved file that says you've won unsaved file. I saved it and then GitHub this little source control icon which is this kind of fork icon here on the left bar when you click on it it shows me hey you've changed something locally and it says I've changed the hello.html file. So Visual Studio Code is really working behind the scenes here and it's detecting changes and it's doing that because it knows Git. Git is what's running here. And so what I will do is I'll double click on this hello.html file just to show you the change. Let's step back. So I've double clicked the hello.html file inside that GitHub change log if you like the source control change log and it's actually showing me and highlighting in wonderful colors what I changed. It's saying that I changed that word world to Brianna. So getting a lot of value at a Visual Studio Code integration with Git and I'm also the power of Git showing me the history of this file and the change I'm about to make. So it's all local. I haven't, I've made the change, I've saved the file but I haven't committed it to my repo and I haven't even committed to my repo locally. So the idea next is that I would make this commit. The commit is the act of committing the change into my storage, into my repo and you always should produce a message with each commit that you make. So what I will say inside this little message field I will say something like make message more personal. And if I hit the little check mark that will make this commit. My check mark, my little hand as you can see it says commit there as a tool tip. I'll hit commit and it says you'd like to automatically stage the changes and I'll say yes and the commitment has, the commit has been made. So that's going into my repo Brianna but guess what? If I look on, I'll just go to my browser and if I go back to my actual browser itself I'll just refresh this page. I go to hello web app and I look at my code I see hello.html is there but it still says hello world. So I've committed my changes. You have to get your head around some of these this kind of way of working. I've committed my changes to get to my repo but it's all just been done locally at this point. The next stage is what we call a push. So I'm going to do a push back up into GitHub. So I'll go back to Visual Studio Code and there's many ways you can do this. I like to select the three dots and choose sync. And all sync does is it would do synchronize in both directions but it's just doing the push. I can also do a push, why don't we just do that? So I'll hit push and it will take whatever changes I've made locally inside my repo and it will synchronize that up to my repo online on GitHub. So I'll hit push and you can see it's busy. I got a little clock icon. I got a little progress bar. It's taking its time. Everything goes silent. Let's see what happens. I'll go back to my browser and go into my GitHub repo. I'm still on that page that I was looking at. Hello world, but if I refresh it now I wonder, there you go. Hello Brianna is online. So I've made a change locally. I've committed it locally to my repo and then I've used Visual Studio Code to make some Git commands. Everything behind the scenes is Git and you can learn about those things at another time but the Git command is the push command which will send my changes back to my repo. It has the intelligence to know that this repo that Andrew has locally is actually linked to an original, an origin repo up on GitHub with this particular address. So there's my changes. I wonder, yeah, can maybe next thing to do is show a pull. So I've done a push which is pushing the changes up. Yes. So if I go back to my local repo that has your files in it from your repo, clone of your repo, nothing, I don't see any changes that you've made because I've pulled this down before you made those changes. Okay. So I can go to that same source control view and Visual Studio Code and this is something I would do if I, you know, I'm curious to see what changes have been made or I want to make sure I have the latest version. So I'll use this pull option and we have that same UI. That was pretty quick. I think it's done now. So let me look at the latest version of these files. Oh, it's already open right here. Already open. So I have hello, Brianna. Let's see what that looks like in the browser. Okay. So I'll open that preview and there it is. That's much more personal. So that's kind of a whole round trip. That's actually what we've done there in that little demo was the full basic GitHub workflow. So created a repo, added some changes, clones us locally, did some work, pushed changes back up to the remote repo, then someone else pulled those changes down or I could pull them down on another machine, whatever. So it's all this flow it's all taken care of. If I was to go back, let's just go maybe briefly back to the hello web app on my machine inside the browser because one thing you'll see once you're in GitHub now, actually this is not, yeah, I can show you here. If I look at that file, hello.html, it has a history. So there's a history button here. When I click on it, Git is behind the scenes and all the work to show you the history that we've done is all available here inside GitHub. You can see that my last commit was called make message more personal. And if I click on this ID here, it will show me inside a kind of comparison view. It shows me that the red means I deleted or removed something and the green means I added. So I've removed the world, that word, and I've replaced it with Brianna. So even in GitHub, the power of Git is now shown to you in a lovely visual UI, a great user experience for that as well. So that's really all I wanted to show today. It's just this brief intro to source control and Git and GitHub. Yeah, and our goal here, there's so much, this is a core workflow that a lot of people can use and there's opportunities to extend that depending on the scenario, but there's more to learn about Git on its own. There's more to learn about working with GitHub. And Andrew also actually has a writing professional code course on edX where you cover a lot more of that, right? I do, I cover the command line and I go into more depth into what each of these commands mean and I add some more in terms of, if you've ever heard of a pull request, if you're no developer, they'll probably mention pull request to you. And so we go into some more detail about how you would do this in a professional scenario where you might have multiple developers on a team. And so we go into that more, it's called writing professional code and it's on edX and we probably show a link at some point. We'll link it in the course resources here. And what we've covered so far is enough for the rest of this course. So what we've covered, you'll be good for the rest of this course so that you can manage your code as you learn more about building web apps. But if you finish this and you're interested, go ahead and check that out. And thank you for being here with us to introduce this topic. It's been my absolute pleasure. We hope that you see the power and the need to use source control with your code and have fun when we get to the next video writing our first HTML code. So I'm sure at this point you're ready to finally get into some code and that's what we're going to do in this video. We talked about the components of web applications and now we'll get started with the first language we'll need to build web apps which is HTML. So let's talk about what HTML is and what it's used for. HTML stands for Hypertext Markup Language. And there are a couple of things we can take away from that acronym. Probably the most important is what type of language HTML is. So being a markup language means that HTML is, we're not really doing anything new with HTML. We're not creating any sort of action or behavior. We're really labeling content that we have for our web pages and giving it more meaning and describing it. So markup languages are used to markup or annotate or label things. And with HTML we use what we call tags to mark up the contents of our page. And the reason that's important is because tools like browsers, search engines or screen readers and other types of third-party tools need to be able to look at the content of our page and understand what's on it and how to use that content.  Everything on our page is interpreted in a slightly different way. And HTML allows us to describe those different types of content. And in the case of browsers, browsers use that information to actually display our web pages properly. So without any sort of styling, we can just use HTML and our headings might be displayed differently from the regular text of our paragraphs, for example. And just to make sure I explain the full acronym, the other word we haven't talked about is the word hypertext. And that might sound familiar from the acronym HTTP, which is the language that web servers use to communicate with clients. That stands for Hypertext Transfer Protocol. Hypertext is an integral part of how we use the worldwide web. So these documents, the web pages are hypertext documents. They're HTML documents. And hypertext just refers to a document that contains links directly to other documents. So when you go to a website, you expect to be able to click on a link and access something that's related and be taken directly to that web page without doing anything fancy or complex. So HTML allows us to create hypertext documents. So let's take a look at how we use HTML to build our web pages. If you think about the kind of content that you usually see on a web page, it's some combination of text, like headings, paragraphs, different types of lists. You might have images, videos, and other types of media, and the list goes on. So HTML is simply a set of specifications for these elements that we can use on our pages. And each element consists of a set of tags that we use to create it. We do this by wrapping the tags around the content that we are trying to mark up or label. So you would use a start tag before the content, and then an end tag, which usually has a forward slash before it after the content. And all of these tags are surrounded by angle brackets. So for example, here, this is a line of HTML code that uses the P tag, which is for the paragraph element. So we start with the P tag, then we have our contents of our element, which is the actual paragraph text. So in this case, this is my paragraph text. And then once we're done with the content that we actually want to be displayed on the page, we finish with the end tag. So everything in between that start and end tag is the contents of the element, and that's typically what's displayed on the actual webpage. Now it's pretty hard to become familiar with the details of every single HTML element that you could possibly use. Instead, you kind of want to learn the most common and fundamental elements that are the building blocks of webpages, and then use reference documents when you need to learn more in certain scenarios. So here I have linked the W3C reference for HTML, and W3C is the organization that manages this specification. But in the rest of this video and demo, I'll demonstrate the use of some of the most common HTML elements that you'll need to know to start off. And with that being said, the best way to learn programming or to learn a new programming language is to see real code and to get your hands dirty. So I'll jump right into a demo where I'll show you how to start writing HTML code. So I've just opened Visual Studio Code, which is the code editor I'll be using for this course. And I'll go ahead and open a new folder to work with for this demo. So I'll use the open folder option. I'll create a new folder, let's just call it demo. And then I will select that folder and Visual Studio Code will open it to make it easier to work with files in that folder. Now from here, I don't have anything in the folder yet. And in this demo, we'll go ahead and create a Hello World program. So for those who don't know, Hello World is the traditional first program that developers write when they're learning a new programming language or learning their first programming language in general. It's really simple. You're just creating a program that outputs the words Hello World. And because it's so simple, it's a great program to start with for every language you learn because believe it or not, it can be the code for the Hello World program can be pretty different between different types of programming languages. So doing this exercise really shows you the essence of a new language so that you can understand the basics and the syntax and things like that. So we're gonna start with Hello World and HTML. So the first thing I'll do is create an HTML file to write my code in. Visual Studio Code has these helpful icons here in the folder view. So I'll do the new file option and then I'll type hello.html and press Enter. That will create a new file for me. And now I'll start writing my HTML code. You can see that Visual Studio Code now knows that this is an HTML file. HTML files always need the .html extension. So the next few things I'm gonna write are pretty common for starting an HTML file and I'll explain them a little bit as I go. So first you always wanna start with an doc type declaration. And this just tells your browser that you're working with an HTML file. Next we have the tags that create the structure of our basic HTML document. So everything that you're gonna work with and write is going to be nested inside of an HTML element. So I'll show you what that means in a second. I'm just gonna create my start and ending for open and closing tags for the HTML document. And then everything I write is going to be within these two tags. And the first section of your file is called the head. So you're gonna create a head element and this just contains all of the metadata about your HTML document such as the title, language specifications, links to other resources and things like that. And for now we're just gonna put a title here. So I'll use a title tag and give this webpage a title. I'll call it Hello World. So in this case, Hello World is the actual title and we're wrapping that with the title tags. And since that's the only thing I'm putting in my head section, I'll go ahead and close my head element. So just to demonstrate, we talked about tags but we didn't talk about nesting elements or nesting tags. So in this case, the HTML element contains these other elements. It contains right now a head element which also contains a title element. And we would say that the title is nested inside the head, the head is nested inside the HTML element and so on. So in this case, the contents of the title element are the text Hello World, but the contents of the head element are is the title element. So next we're going to move on to the body section. And in this case so far, everything in the head element is just metadata, meaning it's not anything that's displayed on the body of your webpage. But the body element is actually where you will write all of the HTML for things that you want to put on your page. So I'll go ahead and create the body with the start and the end tag. And just to demonstrate right now what the title does, if I go ahead and use the plugin that I have installed in my code editor, I'll open this page in the browser and see what we have so far. And you see, we don't have anything on the actual body of the page. We just have a title here at the top. So that title is used here in the browser. It's also used in search engines to display the title of your page and things like that. So I'll go back over to Visual Studio Code and let's just put the text Hello World on the webpage. So I'll just add that text here. Just a note about Visual Studio Code. You can see that as you type, you have some visual indicators when you need to save your file, this large dot here. So when I use my save shortcut, that goes away. So now that I've saved and I've added this text here, I'll switch back to my browser and see what this looks like and refresh. So now we have the text Hello World on the webpage. So that's it for the first Hello World demo, but we'll keep going. I'll switch back over to my code. And right now I haven't really used any sort of tags around my Hello World text. It's just right there in the body, meaning it's something on our page. But we can get more specific to describe what type of content this is. Let's make it a heading, because it's kind of like a greeting that we're gonna have on our page. So we'll use an H1 tag. And you can see as I'm typing here that Visual Studio Code gives me some help with all of the tags that I have available. And when I start typing, it narrows down. And the type of heading that we're about to use is an H1, but you can see that there are six for us to choose from. And H1s are the largest headings or the most important content that we're labeling. H6s are the smallest or the least important. So we're gonna use an H1, because that's our main greeting on the page. And then it looks like I deleted some text. And I'll wrap this around the Hello World text. And now that should be displayed as a heading. Let's switch back over. Now we see the difference between how the browser interprets just regular text versus an H1 heading. So that's a pretty simple Hello World demo. And it kind of shows you the essence of how you write HTML code and what the basic syntax rules are. Just to recap, you use tags to surround the content and to label things that you have on your page. And what we have here are the most basic necessary elements that you use to structure a webpage. You start with the doc type at the top. Everything else is nested inside of your HTML element. You have a head section and a body section. The head contains metadata. The body contains all of the actual contents of your page. And the next part of this demo will move on and create a webpage from scratch with some more elements that are most common to use. So now we've completed the Hello World demo in HTML where we learned the basic HTML tags that most HTML webpages will need to get started. And now you should know the basic structure of an HTML file and how to get started with writing some basic tags. So now we'll move on and create a webpage from scratch that has some more realistic content on it and uses some more complex HTML tags. If you look at my browser, you see this sample webpage I have open. And when people are getting started with HTML and learning web development, I recommend finding some realistic content or something that you care about personally and using that to build something that you're invested in as you learn and practice. So for me, my favorite food is the sweet potato. So for this demo, we're going to be creating a webpage about sweet potatoes that just has some basic information and fun facts. So the page I have open in the browser right now is the end goal that we're going to be working towards in this demo. Keep in mind, this is a styled version. So it does have some CSS applied to it, which is controlling the color and layout. And for this demo, we're just going to focus on getting all of the content that you see here into our HTML file in an organized and structured way. So just to look at what this page contains before we get started, we have some title content at the top just to label the heading of this page, sweet potatoes with an exclamation point. We have a form over here on the side where we'll ask users or visitors to submit their favorite way to use sweet potatoes. And then in the main part of the page, we have some text and an image about sweet potatoes and some fun facts. And then at the bottom, we just have a small footer which contains just like a basic note about who created the webpage. So let's switch over to the code editor and get started working on this page from scratch to get the content out into the HTML page. So I have Visual Studio Code open with a new empty folder and I'll go ahead and get started with the new HTML file for this webpage. And I'll just call it demo.html. So I'll kind of walk through this part quickly since we've already talked about this but I'll add the basic metadata tags for the page including the HTML tag, the head and the body along with the title for this page. So I'll title this, I'll just say all about sweet potatoes and make sure I close this HTML tag. So now I have the basic structure for the page. Let me just open that in the browser to make sure it, I did everything correctly. So you see here, we have the blank webpage and the title showing up correctly. So no errors or anything. So I'll go ahead and switch back. So if you think back to the webpage we just looked at for the final version that we're working towards, we have some generic sections of content on our page that we could group together thematically. And HTML actually with HTML5, which is the latest version of HTML at this time has introduced semantic elements. So these are elements that are used to define sections of content on your page. They don't change how the content on the page is displayed. They're not really elements in the sense that they're defining a specific piece of content, but they group certain parts of your content together to show that content has a certain type of meaning as one. So some of the semantic elements that we can use include the article element, which is used to define an article of content on your page. You have the header and footer, the aside, which is used as a sidebar, and things like that. So you can see that the names of these elements really are clear to explain what type of content they're labeling. So I like to start when I have a lot of content on my page that can clearly be separated like this. I like to start with those high level semantic elements and put those on my page first. So if you think back to my page, I did have a header. I had content that is just a big title on the page that won't really change. I'll use the header element for that. And within that, I had an H1 tag, and I'll title my page, it was just called Sweet Potatoes. And that's it for the header for now. Next, if I were to go from left to right on each level of the page, I have a sidebar on the left-hand side, and that's where we have the form to ask people for input about their favorite ways to use Sweet Potatoes. So the semantic element that's most appropriate for that, since it's a sidebar and it's not the main content on the page, would be the aside element. So I'll use an aside element. And then within that, I have headings for the form. I think first is an H2 heading, and I will, what will I label that? I'll label that share your favorites. And below that, I'll use an H3 to make it a subtitle, and I'll give a more detailed description to say share your favorite ways to use Sweet Potatoes. Under this heading and subtitle, we have the form is where we'll ask people to input their ideas for using Sweet Potatoes. Just to start with the basics, I'll skip over the form details for now, but as a placeholder, it's helpful to use comments in your code. And in HTML, the way that we write comments is we start with the same angle bracket for tags, and then we start that tag with an exclamation point, just like with the doc type. That kind of tells that we're not writing a real HTML element. And followed by two hyphens. So you can see that that changed everything afterwards into a green text, and the code editor kind of helps you highlight your code based on what type of code you're writing. So everything from this point will be considered a comment until I close out the comment. So here I'll just say add form to ask viewers for input. And to close out the comment, I end with two hyphens and the closing right side angle bracket. Now this line is a comment and it won't be interpreted as HTML that should be displayed on the webpage. Okay, so that's it for the aside. And next to the aside on the page that we're going for, we have the main content. And for that, we will use the semantic element, which is called an article element. And the article element is intended to be used for to group content that could be isolated and on its own separate from the rest of your site. So if you have any blogs or if you have some content that stands on its own within your page, then the article is an appropriate semantic element to use. So in this case, I'll use an article for that main content that talks about sweet potatoes. And that content starts with an H2 that says all about sweet potatoes followed by a subtitle. So an H3 that says the best vegetable there is. Next, I have a paragraph that just gives some basic information about sweet potatoes. I have that on my clipboard. So I'll just paste that paragraph in and then close out the paragraph tag. So that's the paragraph I have for that section. Under that, I'll add an image. So for now, I'll also skip that and put a placeholder for a comment just so that we can start with the basic text and then come back to the more complex text. So I'll say add sweet potato image here. Next, we had two more sections. The first is a section that is titled top producers of sweet potatoes. And in that section, I listed in order the top, the countries that have the highest production of sweet potatoes. So I'll introduce a new HTML element here. Since we want to list things and we want them to be in order, the tag that we'll use here is called an ordered list. And what this means is that HTML will interpret this list as having the first element, the first item in the list being ranked higher than the second and so on. So I won't be numbering these items manually as you'll see, but that's what HTML is for in a way, it gives meaning to the contents that it's known by the browser that the second element should be labeled number two or letter two and so on. So the tag that we use for an ordered list is OL. And actually before that, I'll just give a heading to this section before I actually get into the list. So I'll use an H4 since we're getting into the actual subheadings of the article. And for that heading, I'll say top producers of sweet potatoes. Now I'll use the OL for ordered list. And for ordered list, the OL tag is the structure that holds the items. But within that, we have to nest additional elements that hold each item separately. So in this case, I want to list three items in my list. So I'll use three LI tags. LI stands for list item. And the list item is where you actually put the content of each item in the list. So the first country, the top producer of sweet potatoes is actually China. So I'll write that here. Then I created a separate LI element for the next list item, which is Uganda. And then the third, which will be Nigeria. Once I'm done entering all the elements from my list, then I close out the structure, which is the OL tag that holds all of those items. So these are nested elements. The LIs are nested inside of the OL tag. And then the final section I had in my article was fun facts about two potatoes. So I'll use another H4 since that's kind of the same level of subtitle as the previous section. And I'll say fun facts about two potatoes. Actually, I'll just say fun facts. And in this case, since my facts don't have any particular order, I just want them to be in a bulleted list. So in this case, I'll use a UL tag, which stands for unordered list. And the browser will display this as a bulleted list. So I'll go UL. And then the same way I add list item elements to that, my first fun fact will be that sweet potatoes are only distantly related to potatoes. Maybe you're also learning about sweet potatoes throughout this lesson. So that's double the value. The next fun fact will be that the flesh of sweet potatoes can vary in color. Let's see. So include white, red, pink, and purple. And then finally, the final fun fact will be that it is a misconception that orange sweet potatoes are the same as yams. They don't refer to the same thing. So now that I've added those three items, that's all I want. I will close out my unordered list element. Make sure I save frequently. So that's it for the content that I have. And then let me make sure I close out the article, because that's all of the content I have for the article element. Now beyond my article element, the last semantic section that I have is the footer of the page. So I'll go ahead and add a footer here. And within that, I just had a paragraph element. And I'll just put some basic text. I'll say developed by Brianna. And that'll be it for my footer, so I'll close that out. So I'll save that. And let's go take a look at what this looks like so far. Remember, we're not expecting the layout to be anywhere near what it was in the version I showed you, because that used CSS. But we should have the content there. So let's see. If I refresh the page, we have the content. And we do not see the comments that I put. So that's something to notice too. We don't see the comment for the form that's going to be right here. And we don't see the comment for the image that will be right here. Even though in this file, we do have the comments here. So remember, comments are just notes to the developer or anyone looking at your actual source code. But they are not interpreted by the browser or whatever program is running your code. So let's go ahead and add in a few more elements to this page and fill in the gaps. One thing I want to do before I forget is add a hyperlink to a recipe when I, in this paragraph where I'm talking about the options for cooking sweet potatoes. So I have a recipe that I want to link to for baked sweet potatoes. And I want the text to still say baked. But when the user clicks on the word baked, I want them to be redirected to the recipe online on another website for baked sweet potatoes. So that kind of means that this whatever element I use needs to still show the text baked, but it needs to have some additional information for where that URL is pointing to or the address of that link. And that introduces the need for attributes in HTML. So attributes are additional pieces of information that go in the start tag of your element when you define it in your code. And what attributes are used for is to provide additional information that is not part of what's displayed on your web page but helps define the content of your element or how it's displayed or how it should be interpreted and things like that. So in this case, we are going to use an a tag, which is an anchor tag. That's what we use for hyperlinks. And within the a tag, since we don't want the hyperlink to be displayed, that's what's part of the attribute. So the a tag has an href attribute that accepts a hyperlink. So I have the hyperlink in my clipboard. I'm just going to paste it here. So you see that so far, I've just opened my a tag, put a space. I've added the href attribute, which is used for URLs. And then I'm just going to close that start tag. And now, just as usual with most of our HTML elements, what we put between the start and the end tag is the content that's displayed on the page. So in this case, I'm going to add my end tag. And since the word baked is between the start and the end anchor tag, that's what we're going to see on the page. And then this attribute is just behind the scenes. And the a tag knows how to use that attribute to form a hyperlink. So let me save this and look at that in the browser to see what that looks like. So I'll refresh this page. Now I see that the word baked is displayed as a hyperlink. And when I click it, it opens a different website with the recipe for baked sweet potatoes. So you'll see that attributes allow us to provide this additional information. And certain tags have attributes just like the a tag expects the href attribute. Certain tags have attributes that they work with. There are certain attributes that are useful for every HTML element. So we'll start to see which elements attributes are useful for as we go along. And actually, the next element we need to work with, which is the image tag. So we can fill in this gap here, does use attributes as well. So now I'm ready to add an image to my web page. The image I want to add in this case is an image of sliced sweet potatoes. And I already have that saved into the same folder that I'm working from. You see that the image here is sliced.jpg. So the way that we add images in HTML is using the IMG tag. So I'm going to go ahead and start that. And before I close the opening tag, this element also requires attributes, just like the hyperlink or the anchor element did. In this case, all of the information that we give to the image tag will be in the form of attributes, because we actually don't have any text that shows up on the page for an image. We really just need to specify the path to the image file. That's the number one requirement. And then optionally, we can also give subtitles or the size of the image. So for now, we're just going to give the path to our image and since it's saved in the exact same folder as this current HTML file, then we can just give the file name. So the attribute that we use to do this is the source attribute, which is src. So I'll do source equals. And then I'll give the name, which is sliced.jpg, and just close that image element. So in this case, this is a self-closing element or tag, because we don't need a start and an end tag. We usually need those because we are surrounding content with the tags. But in this case, there's no content to surround. So we just use a start tag and close it there. OK, so that's it for the image. And it looks like the last thing we're missing is the form at the top. So in this case, the element that we use to create forms is the form element. So that's really easy to remember. And a form is just a collection of input from users that we want to collect in a group and then submit for some sort of processing. So right now with just HTML, we can't really do any processing. So we're just going to have the form there. It's not really going to do anything when the user pushes Enter or Submit. But we can still create the form in HTML. So we start with the form element, and that's just a structure to hold all of the different input types that we want to use for the form. So let me go ahead and close this just so I can create that skeleton. And then within the form, we can have different types of input. And a lot of these input types use the input element in HTML, which is the input tag. And to differentiate between different types of input, we just use the type attribute here. So we would do type equals. And there are a lot of different. You can see that Visual Studio Code is giving me some options here for autocomplete. So you can have buttons, checkboxes, dates. These are all different types of inputs that you could use. And in this case, since I just want to first ask for the user's first name, I'm going to just use basic text. So that's just a small text box input. And for inputs, you also need to give a name, which won't really make sense right now. But once you process the forms later, this is the labels. The name is used as a label for the value that you submit for processing of your form. So I'll just call this first name. I'll use hyphens for now. And the last thing I can do is give a placeholder for the text that will appear inside of this text box before the user types anything. So in this case, I'll just type first name. Input elements are also self-closing because all of the information we needed, we've already provided via attributes. The next thing I want to use is a text area. In this case, that's a larger input box that can accept longer input. So I will just give this a placeholder. Oh, in the case of text area, actually, this is not a self-closing tag. So the placeholder or the text you want inside of the text area actually goes between the start and the end tags. So in this case, I'll say enter your favorite, I'll say describe your favorite use of sweet potatoes. So now I have a text area, and I'll actually go and add some attributes to this as well. The first attribute will describe how tall the text area should be. Not necessarily in terms of height in pixels, but in terms of how many rows of text we expect the user to type. So I'll just put four rows in for now. And then the second will be a name for this input as well. So I'll call it description.  So once the user finishes entering the input that you're asking them for, you want them to be able to signal that they're done and submit the form for processing. So in this case, we'll just add a button. There are two different ways to do that, but in this case, we're going to use the input element, the same one we used above. And in this case, instead of type equals text, we'll do type equals submit. So that is a submit button that we'll create. And then we'll just give a value of submit, which is the text that will appear on the button. So now we have a form and we have two inputs in addition to one submit button for that form. So it looks like we have all the content we need for the page according to the final version that we're aiming for that I showed in the beginning of this video. So I'll save this and head over to the browser to take a look, refresh the page, and let's see, we have a form here, we have our different sections, we have a huge image, and we have the rest of our text. The one change I'll make before we move on to CSS is to change the size of this image in the HTML. So I'll switch back over. And I can actually add two more attributes to the image in addition to the source attribute. So I'll just add a width, I'll make that 300. And actually if we just do width, the height should change accordingly. So let me switch over, yeah. So we'll just use a smaller image, I'll put a width of 300. And that makes it easier to look at our page. So this is the result of our page using HTML only. We got all of the content on the page. And in addition to what we can see here in the browser view of the page, we've given our content a lot of meaning semantically. So if I switch back over to the code, we see that there are some things that aren't being conveyed on the browser right now, like the fact that we're using an article and a side, a header and a footer. Those things will help in the long run, especially when search engines and accessibility tools access web pages. But that's what we do with HTML. We lay out the content, we structure it, and we provide meaning so that it can be interpreted in the right way. So we'll continue with this in the CSS video, but for now, this is a good use of a lot of HTML tags and we covered a lot of really common ways to use HTML. Welcome back. So we've covered how to define the content of web pages using HTML, but at this point, those pages are in black and white and we can't control the look and feel, which is pretty important. So let's take a look at how we can style pages using CSS. So let's talk about what CSS is and what we use it for. So far, we know that HTML is what we use to define the contents and structure of a web page. So we define the actual text and the elements that will be presented on a web page. But as you saw in module one, you can't really control much of how the web page is displayed using just HTML. So CSS is responsible for the presentation of these web pages. And that's something that we really want to emphasize is that the content of a web page is a separate concern from the presentation of the web page and from the behavior of the web page. So we have different languages to control each of these aspects of web development because it's really important to keep these things separate. It makes it easier to develop them and it makes it easier to maintain the different aspects and so on. So CSS focuses on style and presentation. It stands for cascading style sheets. And the way that we use CSS is we apply it to HTML so that we can access and modify the styles of those elements that we created with HTML. You can actually apply CSS to any type of markup document which HTML is an example of, but it's most commonly used with HTML. Some of the things that we modify when it comes to style with CSS are the color, the layout, size, font and so on of the elements that we have in our web pages. And the really good thing about CSS is that because we have that separation of content and presentation, we can swap those components among each other to modify different web pages with the same CSS. So we'll see an example of that on the next slide. So here's an example of what a CSS document might look like. Don't worry about understanding the syntax just yet, but what you can see is that you have some properties that you're calling out like background color, text align, font size and things like that. And you're giving those values to modify those styles. So you might remember this webpage from the last module with HTML. So this is just a webpage that's built only with HTML and it doesn't have any style applied to it. So it's pretty plain. And if we apply this CSS to this HTML file, it might look something like this. And you see that we didn't change the content, we just added CSS that modifies the properties of the content that we already have on the page. So just to reemphasize this concept of separating content from presentation, let's visit this website called CSS ZenGarden, which does a great job of demonstrating this. So this is the CSS ZenGarden homepage and if you take a look, it's just a basic webpage.  One section is the participation section, we have a requirement section. And what's cool about this website is that there are different versions of the same page that have the exact same content, the exact same HTML file. And the only difference is what CSS was applied to the webpage. So if we look at a different example, a different design, we have, let's look at the robot named Jimmy Example. So this is the exact same content of the previous page, but it just has a different set of CSS rules applied to it. And it makes a huge difference what we can do with just CSS without modifying the HTML. You see the same participation section, requirements and so on. So that's a really good demonstration of the power of CSS and the importance of separating content from presentation. So let's go back to the slides. So let's talk a little bit about the syntax of CSS, how we actually write it to modify these style properties. So a CSS file consists of a set of rules that you define to work with your webpage. And a rule is just a combination of a selector and a property. So the selector is how you identify the HTML element that you want to modify. So in this case, this selector is selecting the H1 element. And in this case, that would select every H1 element on the page that the CSS is working with. Then we need to tell the computer what we want to do to the elements that we select. So that's what the property is for. So the property consists of a property that we identify and then we give a value for that property for how we want to change it. So in this case, we're changing the font family of H1 elements to the value Helvetica, which is an example of a font that we can choose. So that is the basis of what CSS revolves around. To write CSS code, you write a set of rules in which you identify the elements that you want to target using selectors and then you modify the properties of those elements to change their styles. I'll cover a few of these properties in an upcoming demo, but it's impossible to learn all of them at once. There are a lot of properties that you can use and you'll likely want to start with the basics and most common ones and then move on to more properties once you need them for specific uses. Here I've linked the W3C website where there are a list of the properties that are available to you. W3C is an organization that manages the CSS specification. So you can check that list out and take a look at the list of properties. But in the next demo, I'll focus on the most commonly used properties and kind of give you an idea of the categories that these properties fall into so that you can have a better understanding of how to proceed going forward. And once you start to practice, you'll get a better understanding and good experience with some of these properties. So let's go ahead and jump into the demo. So let's get started with a demo of CSS. And we'll start with the same Hello World demo that we did for HTML. Just a reminder, Hello World is the traditional first program that beginners write when they're first learning a new programming language. The purpose of doing such a simple program is to be able to understand the basic syntax and style and where to write the code when you're learning a new language without having to worry about what you're programming. So we're gonna start with something really simple. Now in the case of doing a Hello World program with CSS, CSS can't exist without content written in a markup language, in our case, HTML. So we're gonna start with this HTML code that just says Hello World. What a wonderful day. So I'll show what this looks like in the browser right now. So this is the webpage we're working with to start. Just has the basic text Hello World, what a wonderful day. And we will go ahead and use CSS to change the color of this to start. So there are a couple of ways or a couple of places to write your CSS, some better than others. So I'll start with the easiest option and then move toward the most desirable option. So to start, you could actually write CSS right within your HTML and that's called inline CSS. So if I wanted to change the color of this H1 element that says Hello World, I could do so right here in the start tag of the element using the style attribute. So once you use the style attribute, you can just go ahead and write CSS code right within those quotation marks. So in this case, I'll just change the color of that to blue. And if you remember, this is just the property I'm going to change and that's my CSS. So if I save that and go back over to my browser, refresh the page, now the color of my H1 is blue. So that was an inline style. Let's take a look at how to do this a little bit better using an internal style sheet. So in this case, I can go into my head which contains metadata about the page. So in this case, since the CSS is not content, we're going to include it in the head section and I can use a style tag to write my CSS. And all you do is between these two style tags, you can directly write your CSS. So right here, I'm no longer writing HTML. I can directly write my CSS. So I'll go ahead and do a rule that will apply to my entire body of my page and I will give it a property of color. Let's go with orange. Save that, switch back over to the browser, refresh the page and I see that the color has applied to the body. However, I still see the color of blue and let me go back to my code to demonstrate why that is. So the cascading nature of CSS is actually pretty important. Rules are implied, the most specific selector always wins when it comes to applying rules to the same element. So in this case, the body applied to all of the elements on the page and we applied the color orange to that. But the H1 is more specific than the body. So in this case, the blue color for H1 is going to overrule the orange. And we'll see a little bit more of how this cascading works as we go through this example further. So we've talked about inline styles and using internal style sheets in our HTML files. But it's best to keep content and presentation as separated as possible. So what's most desirable is to use an external style sheet and to save our CSS code in a CSS file. So I'll go ahead and copy this, I'll actually cut this rule out that we created and I'll remove these style tags and I'll also go ahead and remove the inline style just so we can start from scratch. Save that. So just to make sure that my page is back to normal. Refresh that and we're back to just a plain HTML page. So from here to create an external style sheet, which is what we want to do going forward, just create a separate file in the same folder as your HTML file. So I'll call this file style.css and CSS files always have a .css extension. And here I'll just paste that same rule that we used and let me fix the formatting of that. So here's just another basic rule. It's the same one that we used where we're going to color the entire body section, the font color of that section orange. And with CSS files, you literally just start writing your rules directly into the file. There's no setup or anything like we have with HTML. You just jump right in and define one rule after another. So if I save this and go to my browser, nothing happens. And that's because these two files don't know about each other. And more specifically, the HTML needs to know about the CSS so that it can apply those styles to the webpage. So if I go back to my HTML file, I need to link the CSS file to the HTML file. And essentially what that does is pull in those CSS rules and put them right back into this file, the way that we did with the internal style sheet. But it's still better to keep them separate until that happens automatically so that it's easier to maintain our code and to read what we're doing with our code. So to link in a CSS file, we use a link tag in HTML. And we need two attributes. The first is the source of where this file is. So if it's in the same folder, you just have to give the file name of your CSS file. And we do this with the href attribute. And then I just give the name of my file. And then the other attribute that we give is the relationship that this file has to the HTML file. So it's the REL attribute. And then we just tell it it's a style sheet that we're pulling in. And this is a self-closing tag since there's no content that we're actually displaying. So now if I go back to my browser, I should see these changes reflected. And I do. So in this case, you want to always use, let me go back to the code. In this case, you always want to use an external style sheet when you can, because it's just easier to maintain your code and to reuse it in other places. And what you need to remember when doing this is just to link your CSS file from your HTML using a link tag, and then write your rules directly in your CSS file. So now that we've completed the Hello World exercise with CSS enhancing our HTML page, we'll move on from that to a more advanced demo where we'll cover some more CSS properties and go into more detail with how to use CSS to effectively design and layout web pages. So the page I have open here is, it's the same thing we were working on in the HTML module. And this is what we're going to work towards as we style the HTML page we left off with in that module. So it's not designed according to any design standards or anything like that by any means. This is just designed more for a teaching tool to demonstrate a lot of the properties and things that you'll come across as you learn. So we want to play with color, sizing, layout and things like that. And this is a basic page that will allow you to do that. So as you can see, we have a background color and some of the different sections of the page have different background colors. We have different font colors. We have things that are positioned in different parts of the page, different sizes. So we'll kind of walk through and demonstrate how to achieve this final look starting from the basic HTML code with no CSS and turning it into something like this. So here's the HTML file that is responsible for setting up the content of the page that we are working to recreate. You can see it just has some semantic elements such as the article, a side header and footer and some text content and image and a form for users to input some information about their favorite ways to use soup potatoes. So this is what we'll be starting with. So let's take a look at what this looks like in the browser. So here you see we have just plain text. This is just what the HTML produces with no CSS applied to it. And we're going to start with this and add CSS gradually to end up with the end result we desire. And we'll start with applying that CSS by focusing on organizing the content first. We see in our HTML that we have a lot of these semantic elements that we mentioned and we'll start with those. But first let's start by linking our CSS file, a new external style sheet. So I'll use this button to create a new style sheet and I'll call it style.css. And then I'll go ahead and link that before I forget just so that we can get that out of the way. So I'll link it using the link tag in my HTML file. So now going back to the style.css file, we'll go ahead and get started with our first rule. And in this case, we're going to go ahead and start with color before we start moving things around and letting things out just because it's easier to see where we're putting things if we have them colored differently from one another. So the first thing we'll start with is giving the body a background color. And from the page we looked at, we saw that the background color that I had on the body is orange. But before we do that actually, let's go back into the HTML because I want to add one more element that we haven't really talked about. I'm going to further group the content of the page using a div tag. And what that does, it's similar to the semantic tags like header and article, but it has no semantic meaning. And it just allows you to group things together for stylistic and manipulation purposes. And in this case, we want to be able to apply certain styles to all of the content without using the body tag because we want the body to be a little bit different from the rest of that content. So I'm going to go ahead and create a div tag here. And I will give it an ID. We haven't really talked much about IDs, but this just allows us to reference it later. And I'll give this an ID of container since that's what I'm going to use it as a container for certain pieces of content. And then I'll go ahead and indent the rest of the content within that and add a closing div tag. So that won't have a difference visually, but it will help in upcoming steps. So now we can go ahead and go back to the CSS and continue where we left off. So now I will go ahead and add my first rule to the CSS and that'll be on the body section. So I'll use a body selector and I'll go ahead and give the body a background color of orange for the theme of my soup potato website. So if I save that, we can go ahead and have a look to see to make sure everything is linked up properly and that it displays correctly in the browser. I'll just save my file and then I'll head over to the browser, refresh the page and I see the background color of orange is applied to the body of the page. So now I can add my next style or my next rule. And in this case, I'm going to apply it to the div that I just created. And the way I'm going to access that is using its ID. So to access something or select something using ID and CSS, we use the hashtag or the number symbol followed by the ID that you want to select. So in this case, I gave my container an ID, my div and ID of container. So I'm doing hashtag container and then I just do my rule as usual with the property. In this case, I have a background color of white for my container. So let's take a look at that in the browser and we will refresh the page and see the background color of white,