Here are the first two instructions given in the email:

1. Go to http://www.godaddy.com/default.aspx?isc=ICANN99ad
2. Click on the "ICANN Domain Confirmation" icon at the top of the page.

Fine, GoDaddy, let's do that. Step 1 we see…

...HOLY FUCK, be calm, be calm, step 2. Wait where is step 2 in all this madness? Ok, the email says top of the page.

Oh there it is. Of course! This proves a point which hardly needs proving. I'm really not saying anything that hasn't already been said, but here goes:

GoDaddy sucks at design

Shocking, I know, but what's more important is why GoDaddy sucks at design. And I don't mean "why" as in: because they have no whitespace, they try to cram a million text links in a small space, or the color scheme is awful. We all know that. I mean the "why" that becomes evident when you reread those first two steps.

GoDaddy sucks at design on purpose

Step 1, click a link. Step 2, click a link on the page from Step 1. Why doesn't GoDaddy just give you the confirmation link in Step 1 instead of giving you written instructions to click something? If you try you might be able to come up with some theoretical technical reasons for this, but when you look at the reality of the page the answer is clearly: "There's no fucking reason."

Well, there is a reason. GoDaddy is trying to make money. They want you to go to their homepage, see it, and click on something. They do not care if you actually check your contact information. Legally, all they need to do is provide a means to update, and beyond that the ball is in your court. So GoDaddy has decided to use a mandatory legal notice as a way to market to you. And market to you sleazily.

So now you can probably see why their design has to suck on purpose. If it was good their technique wouldn't work. If the ICANN confirmation link were made obvious I wouldn't have taken 2 minutes to read every damn bit of text on the page, skimming over tens or hundreds of products, offers, specials, deals, and banned TV commercials, just to find the link I needed.

Good for them. I hope this kind of shit makes GoDaddy a fuckload of money. But it's filth like this that will always keep GoDaddy relegated, for me, to a cheap place to buy domains from time to time.

So I took the 38 seconds required to make the xml file for this. If I get less lazy I could create an installer and all that, but I'd rather Twootles did that themselves, as well as add the little 16x16 image to go with it.

For now, to install the search, just do the following:

1. Download the xml file. (Right click, save as.)
2. Save this file in your searchplugins directory. PC users try C:\Program Files\Mozilla Firefox\searchplugins. Mac users try Library/Application Support/Firefox/Profiles/xxxxxxxx.default/searchplugins.
3. Restart Firefox.

If I screwed up and you run into problems, just let me know below.

Update: The Twiogle folk(s?) who have an almost identical search engine have created a Firefox extension equivalent. It's actually a prime example of the value in paying a little attention to Twitter. They noticed my dismay at what Twootles was missing and integrated it into his own product. Ben in the comments has a link to the extension download.

Subject: Your food website...

Body:
Hey son...how ya be...
It was kind of cool yesterday when I got my nails done. Emily Mann (well now it is Brooks) does them and she mentioned that she went to your food website and thought it was pretty cool. She said it took her a little while to figure out how to get to each foods page ( I had the same problem at first til I realized you click on the heading.)

So you might not like myspace but you reached people by posting that bulletin on here.
Plus it was neat as your mom to hear someone giving out kudo's regarding my son's culinary skills!
love you bud!

See that? Solid feedback on usability and a lesson in crosslinking! I think I might have to hire her to do wireframes and keyword optimization for my next project.

See, the concept of these Content Management Systems is deceptively simple. The customer is completely braindead but needs to be able to edit the insanely-difficult-to-understand HTML. Are we on the same page yet? Can I punch in the </sarcasm>?

My current employer is in the middle of releasing the second generation of its in-house CMS “solution”. I don’t intend to pick on them since the problem really has nothing to do with the solution itself. It’s the concept of the CMS. The extremely vast majority of CMS solutions are:

• Not dumb enough for the unskilled.
• Too slow for the skilled.

That’s it.

It all comes back to one very simple fact that I’ll be sure to emphasize excessively later, but first understand there will be two basic users of the system.

The Skilled

These are the web producers/architects/programmers/whatever that built your site. They know their way around the usual web technologies but because you don’t have the slightest clue what’s going on they’ve wrapped the site up in a CMS so that you simple folk can make edits to the fancy-pants HTML. Building the site using this CMS probably took twice as long as using HTML or their favorite server side language. Why? Chances are they have to make templates and set up reusable code blocks and all the other abstractions the CMS forces on a developer. The developer hates the CMS. It is slow.

The Unskilled

So some big-city programmer just made you a website. You want to edit something. Now you have to…log in to a website and click this button then that button then click edit then…wait what? Now instead of learning this crazy HTML you have to learn this complicated application. The complexity you were trying to avoid with code has just been replaced with a different-kind-of-complex web app. This is our first, last, and only needed indicator of the truth:

HTML is not hard. Sort of. More accurately: maintaining HTML is not hard. The only thing making HTML maintenance hard in anyone’s mind is the belief that it’s hard. When you look at it, it’s nothing more than the text you see on screen wrapped in some gibberish you may not understand. But there’s really only a few of these bits of gibberish and they’re probably only used a few times. The effort it takes to learn what this gibberish means is probably less than the effort required to get familiar with your CMS.

Once all the insanity of layout and styling is figured out, making text changes to a site is cake, even for the unskilled. The CMS as a product is 99% of the time a complete waste and something only used by companies to justify vast engineering efforts or boost their top line. By selling uselessness to those too stupid to realize they don’t need it.

With that said there are a couple products in this category I do lightly endorse:

• CushyCMS: No huge templating system, no jamming a site into some expected structure of a CMS. Feed cushy some FTP info and if you want the text to be editable just add a class to that element. Simple, the way it should be.
• Wordpress: What can I say, maybe I’m a little biased (this site is built on Wordpress) but they get things mostly right. It stays simple, helps me in removing effort duplication, and has a great community to back it up. And just wait until the 2.7 interface hits the streets.

I’ll be giving a session on Sunday where I will be discussing graceful degradation and progressive enhancement. Looking at the schedule, you’ll notice my topic is strikingly different than the others, which tend to focus on the backend or desktop applications. Considering I haven’t even been to anything of this sort as a regular attendee, let alone a presenter, this can mean only one thing: I’m a little scared. But I’m excited by being scared. I figure if I go too long without a little professional fear of the unknown it means I’m getting complacent. And what better place to screw up than a tiny code camp on the sunny, rural California coast?

But now Opera has started publishing the Web Standards Curriculum. Thank God! Now anyone looking to dive into web development will have a base to start from, written by some of the smartest players in the game. (Hat tip to Roger Johansson for bringing this up.) Now instead of covering many of the same topics, I will simply defer you to the WSC. After Opera posts the last of the articles, I will revise my list of topics and expand on the areas that I find of particular use or interest. In the meantime, I’ll look forward to spending some time on personal projects I hope to share in the near future. Now get reading!

First Some History

Back in the Wild West days of the web the definition of HTML was constantly evolving. New elements were being proposed, discussed, rejected, and agreed upon. The pioneers of this language were passionate and dedicated to developing a solid, open standard everyone could live with.

As the web started picking up steam a number of browsers surfaced. Before long, one gained a vast majority of the market share: Netscape. After enjoying such success, the people behind Netscape began interacting less with the community dedicated to HTML standards, and started implementing their own HTML elements and attributes. This is how I imagine a typical conversation between Tim Berners-Lee and Netscape went down:

1. TBL: Hey guys, what’s up with this bgcolor attribute?
2. N: Pretty sweet, huh?
3. TBL: Guys, this isn’t what our language was meant to do. It was meant to link documents containing useful data together. We’re not putting this in our standard.
4. N: Oh really? We have a better idea. How about you suck on it, then put it in your standard.
5. TBL: Excuse me?
6. N: What are you going to do? We’re the most used browser. Put it in or we’ll beat you up. Nerd.
7. TBL: …Fine.

Even then, 13 years ago, a consortium of web professionals were bickering over the inclusion of stylistic elements in markup. Of course, around this time Microsoft started shipping Windows 95 and including Internet Explorer. These two browser leaders were both guilty of creating their own proprietary tags and features. Some pages would break if viewed in the wrong browser, forcing either the user to switch browsers, or the developer to make two versions (or one version containing neutral elements). The idea was that if one browser created a feature that rocked the world, the others would have to similarly implement that feature, or start losing market share to the “superior” browser. That was the idea.

Hello Standards

The competition might seem like a good idea at first glance. Maybe it was. Maybe it drove both browser vendors and standards groups forward. But what went wrong?

For one, the browsers didn’t always give us proprietary features that advanced HTML. Some of them just plain hurt. The original Netscape included the abomination known as the blink element. Microsoft, not wanting to do be outdone in the steaming pile of crap department, concocted the marquee. So what? Look at this in Firefox. Enough said.

Second, the Internet became too big. There came to be too much content and too many content producers for everyone to have to play a big game of tug-o-war. Sites became like TV channels. Except you would have to either buy two TVs or networks would have to broadcast two feeds. There was just way too much overhead, and the Internet collective wouldn’t have it. The web needed a well defined language for developers to code and browser vendors to render.

Back To The Future Present

So without getting into the gritty details of consortium past and present, here is where we stand. The W3C is the working group that oversees today's HTML and CSS specification. It has been a full 10 years since the CSS2 specification was released and 9 since HTML 4.01. These remain today the de facto standards for web development, and the latest full release of the most widely used browser today (Internet Explorer) still does not fully support the CSS2 specification. Other browsers do anything from only slightly better to an immaculate job.

And you know what? We're getting close. It's been a slow road but we are now far beyond the point where grotesque hacks are necessary to get pages to render in a usable fashion across all major browsers. If you've ever developed a page using tables for layouts, this is one such hack. The HTML 3.2 specification included tables before the world had fully shaped out CSS, and some asshat took it upon himself to discover that tables could be used to achieve relatively complex layouts across browsers without too much trouble. A decade later we're still paying the price. Today this trick is no longer needed. If you can help it, don’t become part of the problem.

These are just a few crappy definitions I pulled from some online dictionaries that suit my purpose, but know them well. If there is any one thing I could hope to impart, it would be the ability to recognize these three facets of website implementation. I cannot stress enough how much a site’s content, presentation, and behavior need to remain separate.

We will get into exactly how to use these things in greater detail later, but for now we’ll look at the basic dos and don’ts.

Content (HTML)

The content of our pages, all of the text, forms, links, and certain images will be represented in markup. For the most part, it is easy to keep the content in the HTML. Where amateur web producers start to fuck things up is using HTML for something other than the content. This is called presentational markup and it was invented by the devil. What we’re looking for is semantic markup, that is, markup which carries a specific meaning within the content. Here are some common HTML elements and attributes that shouldn’t appear in your markup:

• <b>, <i>, and <u>: The tags for bold, italic, underline, and others of the same breed appear useful at first. You'll see web producers advocating the use of <strong> and <em> instead, but why? <b> and <strong> both give us bold text. What makes the <em> italic better than the <i> version? Well, what does <em> mean? It means the text carries emphasis. What does <i> mean? The text is italic. To say that a section of text is italic is to imply that it should be rendered a certain way, whereas emphasis implies something about the text beyond how it is seen. This text matters. Since in the end we can control the presentation of either tag, why not use the one with some semantic gusto?
• <font>: This is an old tag, but you’ll see people use it every now and then just the same. If you want to change the color, typeface, or size of a font, use CSS. Period. Never use this ever, ever, ever.
• <br>: As you get into building sites you will be tempted to use this tag to move to a new line. It is the wrong way to accomplish this goal 99.99% of the time. People will use this tag to get space between two paragraphs instead of simply having two <p> tags. It will be wrongly used to force a new line to create a vertical list instead of using a real <ul> or <ol> list. In general, what the <br> accomplishes visually can be accomplished using CSS, and is typically used by those without strong CSS skills.
• <hr>: It creates a horizontal bar. This is a visual element. Enough said.
• style, align, color, bgcolor attributes: These attributes affect an element’s appearance and clearly violate our goal of separation. Use CSS selectors and attributes to target the element.

It should also be noted that <table> and related elements, as well as <frameset> and related elements should not be used to achieve page layout, but this is enough of a problem that we will address it in greater depth later when we discuss CSS layouts.

Presentation (CSS)

I’m not going to lie. Getting comfortable with CSS takes practice. There are only so many things that can be said in the beginning without diving in and learning the intricacies the hard way:

• Learn the box model well. Knowing exactly what constitutes the width and height of an element will save hours of frustration. With that being said…
• Get Firebug now for the love of God. When something funky comes up, nothing will help you debug your CSS quicker than this must-have gem. We’ll talk more on this later.
• Keep reference handy. Especially at first. You’ll find yourself asking things like, “How can I get that <hr> you told me not to use with CSS?” Good reference will tell you all about your border options. <br>? Margins. Bold text? Font-weight. Underlining? Text-decoration. If you’ve been making websites using the tags and attributes listed under HTML no-nos, you will want to keep something handy to learn about their CSS alternatives until it becomes second nature.
• Ask the right questions: If you know somebody knowledgeable in the art of CSS creation, don’t be afraid to ask them some simple questions, but don’t have them write CSS for you. If possible, have them explain the whys behind the problem and solution. Learning those will be times-over more valuable than the temporary fix.

Behavior (JavaScript)

When you’re starting out, this is of little to no importance. We’ll also be discussing this in great detail, so suffice it to say for now, if there is some user interaction involving elements being hidden, moving, dragging, etc. it will nine times out of ten be a product of JavaScript (assuming we aren’t dealing with Flash).

I imagine this post will become more useful once you start building something. Every so often take a step back and refer to it just to make sure you’re keeping with the basic principle of separation.

A friend and neighbor of mine is in middle of her quest for a Graphic Communications degree from Cal Poly. I asked her if she’d done much in the way of Web Development. Of course not. Her classes only used a pinch of Dreamweaver and taught some rudimentary CSS. She did, however, believe this would be a valuable skill to learn, so I agreed to do some teaching. Yes! I have an apprentice!

Just to instantly digress on my first post, school curriculum is a joke. The process of accreditation for Computer Science, and I assume other majors as well, takes a few years. Also, at least for Cal Poly, students are regularly taking 5+ years to graduate. When you consider that a student can graduate under any catalog that is released while they attend the University, and many graduate under the same one released their freshman year, seniors are taking classes that were decided to be pertinent 8-10 years prior. Can you imagine sitting around in 1999 thinking about what a programmer, let alone a web developer, would need to know today?

Just don’t count on school to teach you what you need to know. A little passion to learn independently is required.

Anyways, I figured if I'm going to teach my minion apprentice a few things, I might as well share what comes of it with whoever wanders by. Here is a list of topics I plan to cover. This is almost certainly going to change, and each “lesson” will build upon the others and discuss more advanced topics. My aim is to cover the essentials needed for the modern front-end web developer. If you have any suggestions for further must-have lessons, please comment.

• Separation Of Layers: Content, Style, And Behavior
• Web Standards?
• Standards Compliant Markup
• Introduction To CSS
• CSS Layouts
• Advanced CSS Techniques
• Introductory Javascript
• Graceful Degradation
• Web Accessibility
• Javascript Frameworks
• Search Engine Optimization (SEO)
• Progressive Enhancement With CSS3
• Browser Targeting And Quirks
• Server Side Languages