UKD1 Limited We provide consultancy, PHP web development and support for web applications and ecommerce sites in the UK.

30Nov/09Off

Picking the best weekday for a website launch

Picking the best weekday for a website launch can be difficult. When considering it, there are a number of key things to take in to account:

Expected traffic / business volume

Launching on the busiest day of the month is not likely to be the best choice - a trail by fire can be risky especially for a major launch. Picking a quiet time of the month - check your sales & website analytics - will mean less lost revenue & annoyed customers and stress if things do go wrong.

Developer availability

Launching at the end of the week might seem like a nice way of finishing the week off - but teething problems might mean work over the weekend. This isn't good for keeping your developers happy!

Launching early in the week (unless of course this is your busiest period) is going to mean more normal working time to work on any (hopefully minor) issues you come across. Should there be a disaster, the whole team will be around anyway.

Support availability

Although your hosting provider probably does operate over a weekend, they are likely to have more staff around during normal working hours.

Phoning them before hand will be a good idea to make sure:

  • There are no scheduled maintenance windows of their network, your server or any of their peers.
  • If they manage backups that there is a current one (can't hurt to ask if you can't check yourself for some reason).
  • They have staff around at the time you are expecting to launch and that they are aware this is happening - this is especially important if they monitor your servers (they may think something has failed).

Post to Twitter Post to Delicious Post to Facebook

Tagged as: , No Comments
4Nov/09Off

Recommended Book : High Performance Web Sites


High Performance Web Sites is another book which we've found highly useful here at UKD1.

The book includes good advice from the guys who wrote YSlow for Firebug in the form of fourteen rules.

It's aim is to advise a front end developer how to improve the performance of your site - which in-turn will improve your visitors experience. A faster loading site means happier users.

Most of the rules are pretty simple to implement as well as being well cheap / free cost wise. Highly recommended.

Get it now at Amazon.co.uk.

Post to Twitter Post to Delicious Post to Facebook

3Nov/09Off

Checklist : 7 critical pre-website launch things to check

This is a pre-launch checklist - things a developer probably needs to get ready before the big day (ideally long before).

It's critical to prepare for the launch before the last minute day. So, the list:

1. The domain

You need to have either bought the domain or if its already registered have access to the DNS settings so you can alter them. If you the domain already exists and you don't control it's DNS, you'll want to ask you client for the access details - or ask their I.T. department to prepare to change.

Why its critical : its the lynch-pin for the whole affair, no access means you can't set your site live come launch day.

Also, find out the DNS's TTL, some free DNS providers have these set long - meaning the time for a complete change over globally is longer. If you want to get around this you can change the name servers - mirror the current DNS settings - to a better DNS provider.

2. The server

Have the details of the hosting been given to you? Have you checked that any modules / services / software that is required is installed? Does Apache / Lighttpd have the correct modules?

Why its critical : It may work on your development server, but if  you've not installed that important module on the live server, its not going to work.

3. The SSL

If your project is for an e-commerce website or something else that requires security its likely you'll need an SSL certificate. Does your client have one already? You may be able to reuse it. Installing it on your development server (& using your hosts file to check it works correctly) will let you test for any oddities with your software - cookies / sessions / etc.

Why its critical : Some SSL certificates can take a while to actually get provisioned - the certificate authority may want you to jump through quite a few hoops before issuing it. Best to get this one out of the way early.

4. Migration script

If your upgrading a site which already exists you'll likely have user data. You'll (probably) therefore need to write a migration script from the old schema to the new one. Testing your script against last nights live database backup is good practice - I usually automate this and run it several times a day whilst testing. It helps iron out any bugs.

Why its critical : Loosing users data is highly likely to annoy them, loosing you custom. Also, if you botch a migration an set the site live you may end up having to either unstitch or loose data to switch back to the old version.

5. Test launch

If possible - test launch. If your hosting on a brand new server run through the launch, set up the server, run your migration, use your hosts file to point the domain at the server and check it.

Why its critical : if you can do this step, your much less likely to encounter problems on the day - as you'd have found most things wrong before hand.

6. The schedule

When is the site going live? In the evening? I normally prefer to do launches early in the morning as I'm awake and will be if there are teething problems during the whole day. However, make sure that you check when your peak traffic is during the week / day as well.

Clients often seem to want to launch at the end of a week - this in my opinion is not a good idea as most people don't work weekends.

Why its critical : Having a smooth launch which affects as few people as possible is always nicer to your visitors (aka customers?) which they'll love you for.

7. The disaster plan

Whilst its never something we want to happen, sometimes it does. Best to plan for it then!

  • Is it possible to cut back to the old site - if so, how?
  • Take backups before you attempt to go live - they'll be useful if it all goes wrong
  • What counts as a disaster - when should we roll back? (i.e. if just SSL didn't work, can we live with it whilst we fix it?)

Why its critical : Unexpected things happen. Planning for them helps, you'll only have to do it on your feet otherwise.

Hopefully you'll find this list useful - I'll be making a few more lists as time goes on - I'd love to get some feedback from your own experiences.

Post to Twitter Post to Delicious Post to Facebook