Lists! They might seem boring, but if you look at a lot of site source code (good sites at least,) you’ll see a lot of lists. A lot of obvious content on the net is in the form of lists (which is why there are three separate constructions for them) and a few years ago we started using them for less-obvious, but still valid reasons.
Using Lists as Menus
The biggest, non-obvious, use of lists is for menus. Someone, somewhere, pointed out that menus were just lists of links. Couple that insight with the power of CSS to bend boring old lists to the designer/developer’s will and we had a de-facto standard on our hands.
Here’s what the menu system for DrunkenFist.com looks like. It’s a lot of code, but it’s a fully-realized version of the pattern, so it’s useful to look at in whole. As a note, this is an HTML5 site, so the nav element is in place signifying to browsers that “the following block represents site navigation.” I’ll be covering the new HTML5 elements as the very last post on the body. Read the rest of this entry »
We’ll finish up our tour of the body tag with several posts featuring general notes about common content elements. I’ll be taking my time with these as getting this stuff right will go a long way towards getting the most out of your site.
Comfy?
On with it then.
Links <a>
The link is the engine of the web. The concept of Hypertext (the H in HTML) itself is expressed in the power of the link. Google is Google because of the power of links. There is no better place to start.
Basic usage
<a href="http://www.drunkenfist.com/"
class="contact"
title="my personal site"
rel="me">DrunkenFist.com</a>
Write Good Link Text
For body copy you want to write link text that is descriptive of the link destination. generally this means a short phrase (5-10 words, depending on who you ask) that clearly describes the link. For that reason “click here” is generally not the greatest link text. For a live example and more on this topic take a look at link chapter of the the US Government’s Research-Based Web Design & Usability Guidelines. It’s full of really interesting tips on handling links.
For the SEO-minded, the above advice has the added bonus of generally including keywords which flow link juice and context to the targeted page. Read the rest of this entry »
The body is clearly going to take a while, since it contains all of the content on the page. I’ll be breaking it out into chunks. This first post will focus on how I use the body tag itself.
I generally use the body tag to hold basic information about the page to use with both CSS and JavaScript. I want to capture the general type of page (home pages, landing page, gallery page, tertiary page, form page) and then the style of the page within the general type (e.g., art, movies, blog.) Coming up with a good, logical scheme for this kind of thing can generate plenty of unexpected benefits throughout a site build.
It can also help with planning as these classifications can be used as part of the estimation process- “I’ve got 5 major templates and 10 variations, that’ll be 2 weeks of work.”
This won’t be the longest entry in this series, but I did want to take a second to outline the way I organize files. You can come up with your own scheme. There are many. This one works for me, so I use it. The basic idea is to keep everything in a logical, easy to find place every time I make a site.
Let’s take a quick look at the generic file structure I use:
Last time out we looked at the Anatomy of a Web Page. Using that, let’s move on and look at the first of the two major sections, the head.
For the sake of this blog post, the head includes two pieces of code that are actually before the head. Sue me
Using the head from my (recently updated) starter assets project as an example, let’s look at the code in detail. First, what it looks like in total: Read the rest of this entry »
This the one of the guiding principles of the way I make sites. We want to keep our content/data, in the form of HTML (HyperText Markup Language) code, neatly separated from the rules that tell the browser what it’s supposed to look like, in the form of one or more CSS (Cascading Style Sheets) and rules that tell the browsers what it’s supposed to do, for our purposes, written in JavaScript.
Why?
Well, there are many reasons. I’ll give you two big ones and then it’s onto the next section. We’ve got a lot to cover.
Well, I leaked it earlier this week, so I might as well get started.
Welcome to How to Make a Web Site the Modern Way, a blog series outlining, to the best of my ability. how to build an HTML page using today’s best practices. The focus won’t be on specific coding techniques, although there will be some of that, it will be on how the pieces fit together. Without experience, it’s tough to know how the pieces of a web page fit together in the best way. I’ve got some of that experience and I’d like to share it with people. So at the end of all of this, I’m hoping this series will serve as a one stop shop for people looking to understand the big picture.
First up: The Anatomy of an HTML Page .
Some basic principles:
Fast: I want pages to be as fast as possible by default.
Findable: This isn’t really the same as SEO, but it’s kind of like a cousin to it. I want to make pages spiderable, human scannable, computer readable and generally information rich.
Standards compliant: I’m not a standards zealot, but I try my best to follow web standards wherever possible.
Accessible: I try to make pages as accessible as possible.
Usable: Usability is a deep topic, but there are things you can do, by default that will enhance the usability of your site.
Intuitive: I want developers to look at the stuff I do and say “hey, that makes sense.” I also want it to make sense to me when I return to it in six months
Breakable: Which is a funny way of saying “graceful degradation,” a concept that colors a lot of what I try to do. The idea being- if something’s going to break, or not work as expected, make sure that it’s not totally screwed up
I just wanted to point folks to the small project I started on Google code- Starter Assets.
It’s based on some work I did at Cramer to standardize the development process there. The idea was to provide a standard set of files and a standard file/folder structure for people to start with whenever they were initiating a new project. I’ve expanded on it in this case to (eventually) include several doctypes (right now it’s just xHTML strict- HTML5 will follow soon) and links to popular JavaScript libraries on the Google Ajax Library CDN (just jQuery for now.)*
To use, you’d just download or SVN export the folder that corresponds to the doctype/library combination that strikes your fancy and you’re good to go.
I’ve released it in advance of a blog series I mentioned during my JavaScript presentation this past Thursday. It’s a step-by-step tutorial on how I build web sites called, “Building a Modern Web Site.” Read the rest of this entry »
Yes, I’m still helping out with screening candidates. I haven’t yet interviewed someone to replace me, but there’s still a week to go.
Anyway, we’ve had a couple of technical questions that candidates universally failed to answer. Why share them here? For starters I just want to know if we’re crazy to expect people to know these. I also like the idea of a kind of “easter egg” for candidates. If someone does enough research to find my blog and read this post, they’ve shown me something, even if it’s not the answer to one of the questions posed below.
The two that have surprisingly turned into stumpers (at least for the last five or six folks I’ve interviewed)
What is hasLayout?
What’s the significance of setting the body text to .625em?
And the bonus question that I want to ask, but don’t, because it’s kind of goofy to say out loud
Or, more simply: If we use Google’s JavaScript Library CDN, we are asking the majority of our website visitors (who don’t have jQuery already cached) to take a 1/3 of a second penalty (the time to connection to Google’s CDN) to potentially save a minority of our website visitors (those who do have a cached copy of jQuery) 1/3 of a second (the length of time to download jQuery 1.3.2 over a 768kps connection).
That does not make sense. It makes even less sense as the download speed of your visitors increases. Try to avoid serving 20 or 30 kilobytes of content at the cost of using a 3rd party just doesn’t make sense.
We’ve used the Google CDN to serve jQuery at Cramer with no obvious complaints and I heartily recommend using the configurator/CDN option that Yahoo offers (for the unitiated, it builds a “just what you need” package to grab from their CDN, so you don’t have to serve every YUI Module just to do x), but Billy Hoffman’s article definitely makes me rethink the former.
If you didn’t live through it (and I didn’t live through the whole thing), now you can revisit the strange history of the user-agent string in just a few, well-written, minutes.
We spent about 45 minutes running variations of the one-liners above in the console during a code-review last week. Fun times.
It sounded like this a couple of times:
“Wait, what?”
…
And finally… are you enjoying the jQuery advent calendar? I’m interested in running jQuery 1.4 against the demo code I build for my library presentation. I expect to be bowled over.
