Smashing Magazine - we smash you with the information that will make your life easier. really.

thanks so much that

This is an excellent list. If every site did these things first, the Internet would be a much happier place.

One comment: Progressive enhancement might be a better approach than graceful degradation. The two are really the same thing (making pages look good in trimmed-down browsers), but take different approaches. Graceful degradation designs an insanely awesome site for the latest browsers, then hacks the stylesheets to not look awful on older browsers. Progressive enhancement designs a tasteful site for basic browsers, then hacks the stylesheets to look insanely awesome in the latest browsers. This way, backward compatibility is a step along the way rather than an afterthought.

Thank you, this is very useful.

Shouldn’t the iPhone apple-touch-image be a png file? I’ve never seen an ico file working on an iPhone before.

SmashingMag, you never cease to amaze! Thanks for the awesome post!

Nice article, maybe you could have included something about Robots.txt

Nice with a usable post instead of all those “inspiration” posts :) Nice work SM!

How can this awesome site not give users the ability to share these blog posts on facebook or send by email? Seems kind of ironic given the natures the posts, no?

I love articles like this.

SM you’ve been on fire lately !!

Other items on my list include:

- Checking the layout on small screens
- Testing Microformats if used
- Minifying CSS/js
- Testing accessibility with Total Validator, aDesigner, WebAIM etc.
- Checking colour contrast
- Checking for unused selectors with Dust Me Selectors (FF extension)
- Checking robots.txt
- As well as Google Analytics, also signing up for Google Webmaster tools, Yahoo Site Explorer, and Live Webmaster Center

The only thing I disagree with is the Javascript item. In this day and age, Javascript is absolutely essential, as are cookies. Don’t believe me? Fine. Go ahead and turn either of those off, and start surfing and using many sites you normally go to. You’ll be dead in the water.

Now, Javascript often breaks, so that’s why we have jQuery — it gives us pretty much cross-browser functionality no matter what browser someone is using. And about 50% of the sites out there use cookies instead of session variables because they realized that session vars are either configured to use enormous amounts of server RAM, especially when you get slashdotted, or are slow because they are configured to go to the database. For me, encrypted, compressed cookies let you scale affordably unless you have invested a lot of cash in your backend — a suitable thing when you’re just starting your website out with one to three servers in the first couple years.

I love you Smashing, I really do. Thank you for being so awesome…

Great. I wish I had advice like this years and years ago when I was first starting web design. :D

nice post.. very useful for me as m going to live my site soon.. thnx for sharing …

These things may come under proof read, but still good to mention:
* check for junk data and meta data, inserted by the CMS/application/developer/designer
* double check that contact info is correct and forms reach the correct mail id.

For optimizing YSlow (http://developer.yahoo.com/yslow/) and http://www.smushit.com are worth mentioning.

And John Faulds’ comments are notable.

Thanks… great post!

Cross browser checks and title tags are hardly things one ‘checks’ at the end. how can you develop a site without checking IE constantly!?

Otherwise, good post. Checking IE is like our company mantra… for the many times we forget. …stupid IE.

Waouw ! Great Post ! Thank you… As a web content strategist, I appreciate, of course, you integrated content (Tip 4) in your check-list ;-)

thanks for useful post,.. I missed some of really important steps before launch my website

.htaccess file with directory listing disabled for the inner folders. I guess this is most important from security point of view.

very useful, thanks!
just bookmarked! :)

12: checking your form for validation.
I used to have “helpful” diagnostics but the spammers used them to try to circumvent my anti-spam measures. I use javascript validation so those with JS enabled get on-the-fly error prompts and follow that with PHP validation. Spammers disable JS but 99.9% of “real” users” don’t so they get the helpful prompts. The PHP validation gives a less helpful error response that says something like “the message appears to have some characteristics in common with junk mail, please review your input and try again”.
I also put a “JS disabled” alert on form pages because I agree with Volomike and others – Web without JS is like a kiss without a moustache (to paraphrase J P Sartre?).

I would also advise to optimize -> minify scripts and css, gzip etc.
http://developer.yahoo.com/yslow/

For testing your site’s performance, you can use the free Page Test tool – this is a web based application: type in your site’s URL and a remote machine starts Internet Explorer, measures how long it takes to load the web page and presents results.
You can test from two locations to see load times from different parts of the world:
East Coast USA
New Zealand

Nice article, thank you.

I don’t know whether to start with the article or the proceeding comments.
I guess starting with the article makes more sense.

1. Many of the things mentioned here, while important tasks, are not the kind of things you should be doing pre-launch – they should be occuring much earlier in your development cycle than that. In some cases (how to handle no-script issues) should be handled all the way back in the wireframing stage. Defensive design and validation is certainly something you don’t want to be first thinking about towards the end of a project.

2. The article lacks a lot of advice on what you should have checked during this crucial time. Things like
i) Making sure you have a the required details needed to go live: does your client allow ftp to their server or only sftp? Do you have the details to login? Do you know how their file structure is configured?
ii) Does their server/scripting language/database have all the appropriate addons/configurations you might have used in development? For that matter are you developing and hosting on indentical environments? (You should be, and you should have a definitive answer to that question before you even start a project).
iii) Do you know when the client wants the go-live to happen? Have you cleared enough time from your schedule to do the job properly? (If in doubt or the project is remotely complex, schedule a full day).
iv) Have you backed up the live site and data? (This is mentioned in the article but you can never remind people to backup enough)
v) Are all your internal links appropriate? No linking a sneaky css file from the testing server? No including that debugging javascript file by accident? No hardcoded links to the development or client display server? No forgotten # in the footer that should link to a privacy policy?
vi) No lorem ipsum content anywhere? This includes making sure that previous placeholders like ads or blockquotes have been replaced with the correct content.
vii) SQL files created for making the appropriate databases and also for adding any required data? Do you know how those sql files are going to get run? Does the client have a user panel for doing this or do you have to ssh into their server and run it by command line or do you have to send it to a third party system admin to execute? (If it’s an external System Admin, have you scheduled enough time to get the job done? Have you? Really? I don’t think you’ve dealt with enough Sys Admins, triple that timeframe).
viii) Is your data clean? No test data lurking in the database that might result in ‘test user’, ‘testuser1′ being seen on the live site?
ix) Did you re-clean the database after running the tests you should have run when the site is live for testing that signup form?

3. Graceful degradation is dead, killed by progressive enhancement. Please don’t publish articles promoting the use of a dead methodology.

As for the comments.
1. Yes, you design and build with the possibility of javascript being turned off in mind. No, shut up, don’t argue, don’t even open your mouth. The fact you’re even opening your mouth to say something tells me you’re utterly clueless and you shouldn’t be entering the conversation. Be quiet and let the adults talk.
You design and build with no-script in mind because that’s the whole point of progressive enhancement. Make sure that everyone can make use of or at the very least comprehend the service you are offering. If you’re using the canvas tag, you provide a fall back notification for browsers that don’t support it. Every other javascript interaction should be detailed/wireframed/documented in terms of progressive enhancement. This is a bigger issue than you thinking ‘Oh man, this is just bullshit.’ This is an accessibility issue and if you don’t understand it you should just shutup, walk quietly away and go and study until you’re capable of holding a conversation about it.

Ok, apparently this got a bit long. I’ll stop now.

Nice article! I agree with most of the stuff, but I think numbering the points was a mistake. Made me first believe that favicons was the most important thing on the site.

One thing I noticed was that the first images points has a faulty link to http://www.smashingmagazine.com/2009/03/05/10-things-to-consider-when-choosing-the-perfect-cms/

I wonder why my reply is awaiting administration approval all day…

All this talk about functions disabled in the browser. How about checks for human users with disabilities? Color blind testing, vision impaired users?

Great article! Will be sure to refer back to this when I finish the redesign of my site.

spectecular. thanks!

Very informative! Thank you!! :-)

Does anyone know why some feeds have a favicon and some don’t? Smashing Magazine’s feed for instance has a favicon so all the visited pages have a favicon and the new ones don’t which makes it really easy to find updates. Other feeds on the other hand only have the default icon. I’m using Firefox’s built-in feed service.

I agree – graceful degradation is dead. I use the mighty noscript addon myself but when something doesn’t work – I turn it on. 95% are using JS by default, the 5% that doesn’t are most likely doing that in a similar aware fashion. Still.. Basic stuff like registration and navigation should be working anyway but not because of the end-user, but because of the site’s best interest, that’s correct. It’s the same rule we apply to the IE6-compatibility right now – “let them know it’s not worth using it”. And of course Steerpike is right: that’s an early development stage, not final. Same with optimization, etc. I agree with you t in most cases except using lorem-ipsum (not the idea behind it), which should rather be replaced with some real text likely to appear in particular areas (which – yeah – is a must-do).

Daemon: should we really care about the mobile phone users? NO – UNLESS they’re an important part of your target. In most cases they are not. In addition, soon all mobile phones will have webkit-based browsers or some IE and then what? You’ll be rewriting your sites, adding tons of new stuff you suddenly realized could or should be there from the beginning? Creating mobile versions, if you really care, is way better. You make them download much lighter, faster, minimalistic version with the most important stuff while not limiting the whole projects because of your naive idealism. “Equal to everyone” – we’ve seen countries falling because of this idea. It’s impossible to make everyone comfortable and usually it’s not best to. There is no general rule like that – it’s about every project individual needs. Will you throw out all your graphics because I’m gonna watch your site in some text-based phone? You get the point. Everything progresses. If you watched the mobile phones market closely, you’d see soon it won’t really matter. 0,5ghz cpus are standard for PDAs now, next year it’s gonna be 1ghz. And as for normal phones – again, mobile versions are best the solution. And if you wanna use your phone for web most often, you’re more likely to have an iPhone, HTC, or whatever PDA already. If not, then you’re an idiot. You don’t buy acoustic guitar to play heavy metal.

Awesome list! I was doing pretty good, but some of these I was missing, they will be in place for my next launch. Thanks.

I agree with most things in this article. I wont mention the issue of javascript since plenty of others have posted about how silly it is to worry about the 1 or 2 people in the world who have javascript disabled.

The only other thing worth mentioning is regarding the browser compliance. As a general rule, I test in IE6, IE7, IE8 and Firefox. Sorry Safari and Opera but for a combined 5% of users, its just not worth it unless the client absolutely demands compliance in these browsers (but that should be a little extra for the time needed). IE8 is the exception. Currently, according to w3school.com browser stats, IE8 only commands around 1.4% but this is IE we are talking about and its use will dramatically increase as IE5 and IE6 get closer to the exit. In an ideal world, every website works in every browser, with or without javascript but the reality for many web designers and developers is that time is of the essence. Clients are more and more demanding for shorter turnarounds and we have to pick our battles.