Hacking for Designers #1: HTML

(Apologies to David Kadavy. I stole his title. :P)

A note: “Hacking” among programmers just means you’re building something new, usually with code (but not always!). It’s not the kind where you just type a bunch and then say “I’m in.” Programmers refer to those people as “crackers,” and they don’t think very much of them; partly because it doesn’t actually take that much intelligence to break into stuff, and partly because what kind of uncreative programmer can’t find something better to do? Honestly. The exception is of course pentesters, or “white hats,” whose job it is to try to break into systems to find out where they’re vulnerable and secure those vulnerabilities. Pentesters are quite highly regarded. Developing security and finding obscure weaknesses to shield is much more difficult than what most crackers do, and much more valuable.

So, you have the ability to make stuff look awesome through design. It’s important! We need people like you, because otherwise technology would be a royal pain in the butt to use. Design is the reason Apple succeeds even though they don’t always have the best tech, and lack of it is why it took Linux forever to get off the ground as a user’s OS despite being awesome at the code level.

But not being able to code at all can be a bit… limiting. There’s a learning curve, yes, but fortunately the basics aren’t anywhere near as intimidating as they look. You’re definitely smart enough to pick this up. The main barrier is how scary and weird code can look to a neophyte.

The good news is that hacking is a lot more similar to your own field than you think! People draw a dichotomy between software devs and designers like they’re total opposites. Even geographically, our classes are on the opposite side of campus next to the physics and chemistry departments (here at UNI). But this is super weird! We have zero to do with science. They call us computer scientists, but that’s just to make us look fancy. What we are is makers, and the way we learn and the way we work are much more similar to painters and writers and… designers!

So, I’m whipping up a quick guide for you last minute. It’s really not going to take you long to pick this stuff up. Coding doesn’t get difficult until you’re deeper into the field, and if you get that far, you’re probably addicted so it doesn’t matter 😉

This only covers web development. There are lots of other specialties in the field, but this is the one that’s most useful to you.

First Stop on the Nerd Train: HTML

You’re gonna need this. Pure HTML is butt-ugly; you need CSS to do any kind of layouts or colors. But you can’t learn CSS until you learn some basic HTML, because you need something to style. Trying to learn CSS first would be like trying to format a book without the actual text.

HTML is for content and structure, CSS is for layout and styling. Don’t fall into the trap of using tables for layout. People did that a lot in the 90s, and it makes your site ridiculously difficult to code and maintain. Also it’s likely to play merry hells with responsive design these days. Fortunately, there are a few newer tools that fix this problem and let you use grid layouts without getting into the whole <table> mess. We’ll get there. HTML first. Just wanted to warn you off this pitfall in case you see it somewhere else.

First off, you’re gonna need a code editor. Right now, the hacker favorite for web dev is Brackets. It’s free, it’s open-source, and you can download it here.

Got that?

Okay, so here’s the basic skeleton for an HTML5 project. Copypaste at will; I’ll explain what all this does in a minute.

<!DOCTYPE html>
<html>
    <head>
        <title>Welcome to Website!</title>
        <meta charset="UTF-8">
        <link rel="stylesheet" type="text/css" href="thisisyourcssfile.css" />
    </head>
    <body>
    </body>
</html>

If you save this as an HTML file and run it in Brackets’ live preview (use the lightning bolt button on the top of the right sidebar), you’re going to see a blank white page. That’s normal! You should also see “Welcome to Website!” in the tab’s label in your browser. That’s because I set it as a placeholder title; you can put whatever you want in there.

About those indents–they’re not strictly necessary in HTML, but they make your code way easier to read! You could put everything on one line if you really wanted, but it would be a pain.

A standard indent is four spaces. However, Brackets does this neat little trick where it turns a tab keypress into four spaces, so you don’t have to wear your thumbs out!

I think the only thing I still haven’t explained is the <!DOCTYPE html> thing. That just tells the browser you’re using HTML5. Nothing weird!

Wait, How Does Any Of This Work?

Skip if you already know about how browsers and servers interact. If not, here’s a quick explanation.

A “live” site (one that can be accessed from anyone’s browser, like google.com) lives on a server. That’s a computer, somewhere, which can talk to other computers and knows how to hand out web pages when other computers ask for them.

So when you type a URL into your browser (e.g., Firefox, Chrome, etc), it uses your Internet connection to go ask that server for the files that make up the web site you want. Usually this means an HTML file, a CSS file (or possibly more than one), a handful of images, and probably some scripts (programs) too, especially if the web site is one you can post stuff on and interact with rather than just read and browse.

The URL you type in is pointing to a location and filename on the server. If you just type the domain name, like somethingsomething.com, then what the server will return is the index.html file (and anything linked to it, like stylesheets and images). You’d still get the same page if you typed in somethingsomething.com/index.html because it’s the same thing. So, as a web developer, you should always name your homepage index.html so the browser can find it.

All those files are basically just instructions for your browser, telling it how to display all the stuff on the web page and what should happen when you click on stuff. Sometimes you enter text into forms and whatnot, and your browser can send that back to the server, asking for whatever response to that data is appropriate.

For now though, we’ll start with static web pages: that is, pages that are just HTML, CSS, and images. If you need more interactivity, you’ll have to either learn a programming language (JavaScript, Python, and Ruby are very reasonable choices for this), or find and work with someone who does. I encourage you to try learning to code, though! Picking up the basics is pretty easy and lets you do more, plus it looks fantastic on your resume.

Adding Stuff: How Elements Work

Most of your other code is going to go in between the <body> tags. That’s where you put all your content. <head> is a separate element. It isn’t the page header! That’s something different, and you’ll put it in the <body> tags with the rest of your content. <head> is only for metadata, which is stuff that you put in to tell browsers and search engines stuff about your site, like what character set to use, keywords to help searches find your site, and how to find your CSS file.

So, what can you put in the <body>?

Elements!

Here’s the basic structure of most elements: an opening tag, like <p>, then some content, like some text or images, then a closing tag, like </p>. Closing tags have that slash before the letters. It tells the browser that that’s the end of the element (the end of the paragraph, in this case). There are a few elements that only need one tag, like the charset declaration in the head, or image elements, but most need two!

You can have elements inside elements, and that works like this:

<p><a href=”heylookalink.com”>Here’s a link!</a></p>

You never do it like this:

<p><a href=”heylookalink.com”>Here’s a link!</p></a>

Always nest elements inside each other, don’t let them cross through each other like that!

Meet Some Elements

Here are a few elements to get you started. There are a lot of elements, and you can find out how all of them work from w3cschools.com, but here are the ones you probably want at first. They’re all linked to their respective W3C Schools pages, so just go there to find out how they’re used. Everything has examples and stuff!

Divs and other style-related dividers

<header> and other semantic elements

These elements are just boxes to put your stuff in so you can style them up later. Like, <header> is for the header in your design, that shows up at the top of the page. It’s an invisible box at first, but you can use CSS to paint the box different colors, or change its size, add borders, stuff like that. Go to the semantic elements link for the whole thing, there’s a bunch like this: <nav>, <article>, <section>, <aside>, <footer>, and so on.

<div>

These are like the semantic elements, but they’re custom! You can give them classes, for when you have a bunch of divs to style the same way, like <div class=”product”>, or you can give them IDs, for when you want there to be only one div in that style, like <div id=”left-sidebar”>. (We’ll talk more about classes and IDs when we get into CSS.) Divs used to be the only kind of “styling boxes” available, but HTML5 introduced the semantic elements above.

Text formatting elements

<h1> <h2> <h3> … <h6>

These are also referred to as header elements, but they’re not just boxes. You put text inside, and the browser recognizes that it’s a header and styles it accordingly. By default, h1 is huge and h6 is pretty small (but still bold, so it’s different than other text). Here’s what my blog’s styling turns them into:

h1

h2

h3

h4

h5
h6

<p>

Paragraph tag. Pretty straightforward!

<ol><ul><li>

1. 2. 3. “ordered” lists, bullet-point “unordered” lists, and the list items you put in them, respectively

<a>

Links (they need an href=”linkurl.com” to work tho, so your browser knows where it’s supposed to go)

Other stuff

<!– comments –>

This is an important tag, and one you’ll probably want to use a lot, especially at first. It’s a special one: it lets you make notes to yourself or other developers. Anything inside a comment tag is totally ignored by computers reading your code.

It’s an unusual looking tag, so here’s how it works.

<!-- blaaaaaah it doesn't matter what I put here! the browser doesn't care as long as it's between these tags! -->

You can use comments to warn future readers about some weird hack you put in your code, or you can use them as a to-do list, or you can use them to remind yourself how something works. Or you can put dorky ASCII art or silly jokes in it, so if someone comes along and decides to read your code, it’s like an Easter egg for nerds. There’s a proud tradition of leaving silly comments in source code.

Occasionally you’ll hear developers brag that no one should need comments because code should be written so it’s “self-documenting”; in other words, one should master the art of precise and meaningful names for variables, classes, etc. This is bullshit: sometimes you just need comments, and usually the developer making said claim is NOT one whose code is “self-documenting.” It’s just an excuse for them to be lazy and not write comments. You’ll find that programmers are very lazy–especially the ones who are either very bad at programming, or very very good.

Either way, just go ahead and write your comments.

<hr>

This makes a line across the page. Sounds weird, but sometimes you need it.

<meta>

Meta tags are how you tell other machines things about your code. They always go in between the <head> tags, not the <body>. You can tell your browser what character set to use (this gets important when your site has international visitors). You can tell search engines who the author of the page is. You can give search engines information about what’s on the page by offering it keywords. You can also tell your browser to notice how wide the device is, and change the page’s formatting accordingly–this will get more important as you get into responsive design.

None of the stuff in <meta> will actually show up on your page, but other machines will be able to read it. The only way your site visitors will see any of it is if they use their browser’s developer tools to manually look through your source code. Also, <meta> are single-tag elements. You’ll never need to type </meta>.

If this element sounds like a weird grab bag of semi-related stuff, it kind of is. W3C can elaborate on the stuff you can do with <meta>. At some point, you’ll need to know about what <meta> can do, but for now it’s okay to skip it and come back later.

<!DOCTYPE html>

That tag is called a doctype declaration. Browsers will generally still render stuff just fine without it as long as HTML5 is current, but as the web page gets older and the standards change, it might start to get buggy unless the browser has a doctype declaration to tell it which standards you’re using in your code. The way we code for the web changes over the years.

This tag has to be the very first line of your HTML file. Don’t try to put it anywhere else.

 

 

 

I’m still working on this post, as it’s going to take a bit to cover everything you’ll need to get started, but I’m confident I can get it down to a manageable and relatively non-intimidating post. Yes, I’m publishing it before it’s 100% finished. A blog post isn’t a book, and nothing that’s going to be here should make the post misleading due to its initial omission. In other words, all the chunks of info on here should be fairly self-contained. (It’s 3AM and I’m getting sesquipedalian wordy because I’m tired, so I’m going to stop for now. Isn’t that a weird habit?)

Happy hacking!

Advertisements

4 thoughts on “Hacking for Designers #1: HTML

    • Whoa, that looks fantastic, thanks for the link! I’ll be looking through the “modern techniques” part myself for responsive design and flexbox stuff.

      I’m still going to write my guide though. The people I’m writing for are somewhat reluctant to pick this up at all, so they’re going to see the length of that guide as a drawback; it’s almost as long as a NaNoWriMo novel. To me that’s a good thing; to them, eh.

      The difference is that it looks complete. Mine is just a crash course in the total basics, to make code look less scary and offer enough context that reading W3C, or possibly Dreamweaver-generated code, makes sense.

      Yes, we’re using DW. I’m about as reluctant to touch it as my designer classmates are to learn coding. Last time I tried to use it was around six years ago, so early 2012ish. Mostly all it was good for back then was writing tables automatically, because it royally screwed up the code on anything else.

      I suppose you could’ve just used the split view feature it had as a clunky version of Brackets’ live preview, and done all the coding yourself, but the teacher I had back then (who actually was supposed to be a techie) did not care a fig about code quality (or maybe just didn’t know any better?). I still have a bitter taste in my mouth from that, even though I’ve hheard it’s gotten way better from a dev’s perspective.

      Anyway, I’ll add that site to the “further resources” post I’m going to put up as the last in the series. Thanks!

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s