I wanted to put this list together as a checklist of things to remember when creating a new site, and more specifically when creating and developing our new site at 18aproductions.co.uk (coming soon...).

This is all written in very much a 'note' form as there's just so much to cover. If you have any thoughts, feedback or can think of something else I should include, please leave me a reply in the comments.

Topics to consider include: (I'll link these up when I get chance...)

Front end
- Grid layouts
  - Choosing a suitable grid layout (12, 24 columns)
- CSS Frameworks / Preprocessors
  - LESS, SASS (SCSS), Compass
- Responsive layouts and considerations
  - Which breakpoints to target, tablets and smartphones, and device orientation
- Javascript libraries and considerations
  - jQuery, jQuery UI
- HTML5
  - Progressive enhancement, HTML5Shiv, Modernizr and backwards compatability
- Print stylesheets
Backend
- Programming Language
  - PHP, Ruby, Perl, other
- Framework / Platform
  - CodeIgniter, Wordpress, Drupal, Joomla, other
- Database
  - MySQL, nosql, other
Optimising for Speed
- CDN
  - Amazon AWS
- Caching
  - Memcache
- Other Considerations (Minify, compress, combine, sprites, AJAX)
  - Expires headers on static components
  - Load Javascript at end of body tag
  - Asynchronous loading
  - Minise CSS/JS - PHP Minify
  - Reducing HTTP requests for objects and combining requests
  - Sprites
Marketing
- Social media integration
  - Facebook
  - Twitter
  - LinkedIn
  - Google Plus
  - Google Places
  - Geo-targetting
- Use of Meta and other tags
  - Description and keywords
  - Open Graph Protocol
  - Twitter
  - Viewport
  - X-UA-Compatible
  - format-detection
  - Alternative Feed URL
  - Apple icons in various sizes
  - Favicons
- Google Rich Snippets (microdata, microformats, RDFs, and Data Highlighter)
- SEO
  - Keyword targeted landing pages and content
  - Good use of title tags
  - Good semantic use of HTML tags, H1, H2, H3 etc.
  - Robots.txt
  - Canonical URLs
  - Social Signals
  - Fresh content
Legacy Site Support
- Mapping pages with 301 redirects
Managing and Maintaining
- Repositories, versioning and collaboration
  - Git
- Organisation of the filesystem
  - Where to store assets
- Google Analytics and Web Master Tools
  - Bing tools and Google tools
Other Housekeeping
- Error handling
  - 404 page
  - Logging and error messaging
  - Cookie, Privacy and Terms Policy

Front end

CSS Frameworks / Preprocessors LESS, SASS (SCSS), Compass

I have to admit, I'm fairly new to the area of CSS pre-processors (but then it is a fairly new area in the grand scheme of things). And I remained quite skeptical until recently. When you know how to do something already and you've got a full workload, learning something new, especially when it involves the number of hurdles this can, can fall pretty low down your list of priorities.

It wasn't until I saw the time saving possibilities that I came to realise how useful things like LESS, SASS and Compass (Compass uses SASS) can be. Also the things they make possible with regards to CSS3 and sprites alone make them worth the trouble of learning.

I've opted to pitch up in the SASS camp, partly due to personal recommendation and partly due to the fact I found it ever so slightly easier to get my head around how it all works. In a nutshell, there are several prerequisites which I needed to install before I could work with Compass and SASS. I work on windows based PC:

You need to work locally (WAMP or some other local web server)
Everyone involved in the project has to agree to use SASS as well otherwise changes will get overwritten.
You need to have Ruby installed. This comes as standard on a Mac I believe, but Windows users like me have to download something like Ruby installer.
You can then install SASS
You can then install Compass

So it's little wonder that quite a few developers are yet to embark on this setup fest. But it is worth it though.

Once you have SASS and Compass setup on your local dev machine, you just tell it to 'watch' a certain file or folder and when you make a change to your .scss file it will generate your .css file for you, according to the rules your specify in your config.rb settings file.

Yeah, it's confusing, but not insurmountable to understand, and after a few tutorials and youtube videos you'll soon get the hang of it.

Responsive layouts and considerations

The big buzzword in 2013 is 'responsive'. With reports suggesting that more and more people visit the web on their mobile and suggestions that tablets have overtaken smartphones it's little wonder that people want to make their websites look good on screens of different sizes, and thanks to media queries they can. All you need to do is write sets of rules to transform your HTML differently depending on the size of the device viewing them.

You need to consider breakpoints to target for different tablets and smartphones, and device orientation. You might consider 320px (iphone portrait), 480px (iphone landscape), 768px (ipad).

Of course, whilst there's lots of talk about things getting smaller - they're also effectively getting bigger with retina displays and high density screens. So then lots of consideration has to be given to images and how to present them for best effect so that they still load quickly on small devices using 3G but can look sharp for retina displays. This is a huge subject of debate at the moment because what solves some issues can cause others so it's something that needs to be considered on a case by case basis.

Grid layouts

Choosing a suitable grid layout.

Grid layouts help you organise a site's content neatly into rows and allow you to use re-usable design elements throughout your site. Examples of grid layouts include Twitter Bootstrap (which also includes a lot of other useful elements for your site such as jQuery scripts), 960.gs, unsemantic.com and semantic.gs. The last 2 are both responsive and make use of SASS and Compass to help generate columns based on percentages rather than fixed pixels. In fact semantic.gs says it runs on LESS, SASS and Stylus. Whilst I appreciate the theory of a grid layout, and I think their concepts should certainly be applied in the design state to help achieve a balanced design, I think their application in CSS should be taken with a pinch of salt.

Javascript libraries and considerations

jQuery, jQuery UI

In the beginning there was Javascript. Then, thanks to a dedicated bunch of programmers, driven by browser peculiarities, Javascript frameworks were born.

I'm a big fan of jQuery. I know there are other options out these such as mootools, prototype and others, but personally I've always found jQuery just floated my boat the most. And I'm not alone thankfully, so I find a plethora of plugins, widgets, help and advice out there for just about everything you might want to do.

Once you have your head around the potential and possibilities of jQuery, along comes something really cool. jQuery UI is a collection of commonly needed interface elements which you can pickup and use in your projects. It's like a packaged up version of some useful jQuery code. Using libraries like these not only means it's so much quicker to develop your site and produce some really impressive interfaces, but it also means that other developers can pickup where you left off and contribute, maintain and support your code. One of the most important things to consider when building a website is what the next coder will make of it. Using commonly recognised, industry standard libraries really makes things a whole lot easier for everyone to understand.

HTML5

Progressive enhancement, HTML5Shiv, Modernizr and backwards compatibility

I've been putting off making full use of HTML5 for a long while now. Not because I didn't want to, but because (much to my amazement!), there are still some IE6 dinosaurs lurking around the net. How they continue to survive is a little beyond me and up until quite recently IE6 support was still an on-going concern. But IE6 isn't the only problem, IE7 is far from perfect and IE8 has it's issues (I expect you're noticing a trend here i.e. IE).

There are ways of making older browsers understand newer HTML5 tags though, and that's where Javascript libraries such as HTML5Shiv come in.

Print stylesheets

I find it useful to hide header and navigational elements from print stylesheets. Generally if people print a page they want it to print the page content, not your site navigation. Another common issue I've found is making things the right width to print sensibly and avoid wasted paper.

Backend

Programming Language

PHP, Ruby, Perl, other

I started out as a Perl coder, then with the advent of PHP I found myself moving to PHP for a growing number of projects. For the past 7 or so years now PHP has been my server-side language of choice. Ruby has been growing in popularity as a web language over the years, but I haven't yet had a strong enough reason to adopt it for use in a project. That day may come, but for now I find PHP still has plenty of life left in it, especially when used in conjunction with a framework such as CodeIgntier, which provides a great platform upon which to build a scalable, MVC based web application.

Framework / Platform

CodeIgniter, Wordpress, Drupal, Joomla, other

As mentioned above, I'm a great advocate of CodeIgniter and have used it for dozens of web projects over the past few years. I believe it provides the right blend of functionality and flexibility and doesn't constrain the developer. It makes jobs easier, not harder, as I've found other frameworks or CMSs can.

For simple CMS based sites, Wordpress is our goto option, as it is for a large number of web developers out there. It's not suitable for more bespoke developments, in these situations I would generally opt for CodeIgniter, but for simple sites that are on a budget, Wordpress is a great starting point. Its tightly cohesive and loosely coupled nature, via the use of themes and plugins, means you can extend and customise to your hearts content without worrying about causing yourself too many headaches when it comes time to upgrade (which happens a lot with Wordpress; their development team certainly keep themselves, and consequently everyone else, busy).

There are various other 'off the shelf' solutions which you might consider, depending on your requirements, such as OpenCart for a shop and vbulletin for a forum.

But personally CodeIgniter projects are always the most fun and personally rewarding.

Database

MySQL, nosql

If you're going to have any kind of CMS then a database is more than likely. Most dynamic websites use a database and most use MySQL. It pretty much comes as standard with most hosting packages and is widely used, understood and supported by the web developer community.

Nosql (Not Only SQL) is a movement born out of the web 2.0 rise in 2009 and is gaining widespread traction. Nosql-database is a great resource which lists many of the databases out there and their respective merits. The general idea behind nosql is the storing of huge amounts of data with higher availability and scalability than traditional relational databases. The Wiki page on the subject also provides interesting reading.

Hosting

Once you've built your website, you need somewhere to run it from. Hosting varies hugely in platform and spec, and in price and quality. If you pay 99p/year from SpeedyHostsRUs, you can't expect to get a great customer service experience or many features.

All the websites we build are on a LAMP stack and hosted on Linux servers, based in various locations around the world and backed up offsite every night. If back ups are really important to you - and on constantly updating dynamic websites they probably are - then make sure you're backing up data on another server. If a hole opens up in the Earth's crust and swallows the one and only data centre you use, it'll take your site and it's back ups with it.

Cloud Hosting on AWS

If you're not afraid of getting your hands dirty and you want to give cloud hosting a go, then I'd highly recommend taking a look at Amazon Webservices (AWS). We recently attended their 2013 Summit in London. They were certainly out to impress, and after listening to various talks from their tech big cheeses and having had a play around with several of their offerings I have to say I was genuinely impressed!

Just like anything worth doing, it's not easy, but setting up an Apache webserver on an EC2 instance, connecting it to an RDS database and installing an SSL certificate on it, all went very smoothly and the site flies along. It's certinaly something to consider if you're expecting your website to get a lot of traffic and you want the capability to scale up your hosting at a moments notice. Or better still have the system auto-scale to deal with traffic - it's really clever stuff.

Optimising for Speed

CDN

Amazon AWS

If you're expecting a lot of traffic on your site from a variety of regions around the world, then using a CDN could really help speed up the delivery of your content to your visitors. Basically the idea is that you reduce the amount of trips around the world that need to be made in order to deliver all the content required for a page to load for a user. For example when a user in Mexico requests a page from a web server based in London, rather than having to download each image from the origin web server, the CDN will deliver the content geographically nearest to the visitor, which in the case of Amazon Cloudfront, is a lot closer to Mexico than London. Thus the page loads faster for the user.

I've found CloudFront to be surprisingly easy to setup. All you need to do is sign up with Amazon AWS, then create a distribution.

If I was creating a CDN repository for 18a.co for example, I could create a new distribution with 18a.co being the origin. Give Cloudfront a few minutes to configure itself (it'll tell you when it's ready). You can then view a complete mirror of your website via your unique cloudfront URL, which might look something like: http://d3uy7bfospl44.cloudfront.net.

So an image which is available at:
http://18a.co/img/logo.png

Would now also be available at:
http://d3uy7bfospl44.cloudfront.net/img/logo.png

These aren't real examples so don't bother clicking them, but you get the idea.

You can now update the code of your website to grab static content from your Cloudfront URL. It's as easy as that.

Duplicate Content issues with Cloudfront

I've written another article about this subject, so please take a read if you fancy a change of tack.

Caching

Memcache, static page generation

Caching pages can help with page load speeds. If your page is very dynamic and calls to a database a lot of times, caching it basically presents a snapshot of how the page looked at the time it was last cached. So you might update the cache every 15 minutes or so. This shouldn't be confused with a browser's own cache (when you have to press Ctrl and R to see the latest version of a web page).

Other Considerations (Minify, compress, combine, sprites, AJAX)

Expires headers on static components

I often get accused of a typo here, but I believe "expires headers" is the right expression. It tells browsers how long these static components are valid for until a new version should be requested.

Load Javascript at end of body tag

This just means that other page elements aren't delayed from loading while scripts are being loaded. Languages like jQuery use document.ready directives to ensure no code starts to run until everything is loaded in any case, so adding jQuery code at the end of the body just gives the user the impression that the page has loaded faster as things are visible quicker.

Asynchronous loading

Rather than holding up the page while loading Javascript it can be loaded alongside other elements, quietly behind the scenes, again speeding up delivery of the page to the user.

Minise CSS/JS - PHP Minify

Minimising CSS and JS just reduces the amount of bandwidth necessary to download the content. It also has the added advantage obfuscating your code (making it harder to read and 'borrow') for nosey people. I like to do this at run-time using PHP Minify as it means I can keep the source files themselves nicely laid out. PHP Minify also allows you to combine requests for separate elements into one, reducing the amount of HTTP requests it takes to load the page. Which brings me onto my next point. [Edit - since using the SASS CSS pre-processor I've actually given up using PHP Minify and instead minify my code at the point of generation with Compass.]

Reducing HTTP requests for objects and combining requests

There are a number of ways you can do this, using something like PHP Minify as discussed above is a great way of combining stylesheet and Javascript elements together. Another way is to use CSS background Sprites.

Sprites

Sprites are images which combine lots of individual images into one larger 'sheet' of images. You then use CSS background-position to identify which part of the sheet of image to show for your specific requirement. The advantage of CSS background sprites are that they reduce the number of HTTP requests required to generate a web page, generally taking up less bandwidth. They also mean things like rollovers don't have that slight delay while the image is loading. Everything is downloaded at once and immediately available in the browser. Sprites can be very time consuming to create, but also very quick when using a CSS pre-processor such as SASS and Compass.

Marketing

Social media integration

Facebook
Twitter
LinkedIn
Google Plus
Google Places
Geo-targeting

Where do I start? This, I feel, is a conversation/blog post for another day. But needless to say, if you're making a website in 2013 you want to consider it's social interactions.

Use of Meta and other tags

Description and keywords

The description and keywords meta tags are about as old as they come. They've been around since very early implementations of HTML. The keyword tag is now generally ignored by robots (and Google states that their Googlebot never paid attention to it at all), due to it's misuse back in the early days of search engines and SEO. However for completeness I feel it doesn't hurt to include it with a few basic keywords about the page being viewed. The description tag however is important, as this is the text which Google and other search engines often use to generate the little snippet of information they use in their SERPs for your site. So make sure it's catchy and relevant to the page it's describing.

Google Rich Snippets (microdata, microformats, RDFs, and Data Highlighter)

We wrote a blog post last year about the semantic web, which gives a background into the point of all this. Data Highlighter is now Google's non-techy helping hand for all this.

SEO

Create keyword targeted landing pages and content relevant to your users needs - i.e. write stuff people are searching for in Google.

Good use of title tags

This is essential. Alongside the META description tag, the title tag for each page is one of the major factors used by the search engines in order to decide how relevant your page is to the users search. The title should accurately describe the page being viewed, be unique and keyword focussed, with the most important words being at the start of the phrase. Normally no more than 5 words or so. The general rule of thumb I use when considering SEO is if it looks spammy to a human, then it'll also look spammy to Google, so don't push it.

Good semantic use of HTML tags, H1, H2, H3 etc.

As well as keeping those W3C Internet purists out there happy, good, semantically relevant use of heading tags can also benefit SEO. So make sure your pages make good use of relevant heading and other tags. [According to Lisa, who does our SEO training, there is apparently no empirical evidence that heading tags help with SEO, but sites that use them seem to do well in the SEO stakes in general... so the jury's still out as to whether that's coincidence, because the site is good in general, or because it actually helps. So put them in to be on the safe side!]

URLs

Websites need to be easy for search engines to crawl. A few years ago this was more of an issue than it is today. These days most sites are built with search engines and search engine friendly URLs in mind. Dynamic pages (i.e. those generated using a server-side technology such as PHP) can look like this:

18a.co/search.php?keyword=jquery

A better (more search engine friendly) format is this:

18a.co/search/jquery

To make this possible rules are written which translate requests for certain URLs and route them to the required backend scripts. How this is done varies depending on the web server being used, but for a regular Apache webserver, they can be defined in a .htaccess file.

Other SEO considerations

SEO is a huge topic so I'm not going to attempt to make this a definitive list, however there are just a few (generally obvious these days) things to remember:

Use alt and title tags on all images
Use title tags generally on other elements which would benefit from them, such as links
Make sure you don't put the same content in multiple places. If you do have duplicate content, try and use canonical tags to point Google to the version you consider to be the origin.

Robots.txt

The robots.txt file contains a list of directives for all well behaving robots visiting your site. There's nothing to stop a badly behaving robot doing whatever it likes and ignoring your requests, but the robots.txt file at least makes it clear what you'd like them to do. Obviously the big crawlers do pay attention to this file and it provides a fairly rudimentary way of controlling what they index.

One trick I've found useful is to serve up a different robots.txt file depending on the protocol being used. This is useful if you serve the same content over http and https and means you can avoid duplicate content by just banning all access to robots when they view your site over https.

Avoiding duplicate content

Forwarding all requests to www or non-www version of site

Avoiding duplicate content is a pretty good idea. What many non-webby people don't realise is that websites can generally be loaded with or without the www at the start. Some websites opt to run primarily with the www, others without. Whichever you choose (and it doesn't matter), make sure you redirect all traffic (via a 301 redirect) to the location of your choice.

For example if someone visits www.18a.co/services redirect them to 18a.co/services.

This can be achieved (on Apache) using a nifty little .htaccess statement:

RewriteCond %{HTTP_HOST} ^www\.18a\.co[NC] RewriteRule (.*) http://18a.co/$1 [R=301,L]

Canonical URLs

Canonical URLs aren't essential, but can be useful in helping the search engines determine which page should be considered the source of the information being published. It's just another hint to help them clear up their indexes of duplicate content.

Social Signals

More to follow on this subject... but in a nut shell it's about search engines trying to decide how they're going to interpret your interactions with social media sites.

Managing and Maintaining

Repositories, versioning and collaboration

It takes a little time to get your head around, especially if you're more familiar with a SVN approach, but recently I've been using Git to help keep track of projects and when setup correctly, I've found it very useful!

Organisation of the filesystem

Where to store assets is a constant source of dilemma for me as I seek to find the optimum choice. Lately I've chosen to store everything in a folder called /a and then the various different assets types in subfolders under that.

Google Analytics and Web Master Tools

These can be very useful and are worth a look. (I believe Bing also has an offering but I haven't checked it out yet.) I find these type of services are great if you know what you're looking at, but they can also be a developer's nightmare if intepretted incorrectly by a client! Nothing like a bit of 404 scaremongering...

Other Housekeeping and notes

Legacy site support by mapping existing pages to new locations using 301 redirects.
Consider website error handling.
Build suitable 404 and other error pages.
Perhaps log errors behind the scenes so you can debug any issues after the event.
Cookie, Privacy and Terms Policy - you've got to remember the EU cookie guidelines.

If you've got this far... Well done, I hope you didn't get as bored reading this as I got writing it by the end! :) Any thoughts, opinions, additions or feedback please leave in the comments. Thanks!

A Comprehensive(ish) List of Things to Consider when Building a Website in 2013