Whether your intention is to build a site from scratch or update an old one, the end result needs to tick a few boxes:

• Displays correctly and responsively*1 on all modern browsers (or at least for your intended audience)
• Uses current coding practises and standards to reduce the amount of refactoring*2 that will be needed later
• Can be found by search engines, (let’s face it – we mean Google and probably to a lesser extent; Bing)
• Has a pleasing design that takes advantage of the browser capabilities, loads quickly, and provides a solid UX*3

You might have a few more considerations to add yourself, but to me – if any one of those criteria are not addressed, you have a problem.

Going in reverse order… if visitors don’t like your site they won’t return. Design is important. We’re visual creatures and the web is a visual medium with a rich colour palette and massively flexible & evolving canvas. There is nothing wrong in my view with starting from a graphical design perspective and working towards the functional. When the web was first gaining traction in the mid 1990’s, it might have been enough to simply “put it out there” with design taking a backseat to functionality and process. Your site had to work but it didn’t have to be pretty… it was already cool because it was on the web!

Having your business on the web isn’t cool any more, it’s a necessity. Moreover, if everyone has a site and everyone can be found, then just having a site won’t necessarily be enough to keep your business from losing market share… possibly on a global level. What to do?

Let’s sidestep for a minute and talk about the bricks and mortar of the web. I don’t mean servers, domains, and IP addresses… but the websites themselves: documents & images. A website is essentially a collection of “pages”, and each page of a site is linked in some manner to every other page. We have basically just described the web. The “documents” and their content employ hyperlinks to enable navigation to other documents and content – such as another page, a photo, an MP3 file, or a PDF etc. These fundamentals have been in place since HTML v1.0. Gradually; the types of content we can display and link to – and the level of sophistication at how it can be presented has evolved, and now we are at HTML v5.0. There have been a few interim document types over the years and most notably you may have heard of XHTML. I won’t go into the complete history here, but suffice to say we are at a time when most developers would agree that HTML5 is present, relevant, and likely in our future for a while to come.

That being the case, your first ‘filter’ question to your web design company might be, “are you using HTML5?” If not, “why not?”

The answer should be a fairly straightforward one, and if they can’t back up their argument in an easy to digest manner (or a demonstration) that ticks your 4 boxes above, then I’d strike them off your list. At this stage it’s not necessarily fair to discount them if they’re not using HTML5 – I’m merely pointing out that they should at least be able to articulate a response you’ll be satisfied with.

Getting your site found by search engines is a behemoth topic in itself. The way in which the document is constructed, such as the types of elements on the page, the frequency of various tags, which elements can be parsed or interpreted, and which will give weight to your SEO are all a little bit grey and can be overwhelming. As a business owner you really need to know that the shape your site is taking is going to lend itself to meeting the third criterion. If the developer is constructing your page using HTML4, then it really doesn’t stand the best chance of doing that… as you’re somewhat handicapped by the lack of available mark-up off the bat. Each reputable web design company will either have an in-house SEO person, or outsource to an expert, or at least recommend one that they deal with. They don’t? Off the list.

“Current practises” is also a bit of a broad topic, but as indicated with SEO – you want the best chance of longevity and not starting off already hampered by an outmoded document type. HTML5 should be your choice not because it’s bleeding edge tech or completely supersedes anything that came before it (because technically – it doesn’t)… but because it is the natural progression from what we had available in the past. It not only builds on years of experience by the W3C*4, (founded by Tim Berners-Lee), it also has a long and promising roadmap. (Unlike XHTML2 which appears to have stagnated with little activity since 2008.)

As for standards, using consistent mark-up that can be interpreted by the largest range of browsers and devices is the goal here. Whilst HTML has always been less rigid (or one might say more forgiving) than say, XHTML 1.0 – in terms of the mark-up and what passes browser checks – it does at least offer a new common subset of elements that every browser will understand. For example there are new media elements (for embedding audio & video), and graphics elements (for browser-rendered drawings as opposed to using JPG/PNG etc). There are also new structural elements for breaking up the page into meaningful sections. Whilst the tendency is (and should) be to separate the style logic from the layout & positioning, HTML5 gives the developer new tags that say more about what they are doing on the page. For example you can use a “section”, “footer”, or even “article” element rather than simply including a “div” block. The latter would still work, and it’s all down to how the element is styled – but contextually it would be less meaningful. That is a trend that seems to be handled carefully by the W3C, and we have to trust they don’t go “tag crazy” inventing things for which there are already suitable elements.

Finally we come to the buzzword of the decade, “responsive” design. For the uninformed on the topic, it simply describes an approach to optimising the style and layout of sites so that they are viewable on a number of screen sizes and aspect ratios. The idea is that a responsive page will have a “view” that is appropriate for say a desktop browser running at 1920x1080 pixels resolution, and scale down dynamically for smaller screens like an iPhone4 running at 640x960 pixels. The designer may have to take the pixel density into account as well as your computer monitor will usually have fewer pixels-per-inch (say 96 ppi) than the latest Samsung Galaxy (at 432 ppi). This can be problematic since small images will look pixelated when you expand them, and can shrink significantly if they were designed for a lower ppi (less dots).

The element positioning for multiple displays is usually handled dynamically by using “media queries” in the styling rules, (called a cascading style sheet, or CSS for short). The media queries ask the browser what the current display looks like and choose the rules most appropriate for that screen width. Another way to offer responsiveness is to create separate views or templates for each resolution. Again you could do the width detection with the CSS or using Javascript. The choice of document type here (i.e. HTML5) isn’t quite as important as it doesn’t play a role in determining the page width. However what it does offer are some cool solutions to our image sizing issues. For example you could create a “vector” image using a canvas element in concert with Javascript instead of a PNG that you might typically have used. Vector images such as SVG can be resized dynamically and are redrawn by the browser to scale up or down accordingly.

We’ve touched on some of the benefits for utilizing HTML5 and that’s all well and good you might think for modern browsers, but what do you do about older ones such as Internet Explorer 8? The answer is the same, you use HTML5 because it only adds to the standard with a superset of new elements. You can always include fall back options if backwards compatibility is a must (such as Adobe Flash), and there are many wonderful Javascript libraries that will aid in bridging the gap until the rest of the World catches up.

Footnotes: 

*1 – http://en.wikipedia.org/wiki/Responsive_web_design
*2 – Refactoring is programming lingo for restructuring code to improve or optimise it but without changing the perceived behaviour.
*3 – User Experience, or Usability. A positive UX means the interface behaved as the user expected. This is in contrast to accessibility which is about enabling your interface to be accessed by as many users as possible, often including those with disabilities or a handicap of some kind.
*4 – The World Wide Web Consortium (W3C), http://www.w3.org/Consortium/

About the Author

Larry Browning has held a long interest in creating websites going as far back as the 90’s. (Starting with sites for family and friends!) With almost a decade of professional experience as a developer, as well as having worn many “web hats” over the years in: web design, application development, database design, and system administration – Larry brings valuable skills to Woocom. Larry also likes to share his knowledge and help to bridge gaps between the technical and the layman so that everyone can benefit from what I.T. has to offer.