10 tips to write better content

Writing for the web

Writing content for the web

Writing for the web is similar to writing for print but requires even more concentration! Here are 10 tips to improve your web content and encourage visitors to stay on your site and to come back for more.

Site visitors tend to have shorter concentration spans than print readers. They can drift from one website to another to find relevant information, especially if they don’t immediately find content relevant to them. If visitors bounce because they can’t find suitable content on your pages, this will affect your search engine rankings.

Use headings well

Most visitors to your site won’t read every word you write. They will skim your pages looking at your headings to find relevant sections. Use headings to break up your content and contextualise it for the reader. Headings must be relevant to the content and give a clear description of what follows. This is usually how visitors gauge the value of your site and whether or not to read further. Ensure your headings describe the content of the section and are relevant to the page.

Summarise the section before going into detail

After the heading, each section should begin with a summary. Similarly to how visitors scan headings, they scan the first few sentences after a heading to understand its context.

Value your visitors’ time by summarising the content of each of your headings first, then go into detail in the following paragraphs. This way, a visitor will scan and read further, when they see what they are looking for.

Visitors are more likely to look further into your page and your site than they would otherwise. This is because they know what to expect.

Use lists effectively

Lists are important on the web because they contain information in summary form. Lists are a good way of providing important content.

Most people scanning a page will read a list. This is because a list is a great way of judging content without reading everything. Because of the use of bullets or numbers, they also tend to force the eye to jump to them.

How to make lists effective:

  • Use short, concise and informative lists to set out important information;
  • Organise lists efficiently;
  • Maintain a logical order (even for unordered lists);
  • Be consistent in setting out lists (use commas or semicolons);
  • Only use lists where appropriate or they lose their impact; and
  • Use bullets or numbering where appropriate.

Use links

Links are another way to direct readers to pay attention. Readers focus on links and lists equally.

You can grab attention by using styles and colour to clearly identify links within your text. Links are blue and underlined in most browsers by default. This emphasises them compared to other text. Even when you alter link styling in CSS, it is important to make in-line links distinctive.

Clarify text links correctly. Don’t be tempted to say “Click here”, “More” or “Next” when you can say “Part 2: Five more ways to improve your content”. Give your readers a reason to click on a link and always tell them what to expect.

Be clear and succinct

Writing for the web requires brevity and clarity. Use short concise sentences. Only use one idea in every paragraph. If your normal style is elaborate, edit it when you have finished.

Start removing all excess words. Instead of saying “To begin with…” say “First…” Cut your word count using this method. Web readers are not usually interested in subtle uses of language – they want clear, non-emotive content.

If you say the same thing several times in different ways, eliminate repetitive ideas. Visitors don’t want to read the same thing again.

Consistent language is important. Make sure that your use of the first, second and third person is consistent and clear; don’t jump from ‘We aim …’ to ‘I hope that …’ unless the change has been signposted. Also, don’t change your voice unnecessarily – if your content doesn’t use conjunctions normally, be careful when you do use them; also, be consistent about when you use apostrophes: i.e. “Do not” or “Don’t”.

Beware the passive voice. Ensure your content is active, direct and current. Using the active voice makes your meaning clear for readers and avoids sentences becoming over complicated. You can change a passive voice easily, e.g. “Your car was damaged by me” to “I damaged your car”; “The recommendations are being considered by the Board” to “The Board is considering the recommendations”.

Use examples

Examples are a great way of conveying your meaning. Use them liberally in well-written content to express your ideas well.

This post uses examples to explain the use of active and passive voice in the previous section.

Readers are more likely to understand an example than a concept. If your content is too abstract and your ideas are inaccessible, your readers will go elsewhere.

Speak to your audience

Coaching your audience will encourage them to continue reading but lecturing them is more likely to push them to another website.

It’s important to speak to your audience and be personable. This is even more important when writing direct content, using active sentences or instructional text. You can break your voice by making it more natural – using shortened words and conjunctions (“We’ve considered this…”, “While doing this, consider that”).

Let ideas flow

When writing content, your ideas should follow a logical order. This enables readers who are skimming your page to follow the logic even if they don’t follow your arguments or reasoning. Think carefully about the patterns that should form your content and move your content and sections around until they seem to flow correctly. Avoid any leaps from one unfinished idea to another.


Proofread your content before you publish. Make sure it makes sense, is grammatically correct and is properly spelled. Read each sentence forwards and backwards when you proofread.

Your eye skips and jumps words when you read content and your brain fills in any gaps and corrects mistakes as it goes. Misspelled words that have the correct first and last letter are more difficult to spot when reading normally. You can usually spot mistakes by reading from the last word of a sentence to the first.

When you have finished writing, read it aloud and change anything that is unclear. If you stumble over your words or need to reread the sentence, change it. Then, get someone else to read it for you and change anything they find difficult to understand or read.

Conclude with a call to action

Let’s face it, not all your readers will bother to reach the end of your page before going elsewhere. However, those that do will want to know what they can do next. You can reward them with a call to action and encouraging them to take the next step.

“Thanks for visiting, come back again” is not an effective call to action. “Find out about our services”, “Look at our portfolio”, “Get a quote for our product today”, “If you found this interesting, read this article on…” are all effective calls to action.

Avoid words that have a negative connotation when trying to encourage a reader to take a specific action: “Subscribe to our feed” can imply that the reader will need to pay a subscription fee (even when this is not the case); “Join our news feed” has a positive meaning of being part of something or becoming a member.

When using calls to action, don’t use too many and don’t confuse your readers with too many options: “Join our RSS feed and leave a comment” offers too many choices. Effective calls to action require readers to do one thing.

How to make accessible tables in HTML

Accessible tables

Accessible tables should allow data to be readable

The use of tables as the bedrock of page layout in HTML is well and truly over, having been usurped by divs. This is a good thing because it means that tables can get back to concentrating on their real purpose, which is to display complex data in a simple format. But aren’t tables dreadful for accessibility? No, they are fine for accessibility as long as they are used for their primary purpose and they are used correctly.

In this post we shall look at how to properly code a table so that it is accessible and easy to use.

The data we will use

For the sake of providing an example for this post, I have used a dataset from the UK Meteorological Office from Newton Rigg. Of this data, I am only going to use data from 2006, 2007 and 2008 (for simplicity) and I will be using the maximum temperature, minimum temperature, rainfall and hours of sunshine averaged or totalled for each month. If you want to follow along with this example, you should prepare this dataset in advance.

The theory

In theory, the table should be simple to create but as tables become more complex, so does the markup. In principle, the best way to denote table headings is using an ID attribute, which is then carried over to each table cell that relates to it. In this way, you create a grid address for each table cell similar to the way that MS Excel references each cell in a spreadsheet.

Building the table

First of all, we have to get the table started:

<table id="newton_rigg" caption="Newton Rigg weather data 2006 - 2008, UK Met Office." Summary=”This table shows monthly average maximum and minimum temperatures and total rainfall in millimetres recorded at Newton Rigg weather station between 2006 and 2008.” cols="4">


Note that a caption has been given to provide a reader with an indication of what the table is about. A summary is also provided to identify the purpose of the table. This is used in a similar way to ALT text. Together these two attributes are useful for accessibility purposes to inform those using screen readers and visitors with cognitive disabilities.

Headers or Cells?

There are two types of cells within a table:

Table Header cells <th>

These are used to describe the column/row headers within the table and should be given special attention when defining a table that will meet accessibility requirements.

Table data cells <td>

These are the cells of the table that contain actual data or information that is cross-referenced against the header cells.

Defining header cells <th>

Next, we need to define the header cells that will give each column it’s context. This is done simply by adding two table rows <tr> followed by a series of <th> cells containing the relevant heading.

Once this is done, we can add a class to the <tr> tag so it can be styled later and we can get down to concentrating on making the table accessible.

We have four columns in our table, marked as ‘Month’, ‘Max Temp’, ‘Min Temp’ and ‘Rainfall’. The associated <th> for each of these is given a unique identifier, such as id=”month”. This is what enables screen readers to read table data within context as it reads the cell. It is important to ensure that the id attribute is meaningful and descriptive.

You will also note that there are two rows of headings. This is because the year of data will change, because we are covering three years worth of data. The year <th> spans all four columns, just to make the table a little more complex!

<tr><th id="month">Month</th>

<th id="tmax">Max Temp (&deg;C)</th>

<th id="tmin">Min Temp (&deg;C)</th>

<th id="rfall">Rainfall (mm)</th></tr>

<tr><th id="year" colspan="4">2006</th></tr>

<tr><th id="year" colspan="4">2007</th></tr>

<tr><th id="year" colspan="4">2008</th></tr>

Populating the data

Next we need to populate the data into the table and this is where the ids for the headings are really important.

Each row contains four cells of data. Each of these cells is referenced back to its table headers. So, for example, the first cell is referenced to the year (e.g., 2006) and to the month. Once we have th ids in place, this is fairly simple – we reference them using the headers attribute. In the first column, we would code <td headers=”year month”> whereas the second cell would be <td headers=”year tmax”>.

The order in which the headers attribute calls the column headers is important as this is the order in which a screen reader will read out the context of the data. In this case it will read (for the first row of data in our table) “2006 January, “2006 Max Temp degrees C 5.6, Min Temp degrees C 0.6, Rainfall mm 34.4”….

<tr><td headers="year month">January</td>

<td headers="tmax">5.6</td>

<td headers="tmin">0.6</td>

<td headers="rfall">34.4</td></tr>

<tr><td headers="year month">February</td>

<td headers="tmax" class="tmax">6.1</td>

<td headers="tmin" class="tmin">1.0</td>

<td headers="rfall">63.9</td></tr>

While this is a bloated way of making a table accessible, at the moment it is the only reliable way of doing so. Future changes in HTML 5 may refine and change this method but at the moment (and until screen readers are updated in line with the HTML standards) this is the most likely method to work.

You can see the finished table from this example here and view the complete code by selecting ‘view source’ in your browser. Note, I have styled this example page to make it easier to see how the data is structured.

The Design Process

Rowers by Y

Rowers by Y

This is the second stage of the 5 Stages of Project Management series for web design projects. So far, we have taken an overview of the 5 stages as a whole and looked at how to write a successful design brief as part of the Inception stage. We are now ready to look at Stage 2, Design.

Before starting this stage, if you have completed the inception stage, you should have a well defined brief and understand the scope of the job. Without these, your project may end up with higher costs and delay because your expectations differ to those of your client. Now you are ready to evolve your ideas into some concepts to present to your client. For now, you are not actually building the site; you are designing concepts to a pre-construction stage that can be presented to and agreed by your client.

The brief may have given you a number of ideas for how to design the site and this stage is intended to consider these ideas, present the best to your client and identify the preferred option. But before you can do that you need to get answers to a few more questions and test your ideas against them.

Some things a web designer should consider:


You need to test your ideas against what users will expect to see. The users of the site are of absolute importance – if you put your navigation system at the bottom of the page, for example, is this what users will expect? Where will they expect to see the logo? There are a number of conventions that users will expect and you should consider these carefully before you decide to go against them.

You also need to consider user-specified items that should appear on the site, such as login widgets, video, interactive elements, forms, etc. How and where will these appear? How important are they for functionality, usability and ‘stickiness’ — the ability to keep users on the site. Create a hierarchy of these objects.


Really this is a subsection of Users because it describes how users interact with the site and whether it provides the functionality they expect in the places where they expect to find it. Do users have to search through 20 pages of description to get to the ‘buy me’ button? If they do, it ain’t functionin’! This is about making it easy for people to do what they want to do on the site. Functionality, to some extent, also covers speed: how quickly does the page load, how many server calls are made to load the page, does the JavaScript slow the page down?, and also how quickly can a user skim the content to find the piece that they want to read (is the typography helpful or a hindrance, is the structure of the page suitable to the content…)?


This is another important feature of any site and one that you should start designing into the site from the first drawing. In this sense, accessibility is about the colours you use — do they provide sufficient contrast? — The fonts you use, — are they easily legible? Is the content going to be overshadowed by that great picture you want to use? Are the link methods you are planning to use accessible? Have you structured content correctly, — is data stored in a table and is the table accessible?

The fundamentals of these questions will be put into practice when you start building the site. Creating the foundation of that best practice now, will make life a lot easier further down the line.

Plan the site

You should also have a clear idea of the content that will appear on the site, how pages will fit together — which page will link to which? This will help you to develop your site structure and the overall site map. This is essential for a large site but is also really useful for a small site and will help you to start structuring your Search Engine Optimisation as a core part of the page design.

Do you want to see my sketches?

Before you start anything electronically, you should use pen and paper to sketch your ideas. This gives you the opportunity to see how they look, modify them and hone them without spending hours getting Fireworks, Photoshop, Illustrator, etc. displaying what you intended and finding it doesn’t work. It also gives you some rough concepts to present to your client and seek feedback. You should only start committing them to electronic form when you have some clear ideas on paper.

Sketching a design allows you to play with where elements of a page should go to maximise visitors’ attention and optimise use of the hotspots on the page. It also allows you to ensure that visual elements work together.

What do you get out of following a design process?

There are very clear benefits to working through a design process (no matter how basic). It gives you a structure to work to and elements on which to focus; so, rather than jumping in and getting it wrong, you are able to concentrate on making the design achieve the results it expects before dedicating time and your client’s money to a concept that simply won’t work. Furthermore, it will help you to explain your design process to your client.

At the end of this stage you should be presenting your final mock-ups to your client for approval and to decide on which design to follow. This is much easier if you are able to describe the process you have followed and explain the reason you have made the decisions you have made.

The next stage in the five step project management cycle is construction. If you have developed your design well, you should have:

  • A site structure and site map
  • An understanding of the back-end data structure
  • An agreed design to carry forward
  • An understanding of what content will be required

How to quadruple your blog readership overnight

Goolge Analytics graph

Google Analytics showing a spike in traffic

This post is about how to dramatically increase the readership on your blog overnight and is based on my recent experience with Redcentaur Blog. It involves some Search Engine Optimisation (SEO), some good timing and, let’s be honest, a huge dollop of luck.

Writing successful posts…

To set the scene, I need to tell you a very short story. I recently upgraded my blog installation from WordPress 2.7.1 to WordPress 2.8 and the process did not go very well. Completely baffled, I decided to tweet for help on Twitter, meanwhile re-reading the codec and the upgrade instructions. Eventually, I got the upgrade to take hold. You can read about my experiences of upgrading WordPress by viewing the post I wrote at the time.

When I looked at my twitter replies the following day, I noticed a response from one of my followers suggesting I post an entry about how I resolved the issues I had with WordPress. This is how the post came about. I wrote it quickly to get it out and help others who were experiencing problems with their own installations.

Search Engine Optimisation

When I wrote the post, I didn’t put much thought into the meta tags or excerpt, both of which I always include in my posts. On this occasion, I tweaked the first paragraph of the post to form the excerpt and put together some keywords based on the core of the post. I called the post ‘Upgrading to WordPress 2.8 – Don’t Panic!

Subconsciously, by going against my usual instinct and not over-thinking the meta tags, I somehow managed to hit the core of the post.

Good timing

By listening to my follower on Twitter and understanding the needs of people to find answers to the problems they were having, I managed to get the post on my site very quickly and it must have had some value for many people. I offered sound advice and help at a crucial time.


Later that evening, I checked my analytics for site activity and noticed an incredible spike in the hits my site had received. Further investigation showed that this was mainly a result of Google search results and Twitter referrals.

Looking at the search results that brought people to my site I noticed that all but a handful of the top 30 results were related to the WordPress installation post I had published a few hours previously.

Table of search results

Table of search results

I checked with Google search, using the keywords used by people visiting my site and found that I was ranked in second position, right below the WordPress codec itself.

Google rank number 2

Google ranking of the post


This has been a valuable lesson about the power of writing relevant and useful posts that people need. It has also taught me the true value of SEO when it is directly linked to the content of your page. For a post that was (let’s admit it) rushed, its value has been in helping others to overcome a problem. It was timely as I saw a need and answered that demand; and it involved a huge amount of luck thanks to the follower who suggested I write a post about my experiences.

Upgrading to WordPress 2.8 – Don’t panic!

WordPress logo

WordPress - how to have an error free upgrade

Yesterday I upgraded my WordPress 2.7.1 version to WordPress 2.8. I approached this with some considerable trepidation because I remember how easy it was a few weeks ago to install the blog for the first time. In my experience, anything that is easy to install is hard to upgrade! So, I took a cautious approach and I’m really relieved I did. If you are considering upgrading to WordPress 2.8 from earlier versions make sure you back up ALL your site files AND your database first.

Most people I have interacted with over the last 24 hours have had an easy time upgrading, but there is a significant group (me included) who have had problems. It is not clear why these problems have occurred – whether it is to do with hosting platforms or certain plugins. Here is what you can do to make your install as safe and easy as possible:

  1. BACKUP. Make sure you have complete back ups of your site files AND your database immediately before you start any upgrade process. This is essential in case anything goes wrong and you need to revert to your previous state. Store these files on a different server or on a local hard drive rather than on the server hosting your installed WordPress.
  2. DEACTIVATE all your plugins. There are some plugins that are incompatible with the new version of WordPress, or require further upgrade before they will work. Some plugins will cause either a complete failure of the upgrade, or may cause serious and catastrophic failures following the upgrade. Having them active during the install could cause conflicts. Do not take any risks with active plugins while you are upgrading.
  3. DO NOT USE AUTOMATIC UPGRADE. This does not work consistently on all hosting platforms and with all installed versions of the application. I seem to have problems with automatic upgrades for plugins and the WordPress application, as do many other people.
  4. DOWNLOAD the zip from WordPress.org http://wordpress.org/download/ to your local drive and unzip it.
  5. Use an FTP client to go to your remote server and DELETE
    • wp-admin
    • wp-includes (except wp-includes/languages if you have an older version installed)
    • readme.html
    • wp.php
    • xmlrpc.php
    • licence.txt
    • wp-content/plugins/widgets (if you have this installed)
    • wp-content/plugins/hello.php
    • wp-content/plugins/akismet/
    • All other files in the root EXCEPT those mentioned in 6 below.
    • wp-content/ (except those mentioned above in step 5.)
    • .htaccess
    • wp-content/images/
    • wp-config.php
  7. UPLOAD each folder separately in the following order:
    • wp-admin/
    • wp-includes/
    • wp-content/plugins/hello.php
    • wp-content/plugins/akisment/
    • wp-content/plugins/index.php
    • all the files in the root directory (except wp-config-sample.php)
  8. In your browser, go to www.yourblogdomain.com/wp-admin/
  9. If asked to upgrade your database, click the button then log-in as normal
  10. Identify any plugins that need to be upgraded, download them, delete them from your server in your FTP client, then upload the new files. Again, do not use the automatic update feature while upgrading, especially if it is unreliable on your system.
  11. Activate each plugin one by one and test that the server continues to work. Some plugins cause a 500 Server Error sometime after they have been reactivated and this could be the next time you log in. If this happens, it is most likely to be a plugin error and it is best to activate plugins one by one over a period of time.
  12. Any plugins that do not work (I have had problems with All-in-one-SEO and YARPP), delete from your server, delete from your local drive, download again and upload fresh copies, try again. If they still cause problems, you won’t be able to use them until they have been updated by the developer.
  13. Check all of your SETTINGS.
  14. Check that your blog posts are visible and showing.


When I first installed version 2.8, I followed the quick process and this resulted in not being able to identify the /wp-admin/ address; so I could not log into WordPress. This is when I followed the procedure above and managed to install a working version of the upgrade WordPress 2.8.

Since then, I have had problems with new versions of all-in-one-SEO, which will not activate and YARPP, which causes an ERROR 500 “Internal Server Error” on my server. I am hopeful that manual installs of fresh copies of these downloads will resolve these issues.

Interestingly, when I try login to my WordPress install, I sometimes get an ERROR 500 message and have to retry several times….

If you are having a similar problem with this or future versions of WordPress, try reading my update to this blog post.

Site analytics and statistics

Recently, I wrote a post posing the question, Is IE6 dead? I described how critical it is for web designers and clients to understand who is visiting their site. Only by analysing the statistics available for site traffic, or estimating it for new sites, is it possible to decide whether or not to cater for older technology. In this post, I will show you the ‘industry standard’ tool to use and show you what will be useful to you in making decisions about the development of your site.


There’s a range of analytics tools available. The current industry standard is Google Analytics. It is easy to set up and use and provides a fairly comprehensive data set from which information can be gathered.

Google develops constantly the tool to ensure it meets the requirements of web developers and other users. So, there is additional functionality available for ‘advanced users’, making it a flexible working tool for most web sites. This is the tool I use for analysing the traffic to my own websites and Redcentaur’s clients.


I regularly check the statistics for my sites using Google and it is through this analysis that I make decisions about how to develop my sites in the future. It is one of the first things that I ensure is in place when I am asked by a client to improve their sites; it shows me how visitors to the site are able to interact with it and can show where there are serious problems.

I think it might be useful to share some of the key findings from my own site with you to show how I might change my site as a result of these stats.

1. Browser use

The biggest question on people’s minds at the moment seems to be whether or not designers/developers should still spend time on workarounds for Internet Explorer 6. The position I have taken in previous posts is that the statistics for a particular site should tell you whether or not this is necessary: if a sizable proportion of site visitors are still using older browsers (which might be the case for a number of corporate, technological or age-related reasons,) then this should inform any decision about ditching support for these browsers.

My statistics for May 2009 shows some really interesting results. IE as a whole only catered for a total of 18% of visitors, whereas Firefox catered for a whopping 58%. Safari catered for 13% of visitors. I have little doubt that this is broadly related to the types of visitors that my site attracts, particularly this blog, which is suited to design and development / technology-aware individuals who are more likely to upgrade their browsers and to use current technology themselves. This is not likely to be the case for all of my clients’ sites, which is why it is important to relate decisions directly to the findings for the site in question.

Browser share for Redcentaur May 2009

Browser share for May 2009

Delving further into this shows that the majority of Firefox users were using the latest version of the browser (3.0.10); although there was some latent use of earlier versions. Of the Internet Explorer users, 15% of all visitors were using IE 7 and 3% IE 8. None of my visitors were using IE 6 during May 2009. Good news! If this persists, I would consider it reasonable to remove support for IE 6 as a browser from this particular site. I won’t base this decision on one month’s findings though (last month showed 9% of traffic used IE 6).


Browser versions May 2009

Browser versions used on Redcentaur May 2009

2. Screen resolutions

Screen resolution remains an issue, especially with mobile browser technology gaining ground and the likelihood that smaller screen resolutions will be used to access the site. My analytics shows that all my visitors are using large screen resolutions, which suggests I’m not currently getting mobile browsers or people using very small (old) screens. I may wish to look to improving mobile browser experience on my site in the future as this is a growing segment of my market that I appear to be losing.


Screen resolutions chart May 2009

Screen resolutions chart, May 2009

3. Flash versions

If your site uses flash, you can also gather information about the flash versions your visitors are using. This is useful when developing flash on your site. As my site does not currently use flash, this is not important for this site but it would be a useful dataset if I were asked to develop flash site for a client.

Flash versions May 2009

Flash versions used by visitors in May 2009

4. Java support

As Google runs on javascript, it does not have a data set showing how many visitors didn’t have javascript enabled; all visitors identified in Google are javascript enabled. For this reason, it is always useful to compare raw visitor figures against those obtained from your hosting service or another source. Any differences should show how many visitors had javascript disabled in their browsers. This is important if you are planning to implement any javascript functionality that are core to the site — generally, it is better to use javascript for progressive enhancement of design and for back-of-house analytics evaluations.

Google does tell you how many visitors had Java supported on their platform. In my case, 10% of visitors did not have Java supported, which is quite a significant number and might affect any applications I wished to develop in the future using this technology.

Java support May 2009

Java support in May 2009

5. Connection speeds

You might be forgiven for believing that today everyone uses broadband and therefore connection speed is not important. However, for a site that predominantly uses images or multimedia, this is still a factor to consider (and not all areas of the world have high-speed broadband connections). Other factors to bear in mind are that visitors who do have broadband may still have a throttled service, might be visiting on mobile devices using 2G or 3G bandwidth or may not want to use all of their bandwidth allocation downloading a page of your site.

May 2009 data suggests there are still a small percentage of visitors using dialup. Google was not able to identify the connection speed of 35% of visitors to my site, which means a larger proportion of visitors could be disadvantaged by bandwidth munching files or repeated requests to the server for additional files.

Visitor connection speeds May 2009

Visitor connection speeds May 2009

6. Country of origin

Something I always find fascinating is where visitors come from. Unsurprisingly, a large proportion of my site visitors come from the UK, USA and Europe. There are a number of visitors from other countries and this could lead me to think more about the number of conversions that are lost through not supporting native languages. Google provides further analysis on bounce rates (the number of people leaving the site on the first page) and time spent on site, which I have not covered here, and the language settings for the operating system. Together these figures could lead me to improve my site translation or to provide dedicated sites in the key languages.

Countries of origin May 2009

Countries of origin May 2009

7. Sources of traffic

Analytics can aid understanding from where people have landed on your site. This provides a useful analysis for the value of ad campaigns, search results, link value, etc. My data shows that I have had a number of hits from Google organic searches (from search requests), from direct hits (typing the address into the browser), from social media, such as Twitter and LinkedIn and from other referrals, blogs and listings. This information is more useful when assessed in conjunction with other data to identify any parts of a site that visitors are landing on and bouncing from. Improvements should be targeted at these areas.

Traffic sources May 2009

Traffic sources May 2009


A vast array of information can be obtained from simple data. This post just touches the surface of what you can gather about the usability of your site from your visitors. Check out Google Analytics for yourself and see what surprising information it can tell you.

How to create your own Twitter background

There have been a number of blog posts covering Twitter background images. Most articles give general guidance on the dimensions of the background. Very few of them advise on where to place objects in the background. The reason for this is that the Twitter interface relies on the screen resolution of the viewer’s computer and it is difficult to optimise your Twitter background for all resolutions. This post gives some more guidance on how to develop your own Twitter background.

Why create a Twitter background?

A Twitter background gives you an opportunity to express yourself or your brand more effectively than the 160 character limit available in the bio. It is likely that more people will be interested in finding out about you if you express your personality or brand through your background image, which is an additional piece of screen real estate that offers you an opportunity to tell visitors about who you are.

While the Twitter background does not provide the ability to add hyperlinks, it does give you the opportunity to add URL text to the image, so that people can find your website. So, while they won’t be able to click on a link in your background image and be transported to your web site, they will be able to see your URL and type it into their browser’s address bar. You are also able to express, through text, images or graphics, what you are about.

How to

Create your file in your favourite graphics software (I have used fireworks). You will be optimising the image for PNG, JPG or GIF format later. For now, you need to set the dimensions of the image: 1600px wide x 1200px tall, resolution 72 px/in. This size canvas will help to ensure that your background image does not tile and is big enough to cover most screen resolutions.

The most important areas should be marked out with guide lines. Drag guides to the following locations within your file:

  • vertical guideline at 2px from the left edge;
  • vertical guideline at 180px from the left edge;
  • horizontal guideline at 14px from the top edge;
  • horizontal guideline at 80px from the top edge;
  • horizontal guideline at 649px from the top edge;
  • vertical guideline at 950px from the left edge;
  • vertical guideline at 1100px from the left edge.

Add rectangles of different colours to these divisions to give you a basic wireframe that looks like this:

Twitter background wireframe

Basic Twitter background wireframe

This grid defines the areas available to you to modify in blue. The black area is the background of your image and can be a gradient or solid fill, an image, etc. The areas in white and grey are used by the Twitter API and anything you put in these areas will be masked by or conflict with Twitter. Note: if you use the blue area on the right hand side of the Twitter API, be aware that this can expand and contract depending on the screen resolution, zoom level, text size and other settings of your visitors’ browsers. It can be partially or totally masked by the Twitter API, or fall off the right hand edge of the browser window at small screen resolutions. For this reason, it should only be used for secondary content.

Get creative

You can use anything you wish as your background image or fill. This should tie in with your overall theme, your brand and with the Twitter API. Note, it may not be the best idea to use adult themed, explicit, violent or other content that could cause offense; remember, the idea is to encourage visitors to follow you or visit your web site!

Your content area on the left should be used for your important information, contact details (website address, blog address, etc) and logo.

The content area on the right should only be used for secondary, non-important information. You do not have to use this if you don’t want to and bear in mind the notes I made above about how this may be displaced.

Save and upload

When you have finished creating your masterpiece, optimise it as a gif, jpg or png graphic. Gif should be used for any image that uses block colours only, jpg should be used for detailed images and png can be used for either. Make sure it is no more than 800k in size, to meet Twitter’s requirements.

All you need to do now, is upload your finished background:

  • Log in to your Twitter account;
  • Go to Settings;
  • Click on the Design tab;
  • Click on the Change background image button;
  • Enter the location of the image you just exported and upload it;
  • Deselect the Tile background image checkbox, unless you want the image to tile;
  • Click on Save changes.

That is all there is to it. You may need to make some slight adjustments to the image and re-upload it. This is normal as the image varies at different resolutions and is affected by the floating Twitter API.

Let me know

Use the comments form for this post to leave your twitter URL. That way, other visitors can check out what you have done. Please let me know how you get on with this How-to guide, and leave any other tips and tricks that you think might be useful.

How to write a creative brief

BT Tower, London

Creative brief, building blocks of web development

This post is the second part of my 5 stages of project management series and covers the most important aspect of the first stage; writing a brief for a web design project.

Why is this important?

Web design projects are only ever successful if two things can be achieved at the same time:

  • You provide your client with a site that fulfills the brief and they are satisfied with it; and
  • You have correctly estimated the time it will take to complete the project and you have been adequately paid for the work you have done.

To achieve both of these, it is essential for you to have a clear understanding of what your client wants to achieve. One of the ways we do this at Redcentaur is to set out in a creative brief exactly what the client wants to get from their web site and the reasons for it. This helps us to identify the objectives of the site and to scope the work necessary.

Obviously, the completion of a creative brief is not the be-all-and-end-all of understanding your client and the goals of the web site. It is the starting point, from which there needs to be conversation and discussion to drill down into the responses to the brief.

The brief

There are two parts to a creative brief that are designed to give the web developer a clear understanding of the client, their needs, desires, strengths and weaknesses. Paying heed and due attention to the brief can pay dividends for both client and designer in reducing the risk of missing the mark at a later stage.

The creative brief

The key part of the brief is to understand the creative requirements of the client. This can be broken down into four sections. Remember, your client might not have a clear grasp of these expectations themselves. This section of the brief should help them to start pinning down some of these concepts if they haven’t already.


This section should give a general overview of the client and the project as they envisage it. It should state the purpose of the project from their perspective and identify any specific goals they have in mind.

Audience profile

Your client probably has a general idea of who the target audience is for their web site and this section provides you with an opportunity to identify the target market from the outset. By asking your client what they think the target audience is, what they care about and why they would visit the site, you are able to develop an in-depth understanding of your client’s aspirations and the factors that will measure the success of your web design.


In our experience, this is one of the most difficult factors to obtain from a client. Often clients do not have a clear idea of their message or how that message should be conveyed. This section is about what it is your client wants to say to their target audience and why it is important for that audience to see this message. This section may help the client to start defining this message.

Competitive position

In an age when the internet has brought huge amounts of information to every audience, competitive edge is king. You need to be clear on the things that set your client apart from the rest and what factors make your client a success where others in their field are not. This will help you to identify the key strengths of your client that will need to be the focus of the design.

The technical brief

The client may have an idea of the technical aspects of the site that need to be delivered. These can be as fundamental as site logos and photography, copy, contact forms, etc. or more technical issues, such as database integration. The technical brief should be tailored to the services that you are able to provide. This is a secondary part to the brief as much of the technical specification will be a result of the design as it develops, but it is important here to understand if the client has decided the site will form the backbone of its customer relationship management, for example.

Roles and responsibilities

Once you have some answers to these questions, you can start to flesh out what are the roles and responsibilities within the project — who will provide the site images, who will provide the copy…?

It is important to have an understanding of this so that you can accurately estimate the time required to complete the design — if you suddenly find that the client does not have suitable photography, you will have to spend time either getting the photographs or sourcing them; a cost that you may not have factored into your quote.

Next steps

Once you are clear on the scope of the web site and have a clear brief, you can move on to the Design Phase.


Please leave a comment below to let us know how useful this is to you. Are there other aspects that you feel have not been tackled in our brief? Is this something you don’t find useful? How do you understand your client’s expectations?

How to use custom fonts with cufon

Using font replacement on the web

Using font replacement on the web

Are you bored of using the same old ‘web-safe’ fonts on your sites? Developers have been looking for ways to solve the old problem of having just a few fonts available across platforms for some time. The most recent methods of font replacement, such as SWIFr, used flash technology to transform text into a replacement font and to display it on screen as an image. Now, there are a variety of such font replacement methods available, including Cufón to display text in any font you choose; it’s fast, reliable and simple to use.

Cufón uses JavaScript to draw text as you go with the HTML 5 <canvas> element. Despite being an HTML 5 element, support for the tag is widespread and is even available in Internet Explorer 6.

There are two key things to be aware of:

  • Text drawn using Cufón cannot be selected in the browser – it is a vector image transformed by JSON;
  • You must have a license to publish the font on the web and embed it in your site.


Simo Kinnunen from Finland developed Cufón as a web font replacement solution. What Cufón does is transform the font into a scalable vector graphic, convert it into Vector Markup Language (VML), convert the VML into JavaScript Object Notation (JSON) and then embed the JSON into the web page using JavaScript functions and an HTML tag.

The downside is that the text is rendered as a drawing. It may sound complicated but really, it is fairly easy to implement and it is fast and efficient.

Pros and cons

There are pros and cons with all the various methods of font replacement available. Let’s take a brief look at the main ones:


This renders the text as a flash image. There is usually a slight lag between the rendering of the page and the implementation of the font replacement. This can cause a flicker of the original text before it is transformed within SWIFr. The use of SWIFr does not allow the formatting of the text within the page and it relies on technologies that are not core to the browser.


This renders the text as a vector image, using JSON. Like SWIFr, there can be a lag between rendering the page and the implementation of the font replacement that can cause flickering between the original and the rendered font. Again, Cufón uses technology (in this case, JavaScript) to render the effect, which may be turned off by the user in the browser. Cufón is more controllable within the page than SWIFr and is slightly more reliable. It does not require the installation of several different font formats, but it does require a licence to be held for any fonts that are used and published on a web site.


@font-face has been around for a while but it is really starting to come into its own with the advent of HTML 5 and updated browsers that can handle it properly. @font-face is a CSS property, which means that it is fully integrated with the browser and does not rely on any technology to be turned on. It is therefore much faster to render within the browser than the other two solutions. However, it does require various formats of the font to be available, either on the web site or from a font repository, and these have to be downloaded with the page for the font to be utilised on the page. This is a method that is really starting to make headway and is likely to take over from the other font replacement methods that are available in the future. We’ll be looking at this method further in future posts.

Useable fonts

Almost any font can be used with Cufón, whether you have TrueType Fonts (TTF), OpenType Fonts(OTF), Pointer Font Binaries (PFB) or PostScript Fonts (PSF), they can all be used. The only restriction is the licence you hold for that font. Commercial fonts often require you to have a second, more expensive licence to allow you to embed the font into a web site. You must check your licence to ensure that you abide by the licence agreement and not infringe the rights of the font developer.

How do you use Cufón?

    1. Go to cufon.shoqolate.com and download the cufon-yui.js file to your site folder. This is the JavaScript rendering engine that will create the redrawn font.
    2. Set up your web site using normal HTML and CSS and find a font that you can use in accordance with your licence.
    3. Next, go to cufon.shoqolate.com/generate,
    4. Select the relevant font(s) (NOTE: it is advisable to make a copy of the font in a separate folder before undertaking this process to avoid any mishaps to your existing font files),
    5. Choose a name for the font family,
    6. Click to agree that the EULA (end-user licence agreement) allows you to embed the font in your web site
    7. Select all the character sets (glyphs) that you want to use (the fewer selected the smaller the file size)
    8. rovide the domain names for the domains where the font will be used (this stops linking from elsewhere and other security issues),
    9. Select the EM size, optimisation paths and kerning tables for your font — this is a trade off between features and file size, so you need to choose what you are willing to sacrifice for file size here. Bear in mind that for small font sizes it is recommended to turn off path optimisation.
    10. Click on the ‘Let’s Do This’ button and download the file to your web site directory (put it with the cufon-yui.js file).
    11. Now you need to move to your web pages and open them in a text editor. In the HTML page, you need to place Cufón after any calls to stylesheets. You need to call teh rendering engine first, followed by the font file. The scripts are as follows:
      <script type="text/javascript" src="[directory]/cufon-yui.js"></script>
      <script type="text/javascript" src="[directory]/[font-family].font.js"></script>

Now, let’s replace some text elements in the HTML page:

  1. Add the following code below the two script codes you just inserted:
 <script type="text/javascript">

Add some effects

You have now changed the H1, H2 and H3 tags to your chosen font. But the script also allows you to render other effects on your text, such as a

Drop shadow:

Cufon.replace('h1', {textShadow: '1px 1px rgba( 0, 0, 0, 0.2)'});


Cufon.replace('h2', {color: '-linear-gradient(white,#990000)'});
Cufon.replace('h3', {color: '-linear-gradient(#fff, 0.4=#999, 0.5=#ccc, #ccc)'});
// shades into different colours at the specified points - 40%, 50%, to the end of the H3.

Final words

There is no reason why you can’t use this method on any text element in your HTML page. You can also extend Cufón by using a selector engine, such as Google’s.

As with SWIFr and other replacement engines, there is a delay between the page loading and the rendering taking place. To prevent this, simply call cufon.now() before any scripts running prior to the closing </body> tag.

Find out more at: wiki.github.com/sorccu/cufon.