scriptNode

Web developers don't usually browse the net like your average surfers. We will often view pages with a critical eye, tear them apart and see how they tick. I know I do. Sure, I've got periods when I'm lazy and just feel like surfing around or watching videos. But usually the engineer in me will take over and criticize a page when I first see it. Here's what us webdevs do when we first see a webpage.

1. Disable Styles
2. View Source
3. Check the favicon
4. Validate
5. Check Firebug
6. Disable JavaScript
7. Run YSlow

Note: This article focuses on browsing with Firefox, the browser "real" web developers use!

1. Disable Styles

   The first thing I do when viewing a new webpage is hit ctrl+shift+s to disable styles and see a page in its design-free, naked state. What you should see after doing this is a really basic page with headers, text, and maybe some images. The Internet in its easiest-to-consume form, really. If nothing or very little changes, you know the page was developed incorrectly.

   Firefox added a keyboard shortcut (I believe in version 3) to map ctrl+shift+s to toggle the sidebar. I'm used to this shortcut disabling styles instead because I've been using the Web Developer Toolbar for a few years now. Thankfully, there's the keyconfig add-on to allow users to alter keyboard shortcuts to their liking.

2. View Source

   This one's a given and can be very revealing. Hit ctrl+u to view source and open up a world of shame or glory.

   Viewing a page's source reveals many things about the developer(s) responsible. It's one thing to disable styles to see how well separation of design and content was practiced, and quite another to see how semantic the page's markup is (typical things to look for include headers in <h*> tags, paragraphs in <p> tags, and lists in their proper ordered or unordered tags).

   It's also pretty revealing when a developer tries his or her damnedest to get spacing and/or tabbing consistent in the markup. It takes a lot of effort and shows a real discipline for cleanliness and organization.

3. Check the favicon

   Having a favicon can be a pretty good indication of whether a site is serious business or not. Web developers that are devoted to high performance would shudder at the thought of pushing a site live without a favicon.

   Other than the technical reasons, favicons have high visibility by showing up in your browser's tabs, can have considerable branding benefits (or consequences), are easy to make and can be really fun or just adorable. Why the hell not have one?

   ... Then again, even web standards evangelists like Yahoo! have some properties lacking favicons (Yahoo! Profiles is guilty as of this writing; I have filed a bug), so not having one only says so much.

4. Validate

   This is one of my favorites. The W3C Validator is one of the most useful development tools I've ever had access to. Now, there has been much debate about whether making a page 100% valid has any value at all. The usual consensus is to remove obvious or easily fixed errors (like malformed tags), but not to put too many resources into validation just to be valid.

   But it's a pretty good indication of careless development when a page has hundreds of errors, especially when most of them are easily fixed. Honestly, I'd say a large majority of pages have errors, and that's fine, but when a page is 100% valid, it shows that the developer(s) went that extra mile.

5. Check Firebug

   Oh, Firebug, where were we without you? Typically I will glance at Firebug to see if there are any JavaScript errors and to see what XHR calls are getting sent off (mostly just out of curiosity). The JS errors can be pretty revealing, but overall Firebug is just a great development tool that really lets you look inside of a page.

   As of Firebug 1.2, you now have to add a site to its whitelist to enable it, so I do this much less often than I used to. Oh well.

6. Disable JavaScript

   I only do this when I'm feeling overly critical or just hardcore. Maybe I simply love JavaScript too much, who knows? I don't have a quick shortcut for this; instead, up in my toolbar I click Disable > Disable JavaScript > All JavaScript, and then releod the page. Often, this tells me nothing. But sometimes it tells me that the page isn't as accessible as it should be.

   A good example is the current Yahoo! Developer Network homepage, which as of this writing doesn't properly display its footer when JS disabled (see it with JS and with JS disabled). For shame!

7. Run YSlow

   YSlow is a fantastic tool that gives a letter grade to a page based on how well it follows Yahoo!'s high performance recommendations. Again, this is only if I'm particularly bored or curious, and Firebug must be enabled so I very rarely do this. Getting a B or higher can be challenging, so it's a terrific indicator of developers that really care about a snappy user experience.

These habits are pretty common among webdevs. Hopefully they come across as endearing instead of obsessive compulsive. Either way, they come in especially handy when looking for a reason to praise a site, or when wanting to scrutinize an applicant's resume sites.

Read other articles tagged: accessibility, philosophy

Thoughts?