JMCQUARRIE.co.uk

James McQuarrie is a UK based Senior Product Manager who helps teams design, build and deliver digital products and services that delight their users.

Category Archive: Code

  1. Why growing your development team lowers their productivity

    Comments Off on Why growing your development team lowers their productivity

    Writing code and building software is one of the most complex undertakings that a group of people can start.

    The complexity stems from one simple fact; there is no right or wrong way of writing code. Let me qualify that slightly; as long as the product works there is no right or wrong way of coding it. There are more efficient and less efficient ways of writing your code. There are even preferred, industry standards and coding patterns in some areas of development, but there is no one globally approved 10 step process for coding.

    This simple fact makes the world of software development one of the most exciting to work and partake in. No two days are the same in this field, and people are constantly reevaluating, reworking and improving the best ways of producing software. This fact also means that getting a group of developers together and getting them to work on the same project is a nightmare.

    The more people you bring together, the worse this nightmare gets.

    If you have a single developer working on a system they will be very productive. They can design and write their own code, in what ever language they fancy, and as long as the end result works it doesn’t really matter how they do it, which conventions they do or don’t follow or which design patterns they have used.

    Now take this same developer and add a second to form a development team. Before these two developers can begin to design and cut their code they need to agree on their approach. They need to pick a coding language, a methodology that they will follow and a series of coding conventions that they can agree to. Once coding they need to constantly think not only about their own code, but also about how it will integrate with the code that their team mate is writing too. You’ve now got two developers who are each less productive than they would be working on their own. Let’s, for arguments sake, say they are now each working at 70% of their potential productivity.

    If one developer working on their own is represented by 100 work units, two together do not add up to 200 work units, they add up to 140 work units.

    Now add a third developer to the team and across the board they are each less productive again as they now have to spend even more time agreeing to how they will write their code and integrating with each others work. Again, for argument’s sake, let’s say each developer is now only 60% as productive as they could be on their own. You now have a team that is producing 180 work units, less than you may have thought you’d get from a team of two.

    Yes, I am simplifying things quite a bit. Yes, as a team gel and work together more and more they will improve their overall productivity, and yes once you start building bigger teams than three even with this model you’ll get more for your money. But, and this is a big but, the point is that adding another developer into the mix in the middle of a project will not have the immediate productivity impact that some folk may imagine it would and to the uninitiated that can some as quite a shock.

  2. Latest client work – The CV Nurse

    Comments Off on Latest client work – The CV Nurse

    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.

  3. HTML tables: Not totally bad. Part three: Putting tables into practise

    Comments Off on HTML tables: Not totally bad. Part three: Putting tables into practise

    As promised last week, here is the third and final part of my “HTML tables. Not totally bad.” series.

    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.

  4. HTML tables: Not totally bad. Part two: An introduction to the table element and its associates

    Comments Off on HTML tables: Not totally bad. Part two: An introduction to the table element and its associates

    Last week I wrote about my frustrations both with misguided individuals who believe that HTML tables are the result of the Devil’s work and the lack of information available to those web designers who are happy to use tables, but need a little guidance in doing so.This week I introduce the table properly, hopefully enlightening those in the “Devil’s work” camp, and helping those who’d like to know how to use this powerful element correctly.

    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:

    10% 20% 30% 40%
    40% 30% 20% 10%

    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:

    Student Result 1 Result 2 Result 3 Result 4
    Mark 10% 20% 30% 40%
    Sarah 40% 30% 20% 10%

    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:

    Student Result 1 Result 2 Result 3 Result 4
    foot
    Mark 10% 20% 30% 40%
    Sarah 40% 30% 20% 10%

    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:

    Student exam results
    Student Result 1 Result 2 Result 3 Result 4
    foot
    Mark 10% 20% 30% 40%
    Sarah 40% 30% 20% 10%

    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:

    Student exam results
    Student Result 1 Result 2 Result 3 Result 4
    foot
    Mark 10% 20% 30% 40%
    Sarah 40% 30% 20% 10%

    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:

    Student exam results
    Student Result 1 Result 2 Result 3 Result 4
    foot
    Mark 10% 20% 30% 40%
    Sarah 40% 30% 20% 10%

    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 &nbsp; 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:

    Student exam results
    Student Result 1 Result 2 Result 3 Result 4
    foot
    Mark 10% 20% 30%  
    Sarah 40% 30% 20% 10%

    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.

  5. HTML tables: Not totally bad. Part one: HTML tables are not the root of all evil

    Comments Off on HTML tables: Not totally bad. Part one: HTML tables are not the root of all evil

    Many moons ago when I was just venturing out into the World of web design and development I learnt to code up HTML designs using trusted <table> elements and their accompanying assortment of rows, table data elements, colspans and other such favorites.

    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.”

  6. CSS tip:- Using whitespace: nowrap and line-height on horizontal lists to stop splintering and overlapping

    Comments Off on CSS tip:- Using whitespace: nowrap and line-height on horizontal lists to stop splintering and overlapping

    Imagine that you are designing a web application interface for an application with multiple areas of functionality.

    Now imagine that in order to access these areas you will need to have a horizontally aligned, navigation menu running across the top of the screen (not an uncommon sight).

    Now imagine that this navigation menu will be sitting in liquid layout and will be viewed at various widths dictated by the end user’s browser window size and screen resolution.

    So far so good? Figure 1 – Example of horizontally aligned navigation menu shows how this common set up can look (click on the image to view full size).


    An example of a horizontally aligned navigation menu
    Figure 1 An example of a horizontally aligned navigation menu.

    This is a widely used design and can be achieved with minimal HTML and CSS with no problem, using CSS like this (based on Russ Weakley’s Rollover Horizontal list at Listamatic):

    #navContainer ul {
    margin: 0;
    padding: 0;
    list-style: none;
    }
    #navContainer li {
    display: inline;
    list-style-type: none;
    }
    #navContainer a { padding: 3px 10px; }
    #navContainer a:link, #navContainer a:visited {
    color: #fff;
    background-color: #933;
    text-decoration: none;
    border: 1px solid red;
    }
    #navContainer a:hover {
    color: #fff;
    background-color: #369;
    text-decoration: none;
    }

    Splinter and overlap


    Example of horizontally aligned navigation menu with splintering and overlapping
    Figure 2 An example of a horizontally aligned navigation menu with splintering and overlapping.

    However there is a common problem that affects most implementations of this type when used in a liquid layout: when the width of the menu's container is too narrow, the last list items will wrap under the first. This wrapping results in two visual effects that we don’t want;

    1. If the wrapping list item has a space in its text (eg; “Contact Us”) it will potentially splinter and wrap only the “Us” bit, leaving the menu item reading Contact on one line and Us on the second.
    2. If the list item and its background color / image is too tall it will overlap the start of the menu making it appear as if the menu items are stacked, obscuring not only the text of the first items, but also the user’s ability to click on them.

    Both of these issues can be seen in Figure 2 An example of a horizontally aligned navigation menu with splintering and overlapping and in this example page showing horizontal navigation (resize your window to see the effect).

    CSS to the rescue

    Luckily there are two simple CSS solutions to these problems.

    1. To solve the splintering problem add the rule: white-space: nowrap; to the list item rules (in my case #navContainer li). This will force the item to wrap in its entirety even if it contains spaces.
    2. To solve the overlap problem set the line-height value for the list items (again, in my case #navContainer li) to be higher than the text height (remembering the line-height values don’t need a unit, 1.2 is right, 1.2px is wrong).


    Example of horizontally aligned navigation menu with splintering and overlapping fixed
    Figure 3 An example of a horizontally aligned navigation menu with splintering and overlapping fixed.

    The results of setting these two values can be seen in Figure 3 An example of a horizontally aligned navigation menu with splintering and overlapping fixed

    See an example of the fixed horizontal navigation (again, resize your window to see the effect).

  7. 5 simple ways to make your mark up more manageable

    Comments Off on 5 simple ways to make your mark up more manageable

    George Lucas once said “A movie is never finished, only abandoned.” Luckily for those of us who work in the world of the web, while never finished, web sites and applications don’t have to be abandoned; we can always come back to them and change those areas that we feel need a tweak or two (in the same way Lucas did when he “remastered” the original Star Wars series).

    There is a downside to our freedom to tweak however; after months of work on a project it can often be several more months before we come back to the code we have written, which is (in my case at least) just long enough to forget exactly how and why we got the design working the way it does.

    Having experienced this many times and having lived through the pain of having to remember what was going on in my code from older projects, I started to use 5 very simple techniques for making my mark up more manageable and easier to come back to:

    1) Add a closing comment to divs

    At the end of each <div> element in a page I add a comment that includes the id or class name of the element in question for example: <div id="container">foo</div> <!--container--> This may seem trivial, but it really helps out when the divs fill up with a lot of content and you’re trying to find the end of a section of a page. This also proves useful for when it comes to slicing and dicing a static HTML page into includes.

    2) Make a HTML map of the main structural elements

    I first saw the 3d CSS Zen Garden diagram a few years ago have been making my own HTML maps for my designs ever since. I don’t bother with the internal elements as shown in Mr Clarke’s example as these change page to page, but mapping out the overall structure like this makes coming back to the design a lot easier.

    3) Use logical class and id names that are memorable

    This is something everyone should be doing anyway, but unfortunately there are still plenty of coders who don’t. There are still people who will name elements things like “leftCol” which is a bad idea as it explicitly ties the element to the layout and will make no sense if the content in “leftCol” has to sit on the right of the screen in an updated design. But as well as choosing a name that is display independent, the name should be meaningful; “primaryContentContainer” not something like “xl42” (which I have seen in one designer’s code). The more obvious the naming, the easier it is to “relearn” how the structure works (it also makes the HTML maps more readable).

    4) Add some meta data to your CSS using comments

    At the top of all my style sheets for each project I include a series of comments that tell the reader a bit about the file. They look something like this: /* fileName.css - description of the site or product this is for, along with any specific styling this file contains (print styles for example)*/
    /* Author: Name and email address */
    /* Creation date: DD MMMM YYYY */
    /* Last edit: DD MMMM YYYY - Name of person making the change */

    This is really useful when you have to hand over a design to someone else, but is also useful when you have to revisit a design and there are a number of style sheets that control things. Remembering which does what becomes simpler.

    5) Put Internet Explorer CSS hacks in a separate style sheet

    Roll on the day when all browsers display CSS in the same way. Until that day IE will always need some help to make it play nice. There are many hacks for common problems out there, but including them all in the main style sheet for a project becomes a maintenance nightmare. Instead use a separate “ieonly.css” file that contains all of the IE specific styling rules. Then include this in your HTML using the IE conditional include. This allows you to collect all the IE only rules in one place and simply remove them by removing the conditional include should we ever reach the mythical day when IE works like the rest of the world.

    Do you have any tips for making your mark up more manageable? Share them with us in the comments.