The Semantics of Prototyping with HTML and CSS

Prior to this week’s assignments, I had never prototyped before. It was interesting to learn by using our previous knowledge, from sketching, to making basic text, to learning basic css, and lastly manipulating images. Now, we’ve combined all of those skills to create a prototype of the YouTube page and it was definitely a journey. These assignments put my skills to the test and had me stumped for a few sections as well. I can’t wait to continue building my knowledge of HTML and CSS, in addition to combining it with new skills in future assignments.

Semantics

For our first assignment of the week, we were tasked with looking at a few articles relating to the semantics of HTML, in addition to relating those semantic elements with CSS. The first article really drove home the idea that there isn’t one specific way to build a website. Compared to before, it brought up the idea that something like a nav can be a sidebar, similar to an aside, instead of a menu bar under the header. It also talks about nesting items, where an article may have multiple sections with a header and footer, which aren’t the elements related to the body of the document, but relate to that specific section on the page. One of the last things that I learned from this article was that semantics are quite important. Prior to this, I felt that semantics only made the code easier to read and it helped you find errors quicker, but that isn’t all it does. It also brings more searchable content, which means higher search engine rankings, and it also can increase accessibility for things like screen readers. That last part is something I always find myself not thinking about. Lately, I have been trying to think about “What is this for,” if it isn’t targeted for me. I think that many people don’t normally think of a user outside of their own means, because we are capable enough. The reality is, those people do exist, and eventually someone in that position will need to use your site. Therefore it is important to know ways beyond making your site simply look good, but also making your site accessible.

The second article we looked at basically broke down the various sectioning elements of HTML5, and I believe it did it wonderfully. Prior to this, I didn’t like the way w3schools explained things because it barely gave you any information on how the element worked. It gave you a short sentence and a small snippet of only that in the code and you are expected to fully understand it. With the teamtreehouse article, they not only explain the basic function, but they use it in example code, so you can see how it would work in a normal document and if you can use multiples of things, like sections. This article also talks about the benefits of semantic meaning, screen readers, and so on. Lastly, it touches on how using these elements helps us to think more about the structure of our web pages and that choosing them isn’t always easy. It raises questions about the content, like what the purpose is, and if it should even be on the page at all. Like the article states, this improves the quality of our code and our web pages.

For the last article, I will just comment on it quickly. I actually used this page in our last week’s assignment, because I wanted to focus on one part of the page instead of affecting the entire document. I definitely appreciate being able to pick out one part of a page, or multiple similar parts, instead of affecting things one-by-one through inline styles in HTML. Lastly, it also helps tremendously when you have multiple elements, such as sections, and you want to affect them differently. It’s amazing to be able to label one “sectionA” and another “sectionB,” for example, and not have to worry about the CSS code affecting both.

Prototyping

I know I keep saying this, but this assignment was definitely one of the most interesting so far. It really put my knowledge and skills to the test in trying to complete this assignment. As usual, many parts came quickly, like the header and creating a simple nav. It was easy to get pictures or write text and link them with “a href.” After I finished my sidebar nav, I ran into an issue, I couldn’t get my top menu bar to work properly because I was trying to only use one nav section. Through some questions, I was able to find out that sometimes multiple nav elements may be used on the page and I was back on track. Next, I had to learn how to create an image gallery, which took me a very long time to get it to work properly. Getting the images and descriptions on the page was the easy part, but I kept having them get messed up and wrap around under my sidebar nav. So, then I tried to find out how to extend that nav to the bottom of the page, but I was unable to figure that part out. From there, with some additional research, I learned about overflow and it actually fixed that problem, for now at least. My next issue was that if I made the page really small, it would place the whole block under the side nav, which again I didn’t want. Eventually I made the max width to be just outside of five tiles to make two rows when the browser window is big enough and made the margins auto, so that at least if you resized the page, it would put them into smaller and smaller columns. Lastly, the footer was fairly easy because I had used almost every technique before starting that section, so I finished that quickly. The only new information I obtained was making the list style be none, so that it removes the bullets, and then floating the individual list items so that they would be horizontal. Overall, this was intriguing assignment. As I said previously, it definitely put my skills to the test by visualizing what I would do with sketches, and then putting it into practice with code. This assignment was quite difficult, and I likely made it harder on myself by trying to perfect it, but it was an absolutely amazing learning experience to build a prototype from the ground up. I can’t wait to see where we take it from here.

Additional Research

I started to talk about some of my additional research earlier, but I want to go into further detail, in addition to talking about some articles I read relating to prototyping. First, learning how to make an image gallery was surprisingly easy, although I never figured out how to make it do exactly what I wanted. Being able to see a full example with multiple sections really made the process go smoothly. Next, the overflow property saved me tremendously when trying to keep all of my images together and not spilling over underneath my sidebar nav. It helped me to keep the gallery seemingly together and in order. Then, the float and clear properties basically made this assignment happen. I was able to float things and have them align much more cleanly than having to place things by creating padding or margins, which was very nice. Clear helped me to keep my footer at the bottom of the document instead of floating in-line to the other sections. Lastly, borders helped me visualize portions of the document, in addition to creating boxes around sections. In the beginning, I wasn’t understanding how big my sidebar nav truly was, so I put a border around it and then was able to control the width to make it much smaller. I then placed borders around many sections on my prototype to show where the section would likely end. These specific pages helped me greatly in completing this assignment.

For some additional outside research, I actually read an article from the teamtreehouse site again about rapid prototyping by Nick Pettit. It was so interesting reading this article because it basically outlined what we were doing in our assignment. It talks about first making a sketch, which can save hours of trial and error in the late stages of web development. He talks about sketching being the best way to start because it can be loose and things can change at any moment. Next, a digital mockup is suggested because then you can start to lock in your ideas and see how things may truly look. In addition, they’re much more comprehensible, which is why he recommends that this mockup should be the one you send to investors or stakeholders for review. He also recommends that you skip things like Photoshop, since they should be left for the part of the project that requires “maximum detail.” Lastly, he talks about using a framework to create an interactive version of his prototype, similar to how we used CodePen. It was nice to learn some additional tips on prototyping beyond what we learned in our assignment.

Lastly, I read an article relating to prototyping in terms of a process for improved user experience by Shaun Ellis and Maureen Callahan. It’s a lengthy article, but the main idea is that by taking user experience and feedback into account, it makes design much better. Beyond that, I think the most important part of the article comes in the conclusion. It talks about prototypes as “persuasive tools for proposing changes” in a somewhat “imaginary” scenario without using many resources. It allows people to “test, fail, and improve along the way” without hurting the company. I think that it’s always important to have a prototype before you do anything because then you don’t have to go all-in. In the case of web design, you could publish a site that works horrendously and then be stuck with the reputation of “the site that got ruined,” or you could create a prototype, work out the kinks, and produce a quality upgrade. As with many things in life, planning usually helps the outcome turn out better.

Final Thoughts

This week’s assignments were a great struggle, but a fun one. It took some wit to be able to tackle certain parts of the second assignment and it was nice to play around trying to find solutions. It was nice to, yet again, use all of our previous learning experiences and put them into one project to create a quality piece of work. I’m looking forward to moving closer and closer to designing an actual website.

References