Best-Practice Page Implementation
Best-practice is a term oft used in many technology circles to describe what should be but frequently isn’t. We will use best practice as the banner for our much improved approach to building e-commerce websites to describe what can and will be. What we mean in essence by best practice is adhering to current and correct site implementation standards: now and forever amen brother Rudi.
The importance of standards
What standards are we talking about?
• Correct use of external Cascading Style Sheets
• Correct use of external java-script assets
• Not using tables for describing content
o The W3C, in its Web Content Accessibility Guidelines, explicitly says “do not use tables for layout...”
• Correct use of image assets
• XHTML compliant mark-up
• Level 1 CSS compliance
• Semantic coding
Standards compliance means the consumers of our sites – not necessarily users but the technology that our users use to visit our sites – have an easier and therefore guaranteed better user experience, ensuring good longevity for our sites, simplicity and therefore reduced time to market and lowered cost of production
Complying with current best practice means we can build websites according to published standards without having to explicitly cater for the lowest common denominator. This takes a lot of the ‘think’ out of site implementation meaning we can build websites that:
• will not suffer as they are adjusted
• will encourage reuse
• embrace change
• are as simple
• are lean
• degrade gracefully
See how ‘lean’ and ‘simple’ address the issue of complexity as mentioned above in our ‘list of ten’? Not degrading through adjustment and encouraging reuse address one aspect of accessibility. By this I mean if one designer builds a page, Rudi can take on the responsibility without weighty tomes of documentation to support the beast. Thus, we can reduce the level of skill required to maintain pages on our sites.
Now would be a good time to demonstrate what we mean. Consider the two HTML examples below. One uses ‘old style’ table layout, inline style where the other uses standards compliant mark-up:
Retro old school style
<table cellspacing="0" width="700" cellpadding="10" align="center"><tr><td colspan="3" bgcolor="#000033" align="center"><font size="4" color="#ffffff"><b>This is a typical 3 column table layout</b></font></td>
</tr>
<tr>
<td width="105" bgcolor="#003366" valign="top" align="left">
<font size="3" color="#ffffff"><b>left menu</b></font><br><br>
<a href="css-1-column-layout.html">1 column layout</a><br>
<a href="css-2-column-layout.html">2 column layout</a><br>
<a href="css-faux-columns.html">3 column layout</a><br>
</td>
<td align="left">content area<br><br>
This page is simply a visualization of a table layout and another similar layout using CSS. This part is layed out without any css. It is all table cells and font tags. Click on the links in the left menu to view actual CSS layouts.
</td>
<td width="105" bgcolor="#003366" valign="top">
<font size="3" color="#ffffff">right sidebar</font>
</td>
</tr>
<tr>
<td colspan="3" align="center" bgcolor="#006699">
<font color="#ffffff"><b>footer - usually contains a text menu</b></font>
</td>
</tr>
</table>
Standards compliant goodness
<link rel="stylesheet" type="text/css" href="style.css" />
<div id="layoutdemo">
<div id="header">
<br />this is the same layout using css without a table
</div>
<div id="leftmenu">left menu<br /><br />
<a href="css-1-column-layout.html">1 column layout</a><br />
<a href="css-2-column-layout.html">2 column layout</a><br />
<a href="css-faux-columns.html">3 column layout</a><br />
</div>
<div id="contentarea">
<br />
content area
<br />
<p>All of the layout for this portion of the page is made using css. Although this looks like the table layout above, it is layed out with divs.</p>
<p>The main benefit with using css is the ease with which you can make changes to the site. If you wanted to add a second footer to every page on the site. For instance, an "add this site to your favorites" could be added by modifying one file. With a table layout you would have to change every single page on the site or use server side includes (SSI).</p>
</div>
<div id="rightsidebar">right sidebar</div>
<div id="footer">
<br />footer - usually contains a text menu
</div>
Page Weight
The first thing to consider is the size of each HTML segment. We can see that the standards compliant HTML is a fair bit smaller than the ‘old school’ example but when one takes into account the size of the style sheet, the standards compliant model seems to look poor in comparison(1.11Kb for old school vs 3.39Kb for the ‘great’ new standards). Not so fast! Our sites (hopefully) exhibit some degree of consistency in terms of layout and style. This means we can reuse our style sheet again and again. Now, browsers will only request the style sheet once – when they don’t have it. Subsequent requests will reuse the cached copy. This well documented behaviour represents the weight saving we are looking for. The study by Akamai Technologies and JupiterResearch that Rudi was excited to receive suggests that an average online shopper will only wait four seconds for a page to download before leaving in favour of a faster site. Indeed, site speed is second only to price in terms of repelling users. Jupiter suggests the following guidelines:
• The consequences for an online retailer whose site underperforms include diminished goodwill, negative brand perception and, most importantly, significant loss in overall sales.
• Online shopper loyalty is contingent upon quick page loading, especially for high-spending shoppers and people with more online shopping experience.
• JupiterResearch recommends that retailers make every effort to keep page rendering to no longer than four seconds.
With respect to our trivial example, saving a few Kb on such a small page seems like lots of effort for minimal return. Moneyspyder has consistently demonstrated a 50% saving in page weight to clients by adopting best practice implementation and standards compliance. Every 5Kb saved roughly equates to 1 second of download time on a 56K modem – easy savings. What if most of your users use broadband? Well, even if you are absolutely sure of your analytics data you have to ask why Google insists on such a light homepage – 13Kb. Surely there is something to page weight after all?
Robustness
We are starting to see some degree of agility already…let’s demonstrate some robustness. We can demonstrate the fragility of the use of tables by clumsy editing/inserting/deleting of table elements. See what happens when clumsy Rudi drops in a table row tag
<tr>in the middle of the main section copy – oops! Ctrl-Z, quick Rudiger!
Trying this with the standards compliant demo has no effect. Now we have strength and some great new agile concepts at our finger tips and we’ve only just scratched the surface!
Semantic Coding
Semantic coding is an approach to writing human and computer readable HTML. In essence, to write code to describe the content rather than code how the content should look. For example, the HTML below will render a page title correctly but there is nothing in the HTML to clearly identify the text as a page title for content managers, search engine spiders or browsers. The end result may appear fine to the end user but meaning and clarity have diminished for other consumers:
<font size="6"><b>This is the page title</b></font>
In comparison, humans as well as computers can understand that this is a page title. The authors intentions are clearer to all given the universal knowledge that the use of the
<h1>tag implies ‘page title-ness’:
<h1>This is a heading</h1>
So, adding fuel to our already raging fire of compliant goodness we have further reduced complexity, code bloat and having increased the clarity of the HTML we have significantly reduced the level of skill required to understand what the site does.
Repurpose Content
Significant effort is typically required to reposition or repurpose tabulated content. This ‘feature’ becomes more burdensome with every new level of tables that are introduced. Extraction of the right content section without impacting the overall page structure and reintroducing elsewhere, again without breaking the page layout can be arcane at best. Reliance on the style sheet to position content sections goes a long way to reducing the content obfuscation problem. The examples here are not illustrative of this point – way too simple. An indicative example of the level of tabular complexity that can easily be achieved can be seen on www.dell.co.uk. Using simple tools in Firefox, you can highlight the tables and the depth to which tables are nested. In comparison, the BBC homepage, whilst not perfect is very light on table usage. Go ahead, try it!
A third example amply demonstrates the ideal – http://www.moneyspyder.co.uk uses no tables. All content is easily extractable, reusable and can be repositioned with relative ease. Want to move your search box from top left to top right Rudi? With the right page implementation – no problem. Do it the old way and you could have a significant project on your hands – needlessly.
Revisit Process
With the risk associated with site changes mitigated to a large extent it is wholly appropriate to reconsider our bullet proof, belt and braces sign off process. As long as our CMS restricts the extent to which changes can be made to those areas that are appropriate then we have another item ticked. That list keeps on shrinking with these exciting techniques, Rudi’s getting closer to a solution but we can’t quite shake off those exclamation marks!
Accessibility
Leanness, simplicity and accessibility have other positive properties that cannot be ignored. Content that is simple to access and understand benefits users regardless of what tool they use to access your site. If content can be presented in a usable format to Internet Explorer, Firefox, a PDA, a screen reader or a search engine spider then all these users will have happy user experiences. This is another Good Thing!
No comments:
Post a Comment