And time and time again I have to explain why there is no such thing as “the fold” online and why we should focus our efforts on designing for clarity and readability rather than worrying about how much scrolling a user will need to do.

The fold does not exist*.

The term “above the fold” is a print world term referring to making sure a newspaper’s headline or main front page image is visible when the paper is folded in half on a newsagent’s shelve.

In the world of digital, online publishing and products the term is used to describe the desire to make sure that the most important elements of each screen’s design were visible without the need for a user to scroll down “below the fold”. Which was an admirable aim and design philosophy back in a time when web design was still an emerging discipline.

We as designers had not learnt important principles like how navigation design and information hierarchy helps to orientate users within our content. Users weren’t used to having to scroll to interact with the web, in fact; users weren’t used to interacting with the web at all.

But, those days have past. Today we as designers know how to organise content, how to structure the information on a screen and, even more importantly, users have learnt to scroll.

I have never once sat observing a user during any usability testing and seen them give up the task in hand because they had to scroll a page. They may have not been able to find what they were looking for, or they may have not understood what to do next, but not once have they not known how to scroll.

In fact, one of the first things many of them do if they do get stuck is try to scroll to see if they are missing something, if there is more to see somewhere off screen. Often they will do that before using a site’s navigation menu if the labelling isn’t clear enough, “just checking if there’s a better option somewhere else.”

If you ask these same users whether they like scrolling, they will say no. “I don’t want to scroll to find things”, “I don’t like scrolling pages and pages to find something.” But when you observe them using a site or application scrolling does not hurt their progress as long as the page has been well designed.

What users say when asked abstract questions and how they behave while actually using something are not always the same.

Trying to explain this to a client can be hard. The no scrolling mantra has become universal law in the minds of those who do not design for screens daily. It is one of those mythical rules of web design that many a project manager will wheel out to show they know about the web when appropriate (another favourite, that is thankfully starting to die a death, is; “everything should be no more than 3 clicks away from the homepage” – remember that one?).

Explaining that we cannot control a user’s screen size, orientation or resolution goes some way to helping clients understand that the fold is at best a moving target. Explaining that not everyone browses with their browser window in full screen mode, or that some users have enough browser chrome to take over a third of the available window height also helps, but there is no silver bullet for changing people’s mind on this.

Sometimes I have to give in and reduce the line-height or padding or margin to fit that little bit more content on the screen for the client’s choice of browser / screen size combination.

It is their product and their choice.

I only hope that as more of us use smaller devices like smart phones and tablets to interact with the web and more of our web experience is touch driven making scrolling child’s play, more clients will let go of their believe that the fold exists and that scrolling is the root of all evil in the World.

*Okay, so the fold does exist to some degree. Not everything will always fit on a screen. And if you’re designing a page with minimal content, or designed purely as a hook to draw the user into a more in-depth process / engagement (think landing pages / sign up screens) it is worth trying to make as much of the content “above the fold” as possible on as many screen sizes as possible. But as with anything related to the web, to try and apply that rule universally to all content and use cases will not work. Be sensible and be guided by your content, its purpose, its audience and their needs.

What is not so great is that many organisations still seem to be of the opinion that designing their product’s user experience is something that they can do after they have built it. They confuse user experience design with the graphical bit of user interface design and incorrectly assume that both can be added at the end of a project build as the polish on top.

Both assumptions are wrong; user experience design and the graphical component of interface design are not one in the same. And neither should, or can successfully, just be added at the end of a product’s development as the “polish on top”.

The look and feel of a product’s interface plays a big part in the user experience of said product, but it is not the only thing to consider. There is also the product’s information architecture, interaction design, information design and navigation design to think about. The design of each of these elements should be driven by your content requirements and functional specification, which in turn should be guided by your user needs and product objectives. Once your product has been built it is too late to change all of these elements of its design.

You can’t add a great experience to a product that is already built to work in a specific way. A technology driven development process, where design is considered an optional extra to bolt on once you have built something is wrong. To create a great user experience for your customers, you need to be designing your product with them in mind from the start; for web based products that means you need to adopt a user driven approach to your development, designing your product’s interface, process flow and experience before developing the underlaying technology.

Jesse Jame Garrett was spot in his book The Elements of User Experience. To have a great final product with a great user experience you have to have been thinking about delivering that great user experience from day one of your project. You sow the seeds of success when you ask that first set of questions about what do the users of this product want and need? If you can’t tie every decision you make about what your product does and how it does it back to the answers of those simple questions, your user experience will not be a good as it could be, and no amount of polish will change that.

Going through this exercise I’ve noticed a change in trends of what clients are looking for.

In days gone by I’d get requests like “make it like Amazon / Google / Ebay / insert-poster-boy-application-of-the-day-here”

The most common request I get for now from all clients is: “Make it simple” (often followed by; “like Apple do“).

As someone who spends a lot of his time thinking about the holistic user experience of the applications he designs, I love that they want simple. But I know that making something look simple and making it simple to use are two very different things; many of my clients don’t.

When they say make it simple, they mean make it look simple. They mean make the interface sparse. They argue for one word where three are needed to explain the context of a label. They argue for removing icons or background colours where they are intended to add meaning to elements on a screen. They argue in favour of text being bunched up, smaller and badly spaced so it takes up less room on a screen, so it fits “above the fold”.

They lack an appreciation of the difference between simple and sparse. Between merely looking at or admiring an interface and actually using and interacting with it.

To paraphrase the excellent Mr Steve Krug; “A web application’s interface should be obvious“. It should be self-explanatory. A user should look at every image, every label, every heading, every input or button and know what to do with it, know its relevance to them in their quest for information or task completion. They should not have to think about how it may work.

One word labels like “Filter”, “Save” and “Add” without very careful placement or grouping with the things that they are related to can raise more questions than they answer. “Filter results“, “Save settings” and “Add a user” are more self-explanatory and even when carefully placed next to, or grouped with, their related interface elements still serve to re-enforce their meaning and reassure the user about what they are referring to.

While I once spent my time encouraging my clients to remove the guff and bloat that they insisted on adding to every screen of their applications, I now find myself spending time encouraging them to add just enough back in to make their interfaces understandable and meaningful.

Figure 1 The new JMCQUARRIE.co.uk homepage design

Those of you who follow me on twitter (@jmcquarrie) will know that I revealed a new design here at jmcquarrie.co.uk this week.

The update was much needed and incorporates a number of changes that I’ve been meaning to make since I launched the last version of the site just over a year ago.

The previous design was done while I was still very new to the world of freelancing and when I wasn’t entirely sure who the audience for the site was or what message I was trying to get across. As a result the old design didn’t hold together as well as I would have liked and, as I learnt more about myself, my craft and my offering, became less and less relevant.

As a direct result of not being 100% sure of what I wanted to say with the old site the overall page structure of the site was left fairly open with a strong mast and footer, but with a weak layout for the actual content. This redesign aims to address this.

The overall goal of the redesign was to tighten up the look and feel, giving each page more structure and a better visual hierarchy. I also wanted to hone the message and bring my portfolio and blog up to date.

Understanding my audience

Last year’s design process started, as I always do for a new project, by me looking at the audience for the site. The problem was, as mentioned above, I wasn’t entirely sure who the audience for this site was. Was it potential clients? Was it recruitment consultants? Was it my peer group? Was it web agencies? The truth was that it was all of these, but at the time I couldn’t see that or decide which group to focus on. For this redesign, I’ve focused on the potential client and recruitment audiences as my primary concern with the other groups acknowledged, but given less relevance.

For my target groups the site serves as an introduction to me, what I do, what I can offer them and gives them an overview of what work I’ve done in the past. To meet with their content requirements, I’ve striped back the homepage, and the overall Information Architecture of the site.

The homepage is now fairly sparse, designed to achieve three things:

1. sell me in one sentence
2. give those who are interested an easy way (with clear calls to action) of discovering more about me and my experience
3. make it very easy for people to contact me (again with a very clear call to action).

My blog, despite my best intentions, is not updated as regularly as I would like and so has not been highlighted as a call to action on the homepage and the previously present “recent articles” section has been stripped out as they only serve to distract from the above three things. My blog can still easily be accessed via the global navigation, but I’ve made the decision to let it take a back seat as far as the homepage is concerned.

While thinking through the homepage design, and having analysed my Google Analytics stats I was conscious that not everyone arriving at the site does so from the same place, or with the same prior knowledge of who I am. Which meant that I needed to cater for their different expectations. But, I also wanted to keep the homepage design minimal and focused. So, instead of cluttering up the homepage with content for all, I focused in on my three main traffic sources; organic / direct traffic, twitter traffic and Linkedin traffic and for each group of visitors I have created a landing page that (I hope) gives a slightly tweaked, more relevant introduction to me, my work and the site for each group.

Whether these traffic source specific landing pages will work or not, I’m not sure, but I like the idea that they may, and will be keeping my eye on how they are used and what impact they have.

You can see the three versions of the landing page at:

• standard homepage for organic / direct traffic with a generic all round introduction: jmcquarrie.co.uk
• twitter traffic for those who click through from my twitter profile and who know a bit about me already: jmcquarrie.co.uk/welcome-twitter
• Linkedin traffic for those who click through from my Linkedin profile and who should have a stronger idea of what I do before arriving here: jmcquarrie.co.uk/welcome-linkedin

Figure 2 An example of my new portfolio pages

Updating my portfolio – focusing on the process as well as the outcome

The portfolio section of my previous design was a bit of a haphazard affair. Each project page was designed differently, with different numbers of differently sized screenshots and varying levels of explanation about the work that I’d done relating to them.

Having now gone through the interview process for a number of freelance and contracting roles, I have a much better understanding of what my portfolio needs to show off. The end product is useful to see, but as a User Experience / Information Architect it’s the process that I used to arrive at the end product that most people want to know about. My portfolio now reflects this a little better, and will be seeing more improvements as I update each project page with more of the artefacts from my work and add more details of the processes that I follow to arrive at the final deliverable for each project.

Figure 3 The new about James page

Saying a little more about me

The biggest change to the design of the site has been to the About James page. Gone is the generic “Hi I’m a London based UX person who enjoys cooking and the outdoors” and in comes three things:

1. an explanation of what I do and offer potential clients
2. a breakdown of my skills and what I can and can’t do
3. the background story of how I got into the UX game and how my approach has been influenced and developed over the years

The idea was for the page to act as a more of a bio than a formal CV that potential clients or recruitment folk could read to get a feel for who I am and how I approach my work.

For the background story bit of that page I wanted to give readers a sense of how long I’ve been working in the web and UX space and hope that by including key web and tech events interspersed amongst my own experiences I can help people frame how my career has progressed in context of how the industry has developed over the last 10 years or so. When I started out UX wasn’t a buzz word, iPods iPhones and iPads didn’t exist and most people had barely got to grips with email let alone the web.

Summing up

Ultimately this update isn’t a huge revolution of a redesign, but more of an evolution. A reflection of a better understanding of the site’s purpose and how I should use it. It will no doubt continue to evolve, but for the moment I see that near term evolution being on a much smaller scale and in smaller increments.

I’ve had a Google Reader account as my RSS feed reader of choice for several years now and for a long time I would log on and check it religiously every day. I’d spend at least an hour a day scrolling through the 1,000+ new blog posts, articles and links that the various feeds that I subscribe to had posted. I felt like it helped me keep my finger on the pulse of the latest and greatest happenings from around the web. It was a massive step up from the days of having to go to every site I liked one at a time to see if anything new had been written since my last visit.

Then Twitter came along (or rather I started using it…) and I found that a lot of what I was reading via RSS was being tweeted about and that it was a lot more interesting and felt more instant to use twitter to inform me what was going on. Tools like TweetDeck meant that not only could I follow and organise what was going on in the twitter world, but I could do so from my iPhone as well as my laptop and the tweets came to me without me having to log in and refresh a webpage, allowing me to feel connected and informed all day every day from anywhere. Over time checking my Google Reader account for news started to feel both redundant and like a chore, especially when thanks to the UI I was having to scroll through every single article in order to see the headlines of each.

Reeder changes that. Now I have a RSS feed reader on my iPhone, and on my desktop that tells me when there’s something new to read. It lets me feel connected again, and it does so beautifully. I’m checking my RSS feeds daily again, in fact several times a day. If I’ve already seen something via twitter it doesn’t take much to scroll past and ignore it and, more importantly, Reeder lets me scroll through just the headlines of articles, letting me scroll past and ignore anything that I’m not interested in. This alone makes Reeder 100 times better than Google Reader, but that’s not the only advantage Reeder has over Google.

Figure 1 The beautiful Reeder for Mac (Beta) User Interface.

The understated Reeder UI is a work of art. For a long time I have argued that an Interface Designer’s job is to make the app / site disappear and to make the content stand out and easy to interact with. The folks behind Reeder have done just that. It’s the content that is the focus with settings, options, actions and even the application’s chrome taking a back seat until you go looking for it both in the desktop and the iPhone versions. The interaction design is also streets ahead of the default Google Reader, letting me skim through content or dive deep into every article in a very simple and efficient way.

Minimal chrome. Simple, limited actions. Beautifully subtle colour scheme and design. Love it.

I’m using the Beta release for Mac (Download Reeder Beta here) and I’ve bought the iPhone version. And the best bit of all? They syncronise with each other, so if I’ve marked an article as read on the desktop then it appears as read on my iPhone. Even Tweetdeck hasn’t quite got that sorted yet…

When I finally give in to temptation and get an iPad (I’m holding out for iPad 2) I’ll be buying the iPad version too and love that all three will permanently be keeping me up to date with the goings on in the World in perfect, sync-ed harmony.

Launched over the summer, I’d like to draw your attention to some recent client work of mine; The CV Nurse.

The CV Nurse (Islay Dring) has been working in the world of recruitment for 10 years and has in that time read over 40,000 CVs. She’s now using her experience and expertise to help you (or anyone you know…) land your dream job by reviewing your CV and helping you perfect it in return for a small fee.

She offers two services;

1. A simple CV review – for £20 you can send her your current CV and she’ll review it and send you back some notes for how to improve it
2. A consultation and review – for £50 you can have a quick telephone or skype chat with her to help her understand your experience and the job that you’d love to do and she will then look over your CV and send you notes and tips for improving it.

In a time when the job market is proving harder and harder to navigate having an expert review your CV could make all the difference between landing the perfect job or not.

The evolution of the design

While working on the site I wanted to somehow show the design process and share some of the thinking that went into the look and feel and layout. So, after sketching some rough designs out on paper I jumped into the code and decided to take screen-shots of the design as it progressed from naked HTML to a fully styled, polished and completed design. In the resulting video below you can see how the bare bones version of the homepage developed into the final version that you can see live on the site today. You can also see how the design changed and evolved through the process of building it.

I hope that the video gives you some insight into how I work through the process of designing a web page and how the design itself changes over time as things progress. Enjoy!

As of today I am a gun for hire. Available to work on designing your latest project. Available to help you change the World. Available to make you, your company and your web sites / web applications look good and delight your customers.

Having spent years working in a corporate world it feels good to stride out on my own and be able to offer my web design services more widely than to a select few organisations chosen by someone else. I can now work on projects big or small that are interesting, fun and exciting without having to convince someone more senior than me that it would be a good thing to do.

So what am I offering?

Well, for those that have been here before you will notice that along with my big announcement this site has undergone a fairly large face lift. A face lift that is designed to explain a bit more about what I do and what I can offer you and your company as well as giving you a view of what I’ve designed and built in the past.

The Services page describes what I can do for you and your organisation, whether it be redesigning an existing website, designing a brand new website (or blog), or even designing the interface for a huge enterprise level web application, I can help. It also lists details of my contracting service and my slightly different partnership service.

The Portfolio page shows some of the web design work I’ve done in the past for others, to give you an idea of what I could do for you and your project. It also describes how I work, what you can expect from me and, maybe more importantly, what not to expect from me.

As well as the new Services and Portfolio sections of the site, this Writing section of the site has had a make over and I plan to continue publishing articles about web design, start ups and other industry and business related topics here. All of the articles that were published in the old version of the site over the last few years are still here too.

For those who want to know a little bit more about me, there’s the About section which contains a short introduction and a link to my full CV for you to browse should you want to know more about the corporate life I used to lead.

If you have any questions about my new freelancing venture, or about what I might be able to do for you leave a comment with this article, or get in touch using the Contact page and I’ll do my best to answer your questions and help out in any way I can.

Here’s to a bright, freelance future. Thanks for reading.

In part one I expressed my frustration with the misunderstandings surrounding the use of tables in standards based web design. In part two I talked through the elements available as part of the table and some of there attributes. In this, part three, I’ll give three examples of how to construct meaningful, semantically correct, accessible tables using those elements and attributes. I’ll also show how some simple CSS can spruce them up and make them suitable for even the most elegant design.

I’ve published each example on it’s own page so you can copy them as is to use yourself, click through to see each one.

Example 1 – School exam results

In this first example I’ve used a classic example of tabular data; a set of exam results. The results in question are the fictitious results from three summer exams for both boys and girls at a secondary (high) school. The three exams sat were: English Language, English Literature and Mathematics.

Example 1 – School exam results

A quick peek at the source of the example page will show you that the thead, tfoot and tbody elements have been put to good use here to separate out the headings across the top row, the data rows and the overall totals at the bottom. Using these elements not only lets us add logical meaning to the data, but it also lets us style those areas of the table differently using some simple CSS (all the CSS is in the source of each example for completeness).

Eagle-eyed readers may also have spotted a new attribute that I’d not included in the previous posts; “scope”. Setting the scope attribute will let assistive technologies explicitly tie each heading to the data cells it applies to; in this example letting screen readers read the headings out before reading the numbers of students with each grade. Thanks to Mr Christian Heilmann and his Automatic conversion from simple, accessible data tables to YUI Charts article over at the Yahoo! User Interface Blog for making me aware of this attribute and its importance.

Example 2 – A system dashboard

This second example is a little bit different. I’ve mocked up how to potentially use a series of tables to create a “dashboard” overview screen for a user in a web application (something I’ve had to build for 99% of all the “enterprise” applications I’ve ever worked on)

I’ve used the example of a Request For Quote (RFQ) application which basically allows people to get in touch with a number of potential suppliers and ask for a quote for some materials / work they want them to do. Once sent out there are three types of RFQ:

1. open – those that are still open for reply from the suppliers contacted (RFQs generally have a “respond by date”
2. closed – those that have reached and past their respond by date. These need the person who set them up to look through the responses and decide whether to pick a winning supplier, re-issue or complete them without a winner
3. completed – these are RFQs that have either has a quote that has been accepted, has been with drawn or has been completed by the person who raised it without picking a winner.

Example 2 – RFQ Dashboard

Note how in the Completed RFQs table the footer is used to provide navigation to the archived RFQs. This same technique could be used for a table of search results if there are two many to display at once. The “Results page: 1 2 3 4 5” links could be placed in the footer of the results table to tie them semantically to the currently displayed results.

Example 3 – Mixing in a little more CSS to sex-up data

This final example shows how with a little lateral thinking you can mark up a set of data in an accessible, semantically correct manor and still make it look great (or at least, more colourful) for the more visually orientated out there.

This is a very simple example of what can be done. For more advanced demonstrations I’d recommend Mr Eric Meyer’s CSS vertical bar graphs.

Example 3 – Using CSS to add colour

To achieve this effect a little work would need to be done on the server side of things to generate the correct values for the class attributes, as the CSS relies on the class to determine the position of the background image.

So there you have it, three different ways of using the table and its associated elements and attributes. I hope these examples have given you some food for thought. Feel free to use and abuse them, they are free for use however you see fit.

Web Standards doesn’t mean no tables…

Lets get this out of the way first: Yes tables should not be used for laying out entire web pages. But, nowhere in anything published by the W3C (our guiding light when it comes to the correct use of HTML) are tables banned. In several places they (the W3C) advise that tables should not be used for layout, but never are they ruled out completely. On the contrary, in WCAG 1.0 Guideline 3 it states;

”…it is appropriate to use the table element in HTML to mark up tabular information […] using table correctly and creating tables that transform gracefully makes it possible for software to render tables other than as two-dimensional grids.”

So let’s accept that the table is indeed a useful, standards compliant, accessibility friendly and semantically correct tool that all HTML coders should have in their arsenal of markup weaponry.With that agreed let us look at the element and its associates.

The table, table rows and table data

Most web designers will be familiar with these three most basic elements of a table. The <table> tag itself, simply, defines a table. All table rows, data, etc should reside in a table element.

The <tr> tag defines a table row and usually contains a number of data cells (at least).The <td> tag defines a table cell (I believe the D represents “data”). These should appear nested in a tr. Putting these three elements together allows you to devise simple tables of data like below:


<table>
<tr>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>40%</td>
</tr>
<tr>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
</table>


Which results in:

Most (if not all) tables of data also need some sort of headings in order to make sense. The <th> (table header) tag is available just for this purpose.

The th tag has to sit inside a tr tag and is used in the same way as the td tag. Its contents are usually displayed in bold (the default in most browsers) but can be controlled via CSS if need be. It should be noted that using th tags just to make something bold is not correct, use CSS or the <strong> element for that.

Adding th tags to our simple table makes it a little easier to understand, increasing its accessibility.


<table>
<tr>
<th>Student</th>
<th>Result 1</th>
<th>Result 2</th>
<th>Result 3</th>
<th>Result4</th>
</tr>
<tr>
<td>Mark</td>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>40%</td>
</tr>
<tr><td>Sarah</td>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
</table>


Which results in:

Head, Foot and Body. In that order

Many tables you will have to deal with, especially if like me you work in the realm of “enterprise applications”, will be much more complex than my simple examples here. In fact they will be much like a good story; having a beginning, middle and end. Or in our case; a head, body and foot.

The <thead>, <tfoot> and <tbody> tags allow you to group sets of table rows into logical collections.

If you use one of these elements, you must also use the other two. They must be used in the order they are written here; thead, tfoot, tbody. This, slightly counterintuitive, ordering allows for something quite special to happen in browsers. If your table has a billion rows a users browser will take some time rendering them. By placing the foot of the table before the body in the mark up the browser is able to render the foot before completely loading all the body rows. On the screen the foot will still appear below the body, but will be rendered along with the table head first, letting the body rows appear like the filling to a data sandwich.For those who use CSS to style up their content, the thead, tfoot and tbody tags offer some convenient hooks onto which styles can be built without having to resort to nasty, bloating, class or id declarations within the tr or td tags.

Adding these elements to our example makes the whole thing more semantically correct, but results in no visual difference in most browsers that I know of.


<table>
<thead>
<tr>
<td>Student</td>
<td>Result 1</td>
<td>Result 2</td>
<td>Result 3</td>
<td>Result 4</td>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="5">foot</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Mark</td>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>40%</td>
</tr>
<tr>
<td>Sarah</td>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
<</tbody>
</table>


Which results in:

Captions, colgroups and cols

The <caption> tag should only be used directly after the opening table tag, and there can only be 1 per table. I would only use this element for adding a name or ID that I want the user to see as part of the table. For example in a scientific paper you may have numerous tables of results to display, adding a caption “Table 1: Temperature results” will help users identify which table any accompanying text refers to.

In most browsers the caption will appear at the top of the table and will be centered.Adding a caption to our example looks like this.


<table>
<caption>Student exam results</caption>
<thead>
<tr>
<td>Student</td>
<td>Result 1</td>
<td>Result 2</td>
<td>Result 3</td>
<td>Result 4</td>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="5"> foot</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Mark</td>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>40%</td>
</tr>
<tr>
<td>Sarah</td>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
</tbody>
</table>


Which results in:

The final two elements that I’ll cover here are two that I have to admit I’ve never used; <colgroup> and <col>. colgroup is described as an element that allows you to group columns for formatting. The col element’s function is to allow you to define attribute values for one or more columns in a table. It must only be used inside a table or colgroup element.

Setting a colgroup element’s “span” attribute allows you to group up the columns that follow, allowing you to apply specific formatting to them. Adding the colgroup element to our example table allows me to specify the width (for example) of the first three columns.


<table>
<caption>Student exam results</caption>
<colgroup span="3" style="width: 50px;"></colgroup>
<thead>
<tr>
<td>Student</td>
<td>Result 1</td>
<td>Result 2</td>
<td>Result 3</td>
<td>Result 4</td>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="5"> foot</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Mark</td>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>40%</td>
</tr>
<tr>
<td>Sarah</td>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
</tbody>
</table>


Which results in:

The <col> tag can be used when you want finer control over each column within a colgroup. For example in the table below the col element is used to allow me to format the width of each of the first three columns separately.


<table>
<caption>Student exam results</caption>
<colgroup span="3">
<col width="20px"></col>
<col width="40px"></col>
<col width="50px"></col>
</colgroup>
<thead>
<tr>
<td>Student</td>
<td>Result 1</td>
<td>Result 2</td>
<td>Result 3</td>
<td>Result 4</td>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="5"> foot</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Mark</td>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>40%</td>
</tr>
<tr>
<td>Sarah</td>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
</tbody>
</table>

Which results in:

Summaries, colspans and Non breaking spaces

That’s the lot when it comes to elements available as part of the table. But there are three more things to look at in order to make our tables even better;

• summaries
• colspans
• non breaking spaces.

Summaries

To make the table accessible to non visual browsers the summary attribute of the table element should be set. This summary should describe what the table is showing, without getting into too much detail, enough to allow a user to know whether it’s worth them continuing to delve into the data or not.

Colspan

The colspan attribute can be set for in th or td tags. It allows you to specify that a cell spans a number of columns. Eagle eyed readers will have noticed that I’m using the colspan attribute of the td in the table foot to allow the one cell to span the entire table width.

Non breaking spaces

If for some reason you need to leave a cell empty, for example when you have no data for a particular set of results, to ensure that the table is displayed correctly you should place a   character in the cell. Not doing so will cause some browsers (older versions of IE mainly) to break the display of the whole table.

Our example table with a summary and a non breaking space added is below:


<table summary="Table showing the exam results for a number of third year students">
<caption>Student exam results</caption>
<thead>
<tr>
<td>Student</td>
<td>Result 1</td>
<td>Result 2</td>
<td>Result 3</td>
<td>Result 4</td>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="5"> foot</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Mark</td>
<td>10%</td>
<td>20%</td>
<td>30%</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Sarah</td>
<td>40%</td>
<td>30%</td>
<td>20%</td>
<td>10%</td>
</tr>
</tbody>
</table>


Which results in:

Conclusion

So there we have it. A whistle stop tour of the most common, and some not so common, tools available as part of the HTML table. Next week I shall talk through some real life examples of how to use everything discussed here in different ways to solve different problems. If you have any specific table related questions or examples you’d like to see walked through let me know via my contact page and I’ll happily work through them.

For further reading about all the elements discussed here also see The W3Schools HTML tables tutorials.

Then, only a few months into my web coding journey I read an article questioning whether tables should not be given the “old heave ho” when it came to laying out a screen in favour of the more correct Cascading Style Sheet (CSS). I was sold, the arguments made sense and I busied myself with learning every cross browser, CSS layout trick in the book to allow me to craft beautiful, semantically correct, web pages with not a table in sight. After a while I forgot how to code with tables, and in fact I would struggle to build any page (let alone a whole site) now without my trusted style sheets.

As CSS became fashionable not only to those in the know, but to a wider web building audience (and even to their clients) more and more was written about the evils of using HTML tables for layout and eventually the message got somewhat muddled and condensed, as is so often the case with such things. The message became “HTML tables are evil” full stop. No longer was layout a concern, instead misguided individuals became convinced that web pages should never be tainted by the merest whiff of a table element or any of it’s associates. I have worked with such people.

This is simply not true, and those people are simply not right. HTML tables are useful, versatile and very often absolutely the most correct, semantically appropriate element to use.

They should be used when marking up any data or information that could be deemed a set of some sort. The most obvious occasion would be when marking up some statistical matrix of numerical results, such as a set of temperature readings taken through the day at set time intervals.

Other not so obvious uses may be using them to mark up the profile values of a user (name, date of birth, address, etc) in a social networking site. I’d see this as a perfectly valid use of the element as the rows and columns afforded by the table imply the structural relationship between the values held for the user in question.

There’s even an argument to be made that perhaps the workhorse of the web application world, the humble HTML form may be best marked up in a table. The table providing the implicit relationship between labels and their inputs. I hasten to add that I’m not totally convinced by this train of thought, though after hours of fighting with CSS based layouts of some forms I’ve been tempted to adopt this philosophy wholeheartedly.

So why do I bring this up? Well while searching for a little advice on how to correctly encode some numerical data in a table a few months back I was surprised to find little written on the subject. I have become so used to Googling any CSS related questions and getting a barrage of possible answers, I never stopped to consider there may not be the equivalent for questions concerning tables and their finer details. Don’t get me wrong, there is plenty written on the subject, just little that clearly explains what options you have when trying to code tables correctly (that I could find, or follow).

So I thought I would start a mini series here explaining what I have managed to piece together about the correct, even elegant, use of the most abused element available in HTML.

Next week I shall introduce the elements that are available to the table coder. The following week I shall discuss some of the correct and incorrect uses of said elements. Then in the final installment I shall get really advanced and mix in a little CSS magic to show how data tables can also be sexy.

Stay tuned for more; “HTML tables: Not totally bad.”