As a next step, you may be interested in my 2008 presentation from WebVisions: Optimize Your Site in Seven Easy Steps. This repeats a few tips but also provides some additional steps to improve page load times.

These resources just scratch the surface of the topic, but they’re important fundamentals. If you want to optimize your site, you need to do it at every step — in your code, with the use of graphics and other assets, at the server. Building a site and trying to retrofit for optimization may help, but it doesn’t pack the same punch. (The same thing holds true for accessibility. And, like accessibility, creating an optimized site isn’t terribly difficult when planned for from the start!)

If you have any questions about Easy Steps to Improve Page Load Times, please ask and I’ll answer in another article or post!

I presented at In Control Cincinnati this year and thought it was great. As a presenter, having only 60 minutes to relay your information and message can cause you to rush — but the workshop format lengthens each talk to an hour and 45 minutes so there’s plenty of time for taking it easy, giving demos, and answering questions. I think that makes for a much better experience for attendees, too — no more furious note-taking without ideas sinking in!

As for the presenters, you’ll be learning from some industry leaders: Jared Spool, Ethan Marcotte, Kelly Goto, Stephanie Sullivan, and Christopher Schmitt. (Nope, sorry, I won’t be there… and I’m kinda jealous, because I’d really like to see these folks speak!)

Interested? Want to get $50 off the registration price? Use this discount code: INCKIMB

With a flurry of new browsers hitting users’ computers and mobile devices this year, everyone involved with the Web has had to scramble to ensure that their sites are compatible with the latest and greatest. This has left many Web professionals and business teams wondering, “What browsers should my site support?” Kimberly Blessing helps you answer that question.

Read my article at Peachpit and let me know what you think! And stay tuned for my next article on optimization…

Web developers can’t have this attitude. We absolutely must care about our craft and continually ensure that our work is demonstrative of best practices (both industry and our own signature practices). Sloppy execution of our work leads to cross-browser problems, inaccessible features, confusing user interactions, and time lost refactoring code in the future. We don’t get to give excuses to our customers — if it doesn’t work, end users don’t use the site, and clients don’t pay. Messy code shows that we don’t care about leaving something our fellow developers can learn from, and it demonstrates that we don’t care to take the time get our code right.

I shudder to think about the kind of code the baristas at the local Starbucks would write, were they developers. If only they could be more like so many of the awesome developers/craftspeople I know… then I’d be happily caffeinated each morning. And if fewer developers wrote code the way those baristas make drinks? Well, the Web might just explode from all that awesomeness.

Since the practice of setting and managing standards is as much a management concern as it is a technical concern, I spend time reading a number of business blogs. The HBR Voices blog is full of important management insights.

A recent blog post, How Are You Defying “Best Practice”?, was particularly insightful. Although the article was referring to business and management best practices, it just as easily could have been about design and code best practices.

The only difference is that, while the business world has well-documented and well-established best practices (most commonly taught in MBA programs worldwide), the Web design and development world doesn’t yet have that common set of agreed-upon best practices. What one designer or developer considers a best practice may be contrary to what another one believes.

This leads me to the question of how do you define what is an industry best practice? And, how do you defy those best practices, if at all?

Add your two cents

In the chat room, a number of questions and comments came up regarding the use of CSS hacks to address IE. I don’t know how many people were in the camp of “all hacks are bad, all CSS must validate!” versus “who cares, use all the hacks you want”, but I was put on the spot and asked for my two cents. I said something to the effect of, “Aiming to write CSS which validates is a great goal and perfectly achievable on your personal site, but when putting together a site for work or for a client, especially a large site, you may find that using hacks is easier to write and read, and will scale better over time — so long as you plan a way out.” I think that resonated with some of the folks in attendance, who have always felt that to honor the Web Standards cause, a developer always had to follow the best practices and have valid code at all times.

So, just to reiterate, no, you don’t have to have valid markup and style sheets all of the time. In fact, there are times where you’ll intentionally code something not valid — whether it’s the use of the target attribute for an anchor to make sure a link opens in a new tab/window, or whether it’s the application of a hack in your CSS, so a future developer doesn’t have to look through multiple CSS files to figure out what you did. I think this is perfectly acceptable, provided you execute the hack consciously. At almost all of the large companies where I’ve worked*, we’ve had to use hacks or deliver non-valid code. It’s just a fact of life. It’s what you know about your non-validating code, what you plan for**, that matters.

*At PayPal, we attempted to maintain separate IE6 and IE7 style sheets, called with conditional comments; this caused developers to have to write additional CSS in many cases, as the CSS architecture included a global CSS file, one or more product/flow/page-specific CSS files, and then these IE-specific CSS files. Due to the cascade, overwriting one style in the IE-specific CSS file sometimes meant writing additional lines of CSS to restore a style — unless you could ensure that tweaking selectors in the other CSS files to make them more specific would be a better fix, without breaking any other pages… perhaps you see where I’m going with this? With over 100 developers potentially working on a bit of code, decoupling IE-specific styles created a nightmare situation, which inline hacks would have solved in a way that would have been easier to read and easier to maintain.

**On the other hand, at CIM, we have no coding standards (yet), so each developer appears to be addressing browser-specific issues in whatever way they want. I’ve seen multiple hacks used in our code and backing them out later is going to be a major challenge. When you do use hacks, make sure everyone on the project/working on the site uses the same ones!

So, with that, you have my permission to use hacks and write non-validating code — just make sure you have a good reason for doing so, in case someone comes asking why you did it. ‘Cause I won’t back you up if you don’t have solid justification!

Since it’s an online conference, there are no travel expenses, and registration is only $139 for individuals! (If you want to round up a group of folks in your living room or office, you can register as a meeting room for just $439!) However, if you register via this link, you’ll get $25 off the price!

As you may have guessed from the title of this post, I’m presenting on the topic of troubleshooting IE6. Unlike most Web developers, I don’t hate IE6. In fact, it has a special place in my heart, as it enabled my team at AOL to build some of the most awesomely advanced CSS-based grids and templates ever. (No joke, I see folks still trying to do what we did back in the day!) Yes, I still get frustrated by having to deal with some of the odd bugs it presents with, from time to time, but generally I’ve learned how to plan for and work around those bugs. So that’s what I’ll be speaking to.

Of course, if you have particular pain points or concerns that you think I should address, please let me know by adding your two cents here. Thanks!

These companies, while all different, handled the release of new browsers using the same wait-and-see approach: wait until the browser comes out, see how much of the site’s traffic moves to that browser, then invest on bug-fixing only if n% of users are on that browser. Most, if not all, of the alpha/beta/RC testing was done by developers who were interested enough to test and possibly bug fix (assuming the issues weren’t major shared template problems). And they were probably doing this on their own time, because the business wasn’t going to stop business-supporting, revenue-generating development work in order to support a new browser!

I often owned the browser support matrix at the companies I worked for, but just because I owned it didn’t mean I could change it whenever I wanted. I had to convince the business teams that preparing for a new browser was worth our time and money. If I didn’t walk into meetings with current and historical browser usage statistics and demonstrations of bugs in the new browser, I would have been laughed out of the room. Simply stating that “a new browser is coming and we’d better be ready” just wasn’t, and isn’t, enough.

Other than a handful of companies, businesses aren’t in the browser business, or even in the browser support business (even though we developers may feel differently). Microsoft is right to not expect all businesses and Web sites to jump just because they have a new browser coming out, and I think that IE8’s Compatibility Mode provides a decent solution to bridging the gap for users between the old, crappily coded sites and the nice, new(er), standards-compliant sites.

I’m not jumping for joy over it, of course, because it signals that we standardistas haven’t succeeded in our education mission. There still aren’t enough designers and developers out there building standards-compliant Web sites, with or without business support, to withstand an event such as this. There certainly aren’t enough business people who understand the Web well enough to simplify the business case for standards-based development. Community and education tie into this as well.

Those who think that IE8 is going to be a wake-up call to businesses dependent on the Web are wrong — it won’t be. But it should be one to all of those designers and developers and business people who do understand the benefits of sticking with the standards: we still need to get out there and talk to our colleagues and community about standards, and help move the Web forward!

Organized largely by Christopher Schmitt, it’s a single-track conference of longer workshops. Unlike other conferences where sessions last an hour, speakers at this conference will be in control (ha!) of the mic for nearly two hours. This will give attendees the opportunity to really dive into the topics being presented!

I’m leading a workshop on my favorite topic — style guides and standards. After many years of creating and maintaining style guides, and many requests from readers like you, I’m finally working on some templates which will be part of the materials given away at this session.

If you want to be among the first to get these resources, register now! Through May 10, use discount code INCBLES to get $50 off the early bird rate. Managers, discounts available for groups of three or more.

WebVisions – May 22-23 in Portland, Oregon: I’ll be giving a talk called Web Site Optimization in Seven Easy Steps on Friday the 23rd at 2:45 PM. Register by March 31st (meep! very soon!) and the cost is only $180 for a conference pass, or sign up for a workshop for $375 and get the conference pass for only $130!

Voices That Matter: Web Design Conference – June 10-13 in Nashville, Tennesee: On Friday, June 13 at 10:15 AM I’ll teach attendees about creating design and development standards in the workplace. Use discount code WDDSPKR to get $200 off any conference package. Early bird pricing is in effect until May 2nd.

An Event Apart – June 23-24 in Boston, Massachusetts: Standing between you and lunch is where I’ll be on Tuesday the 24th at 12:15 PM; hear me talk about standards in the enterprise and then they’ll let you eat. And you can get $50 off with code AEABLESS; with early bird pricing (through May 26) get an additional $100 off.