Web development basics
27 March 2006
Those of us who design and build for the web have witnessed some exciting changes in our field over the past few years. We've seen traction in the web standards movement, a spreading commitment to accessibility, the growth of web services, the emergence of Ajax, the development of time-saving code frameworks and libraries, and more. But how does it all fit together? As we pursue the next new and exciting development, how do we avoid taking for granted the amazing infrastructure all these changes have left us with?
Whenever I start a new project -- and from time to time during ongoing ones -- I take a step back to review the web development basics. What priorities should guide my work? Given the landscape of ways the web is accessed today, what core design and development requirements should I meet? What advice would I give to others in the same situation?
Well then, here are a few recommendations, for myself and those like me. This discussion will be mostly about front-end technical priorities, so the main back-end/infrastructural recommendation I'd make is to use systems (like Drupal for content management, say) that don't unnecessarily get in the way of realizing your front-end goals. For example: don't use a CMS that inserts invalid code into your documents!
Above all else, make sure that your site declares a document type (preferably at least XHTML 1.0 Strict) and that its HTML and CSS validate against the W3C's validators. As I've discussed before, this is simply the best way to keep your code lean and maintainable, and it sets an essential foundation for everything else I'm about to describe.
Beyond that core of valid markup and CSS, your site should also meet web accessibility guidelines and standards, such as the W3C's Web Content Accessibility Guidelines and the federal government's Section 508 standards. You can use various tests to check your site's compliance to these guidelines and standards.
But what's actually far more important than letter-of-the-law adherence to those guideline checklists is that your site really is designed and developed, from the beginning, with accessibility in mind. Keep the interface simple; organize and order content logically and meaningfully; and make sure the site makes sense in alternate browsing devices, like screen readers. On a markup level, this would mean direct, uncluttered code that's structured into semantically meaningful elements like headings, paragraphs, and lists rather than lots of meaningless divs and spans -- or worse, presentational elements like nested layout tables, hr tags, and images that contain text. Plus, if you use markup correctly, the site will not only be more accessible, but it will tend to rank higher in search engine results as well. I've found that Dive into Accessibility among others can help keep you on track when it comes to these sorts of common sense, real-world accessibility strategies. Example: a "skip to main content" link is important if your site includes a list of navigational links at the top of each page. Many major sites still don't have one.
As for browsers, you basically want to support them all. This doesn't mean that every hi-fi detail of your site has to work in, say, Netscape 3, of course. It just means that, ideally, browsers that don't support the latest standards will still be presented with a usable site -- perhaps unstyled, if they don't support css-based layouts, and perhaps not Ajax-enabled, if their Javascript support is lacking -- but informative and usable nevertheless. So the advanced features of your site should either look and function their best, or be stripped down. And the thing is, you can still end up providing the best experience to most of your site's visitors: just be sure to test advanced features in at least IE6, Firefox/Mozilla, Safari, and Opera 8, and you'll be covering most people. Ideally, you'll also test in Windows IE5/5.5 and IE 5.2 Mac, though there's been some debate as to whether accommodating the quirks of these browsers, especially Win IE5/5.2, is worth the all the hacks and extra effort necessary.
And that about sums it up. Yes, of course there's so much more beyond this. But I've found that resisting compromise on these basic guidelines helps keep projects sane and sites usable, even as the web continues to evolve in newer, more exciting directions.
On 28 March 2006 at 12:43 PM, Chris Frazier commented:
Wow - a real post! And it's a good one too!
As far as browser compatability goes, I like Yahoo's graded approach, where you establish A, B and C level experiences and make sure that browsers within that grade level are supported fully for that experience. If you build you presentation framework in such a way that it abstracts the actual nuts and bolts of it, then developing this way isn't hard.
Oh - and I've stopped using HRs, thanks to you. :)
Commenting on this post is now closed.