Julio's Blog

There’s two things that happen when you visit a web page.

• you get to see it from a end-user’s perspective (see images, read content, interact).
• you get to read the source and styles or inspect the document and all that comes with it, should you choose to.

Surprisingly not enough people who have an interest in understanding how to write good HTML / CSS do the second.

In the circle that I sometimes hang out, there seems to be a legitimate interest from developers to learn how to write markup, as evidenced by Ben Schwarz’s workshop having sold out rather quickly (if his tweets are any indication). If you get the chance to go to one of these events, do yourself a favor and go. I say that not because I believe that’s the only way you can learn (keep on reading), but because learning from developers instead of teachers means you’ll waste a lot less time. You’ll get to see some of what the tutor has done for real projects, and the chance to ask why it was done like so.

But in the interest of giving people something to do until they decide to take on a course, there’s something I do often that I find it works pretty well: building small scale prototypes of parts of websites you like. Bear in mind that this is not an argument in favor of copying others. Though that’s a rather decent self-teaching methodology, it’s also pretty scummy if you’re actually launching things this way.

Think of it like this: the blueprints to lots of high quality work are being throw at you. Now all you need to know is how to catch it.

I want you to start bookmarking websites of low to medium profile design / development studios out there. These are the guys who care about doing it right. A few sources I have on my Google Reader: Line25 (the Sites of the Week section), Six Revisions and BeCreative Magazine. Keep an eye out for the bottom of the articles where in general, authors link the firms where they work. Check them out, and look for a portfolio section. Stay away from Facebook, Google, and the likes. It seems most of the giants don’t give a damn and just do whatever they want when it comes to markup.

Now go get Firebug installed if you’re using Firefox, or enable the development tools in Safari or Chrome. As for IE, you can get Firebug Lite set up as a bookmarklet. Now start poking around by firing up the DOM inspector. Look for how they laid the base page structure, headings, comments section if any, navigation, etc. That’s all fine and dandy, but you can do that all day and you won’t learn fast enough. You need to sing along. So open up a text editor, and start writing a document in parallel, copying bit by bit. Use inline stylesheets if necessary to keep things minimal. Don’t bother trying to replicate every asset they have. That’s not important. What’s important is that you understand why the markup is written the way it is. Forget about the right way to do it. You’ll start understanding the patterns once you go through 10 or so of those.

Done? Move on. Don’t be tempted to fix anything. It most likely won’t look as good as the original, and that’s fine. You’re better now than you were when you started. Win. When you get into the habit of doing that, you’ll go through markup like it’s fine food.

One of the most intriguing pieces of markup I read recently was http://camendesign.com/. Open that website up on your iPhone (or whatever phone you have that has a remotely decent web browser). If you’re trendy and you have an iPad, open it up on it too. Now put both your phone and your iPad next to your monitor, and behold: valid, gracefully degrading, mobile friendly HTML5. I don’t think I learned as much from any HTML5 article as I learned from reading how this guy did it. It’s brilliant. If you can make your mini prototype off of this website, while keeping it portable across devices, odds are you now understand how it works, and you can roll your own.

This advice goes not only for HTML, but for any programming language. If you’re not reading source code, you’re doing it wrong. Learning how to build things strictly (or even mostly) from the perspective of a language’s syntax is slow and unrewarding. That’s like kids having to learn math by running equations over and over. Get them to build a shed while applying geometry instead and you’ll get not only people who really get it but also potential engineers. So screw formal learning methodologies. Go to http://github.com, pick a small project of renown, clone it or read it online, and try to understand how people who are more experienced than you did it.

ps: and quit bitching about my blog’s layout / style. I’m just using a theme from Tumblr since I didn’t think this whole blogging business would go anywhere. I’m well aware it could be done a lot better. And it will be.