The keyword reach associated with building a website is limitless, but essentially – as ghastly as it might sound; building a website without planning, can – and most of the time will mean danger ahead and ultimately less success in the long run!

So without further ado, here is Cheb’s guide to building a successful website.

Planning/Scoping

The “Ahh, guys? What are we building again?” phase

So, you want to build a website? It’s not rocket science – but it is a science, and an art! Just like baking a cake you have several ingredients: A handful of designs, a dash of slicing, a teaspoon of code, a sprinkle of love, and ‘bob’s your uncle’ – or, ahh, not! What many people in the web industry however don’t realise is that the planning phase of a website is so crucial, that it really can dictate how well the build of the website is. Essentially, if done correctly, the planning phase – or more importantly, the scoping sub-set of the planning phase, should setup the site’s structure, navigation, as well as functional specifications for the web site build.

Scoping (also referred to as Information Architecture) should reveal not only the clients’ objectives for the project and what they would like the site to achieve – but more importantly, extrapolate all the detail, business rules, as well as technical adjustments which will be needed down the track in order to successfully design, build and launch the website.

Without mentioning any names, I’ve worked with around six web firms, in some way or another, in Australia alone – and the sad thing is, only 65% of them actually ‘recognised’ the importance of getting scoping/Information architecture right! Obviously Wiliam Web Design is in the 65 percent that got it right! Overall though, not really the statistics you’d like in the field of web design and development – right?

At the risk of helping the competition too much – to be counted up with the ‘best of the best’ you’d be expecting your Information Architects/Business Analysts/Usability Evangelists/whatever you want to call them – to be able to at least come up with the following pieces of documentation in this phase of the web build. As a side note, the documents listed below will be discussed in detail in an upcoming post so stay tuned!

1. Requirements gathering documentation
2. Requirements analysis documentation
3. Functional specification documentation
4. Prototype development

You read it here first ladies and gentlemen! From this day forward, let it be known that Cheb D coined the term “The GASP Method for scoping/information architecture” which will be used to outline the bare minimum in terms of documentation/deliverables; that the planning/scoping phase of a good website build whether in Sydney, Melbourne, New York, or London – should deliver. I will outline the massive importance that these documents play in the successful build of a website in an upcoming post – for now, let’s kick on to design.

Design

The “Wow! so all you needed was good documentation and you came up with THAT?!?” phase

Never thought this would be a part of this post, yeh? Okay, so nothing overly-crazy here. You can’t build a website without design. The situation is that everything that happens from this point forward will start to effect everything else throughout the project. Think of it as the literal view of ‘The Waterfall Model‘ for software development.

Further to that – everything that was done right in the previous phase will already have a dramatic affect on the project as a whole, because the difference between a good and bad design decision does not always start and end with the designer! Whether you are building a web design blog or an E-Commerce shop-front, I think that holds true.

Designers as a collective, love to think that they understand everything about usability simply because they know good design! Sure, they would be one of the few people involved in the web design process who could have a say in how and why things will work – but having a designer nutting out the usability of their website as well as designing it, without the assistance of:

a) an objective individual such as an Information architect, and
b) an objective individual such as an Information architect with previous experience in online user experience design (UXD)/User interface design (UID), or usability and accessibility analysis;

is comparable to getting a developer to bug-check his own code or bombing for peace!! Good luck with that!

The issue however is that we have come to realise that good design is not necessarily always good usability, and more importantly that good design practices is not the same as usability. Something as simple as having a login box pop-up as a div overlay upon click, as apposed to always being on the page and distracting the user from more important areas of the page, such as a call to action – can be a big talking point.

It’s a double-edged sword! Do you hide the login box to begin with under a ‘login button’, or do you go with the norm and leave it showing on the front page, but risk it being a total distraction due to its positioning? A question that a designer shouldn’t have to, and probably can’t figure out on their own without some interaction from an information architect.

There is absolutely no doubt though how important this phase is in a good website build! It’s paramount that design is not only up to standard, but that is ‘sets’ the standard! New techniques, interactions as well as connectives to modern technologies such as Ajax should all be encouraged and not frowned upon as ‘making more work for developers’.

Slicing

The “Do you seriously expect me to cut this PSD up for you in THAT many hours ONLY?!?!?” phase

Slicing is one of those things that in the past has taught me can greatly change how upper management think about the whole design process. Some managers think the hours dedicated to it are way too much, others think that’s just unscrupulous and without merit that it ‘generally’ is allocated the least amount of hours dedicated to it out of the whole web site design build process.

Which ever way we look at it, years of experience has taught me that not only are designers getting ‘crazier’ with rounded-corners, drop-shadows, beveled-edges and more; but Web 2.0 calls for all that snazzy stuff, and unfortunately, I don’t see that stopping, coupled with, we can’t stop technology – means we have to find a half-way house!

I personally think more time needs to be dedicated as a whole to the slicing process. Not only do slicers need to give the PSD (design) some life using CSS and JavaScript, on top of HTML – but cross-browser testing is a freaking arduous and taxing process – if nothing else! So respect to all you slicers, or Interface Hackers as I like to call them… I feel your pain!

Development

The “Okay, so I take the source files from here, and connect it to WHICH database?” phase

Development and slicing somewhat go hand in hand.. Whether the web site is being developed in C# (.Net), PHP, Ruby on Rails, or Perl for that matter – the task is simple and complex – or better yet, simply-complex!

This phase is important and hence why most of the time, you will find a good chunk of the hours allocated to a web-based build will be allocated to development. Unfortunately, that’s the nature of code! What you want to do, is make sure that there are adequate hours for the design and slicing – but ultimately, depending on the scope, budget and size of the project, actual development of the sever-side application as well as all the database connectivity as such should be the biggest chunk of the collective ‘development/build’ pie.

Obviously, if the project is just design and slice, then there’d be no time against development phase, or minimal (for testing, etc).

Testing/Quality Assurance

The “Yikes… You found HOW MANY bugs?” phase

It’s not easy to fight technology. Somehow, no matter how hard we try, Testing and quality assurance will (unfortunately?) always be a phase in the successful build of a website. To aid in keeping this short(er) than I expect it to be, I would just make the following suggestions in dealing with this phase.

1. Make sure the project plan/milestone outline clearly shows the testing phase as part of the project (from the get go!). This is important because the client has to realise that no matter what happens during the life cycle of the web build, how fast the build is, how many functions they take out, or whatever it may be – this phase is not going anywhere!

2. Treat it like you would any other phase. You wouldn’t get your delivery man to code your website, would you? Don’t get your secretary or janitor to ‘run through the site and tell you if they find anything out of place’. Believe me, it is sad but trust me – I heard that statement being said about two years ago and it’s been ringing in my ears ever since! Pay for a tester, they are worth the dollars you spend on them! and finally,

3. Make sure the quality assurance/testing is being done off a functional specification! For god’s sake people! Cardinal rule of unit/website testing. Go in there with a plan! Do NOT just pretend you are a user and ‘click around’. In my experience, around 60% of bugs found in this phase are always business rules that either the tester didn’t know about, or were simply forgotten. If they are on a document that has a signature on it, it WILL save your behind!

Deployment/Launch

The “So does that mean we can get paid now?” phase

Website design and development; once again, whether in Sydney, Australia or Sidney, Montana, USA – even though sadly many people don’t see it that way, is really an art. Wiliam has definitely set a precedent (and a name!) in the web design industry in Australia for not only delivering websites that work, but delivering websites that work great, and boy is that not a cliche!

It’s really about how you learn from your mistakes, co-ordinate change management in an ever-growing industry, and more importantly control technology that will ultimately dictate how you represent yourself as a web design agency/freelance web builder and best of all, how your competition view you in such a bloody competitive market.

So we’ve made it all this way. Launch the bugger! You’ve come all this way though and apparently you’ve survived. Don’t lose it all now! You want to make sure you take your time to get the launch right. Just like a top-secret launch sequence, make sure testing is complete, you have document listing where everything should go (server wise) – your databases are working fine and everything is connecting to where it should be – and then hit the switch!

Damn, wait.. Did you kill something? refresh, clear cache, refresh again, is it all still up? post to that forum that you created; is it threading correctly? Point is, make sure it doesn’t just stop when the last file is transferred. Building a great website involves a lot of co-operation from many people. It won’t happen overnight. Heck, sometimes it won’t happen over a six month period; but when you get it right? It’s a feeling like no other – or at least you’d hope so!

And that’s just about it… Happy web building people!

So, that was a long one. What are your thoughts? Do you agree on this model for effective website/web page design? let us know. Please drop a comment or if you like the posts, subscribe to our RSS feed to be alerted whenever a new post is available.

There are however many ways to make sure you get the best out of WordPress and what it has to offer you in terms of the speed, power and throughput.

Below is part one in the series of code tweaks that will ensure that your copy of WordPress; especially if running multiple CSS/JavaScript files and/or plugins – runs faster than ever before.

If you are running Apache webserver with mod_gzip enabled, you can compress your files by up to 75% in order to make your page load faster, as well as reducing your HTTP requests. Let’s just try out making your main .CSS theme file smaller today…

The best way to do this it to follow the following steps.

1. Backup a copy of the main .CSS file(s) used on the blog. For this demonstration, I will assume the main CSS file for your theme is called ‘style.css’.

2. Copy the file ‘style.css’ onto the web server so you don’t have to edit the original.

3. Rename the copied file to style.css.php – Yes, to .PHP (that means we are going to be scripting a little!)

4. Edit the file so that the following lines appear before any CSS. (I.e. if your first line of the CSS file has ‘body’, put a line break before ‘body’ so now it is on line 2 of your document, and then paste the following onto line 1).

[sourcecode language='php']

ob_start('ob_gzhandler');

header('Content-Type: text/css; charset: UTF-8');
header('Cache-Control: must-revalidate');

$expire_offset_time = 604800; // Set to a reasonable interval. I.e. 3600 (sec.) = 1 hr.
header('Expires: ' . gmdate('D, d M Y H:i:s', time() + $expire_offset_time) . ' GMT');

?>

[/sourcecode]

Let’s go through and explain some of the code for those that aren’t as technical with PHP. Any definitions below are courtesy of PHP.net.

Line 3:

ob_gzhandler() is intended to be used as a callback function for ob_start() to help facilitate sending gz-encoded data to web browsers that support compressed web pages. Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept, and will return its output accordingly. All browsers are supported since it’s up to the browser to send the correct header saying that it accepts compressed web pages.

In English, basically, calling “ob_gzhandler()” effectively means that the contents of the page below that call are compressed by default through Apache.

Line 5 & 6:

These two lines essentially setup the headers for the file (which will be asked for when a browser downloads the file) to tell the browser that the content in that particular file is CSS, and the character set being used is UTF-8 (character encoding for unicode). Secondly, line 6 sets up the Cache control of the the file. We are effectively saying that the browser should re-validate the contents of the time as opposed to, only-if-cached or max-age. The reason we apply the must-revalidate Cache control header is because a cache may be configured to ignore a server’s specified expiration time and so, we basically override this setting.

Line 8 & 9:

Line 8 sets up a variable we create called expire_offset_time which will hold the value ’604800′ which at this stage is just a ‘number’, but will be used on the next line as an expiry interval. Line 9 in this case sets the contents of the page to expire after the variable we set above; which now represents seven (7) days worth of the content not expiring. The calculation for this is: ((604800 / 3600)/24) = 7; where 604800 is what we set; 3600 is the amount of seconds in one day, and 24 is the amount of hours in one day.

And there you have it. Adding the above to your CSS file, appending .php to the end of the filename, and obviously changing the link in your homepage template can mean big savings in load time and site speed. Based on my CSS file, the savings in KB’s are pretty substantial to say the least! My CSS file on the server has a footprint of 23KB. As you can see from the image below, the new file size is 5KB – close to a (whopping?) 5 times smaller!! I’ll let the ‘after’ screen shot taken from Firebug speak for itself!

So what do you think? Have you previously tried this method? Did it work for you? Share your thoughts with everyone!

For those of us that are involved with design for the web on a daily basis, there seem to be many ways of creative navigation for websites that we come across. Over the last nine years or so on my journey designing for the world wide web, what I have noticed is that not only have conventions and ‘acceptable methodology’ changed on a regular basis – but also, the way some (big) site’s are architectured these days leave something to be imagined.

So without further ado; below are five reasons why I love tabbed navigation.

1. Tabs are an easy-to-setup form of navigation that don’t need to weigh down the load time of a website.

Whether it is CSS-based cross-browser accessible code or a simple unordered list, tabs are fairly easy to setup and re-use. The web design community is always coming up with solutions after solutions. A great example of accessible CSS-based tabs by Joshua Kaufman can be found here.

It’s also great to know that apart from the Web 1.0, standard text-based links, CSS-based tabs can now be done without any CSS hacks, with less code and the best part – without imagery; A formula for success.

2. Tabs are no supernatural phenomenon to not-so-techy web users.

Tabs are not just seen on the World Wide Web. They have been used for an incredibly long time. In fact, the reason why web user’s seem to get on like a house on fire with tabbed navigation is because they ‘know’ instinctively what they are supposed to do. Foldering systems, hanging-file folder tabs, as well the uber-cliched Inspector-Cluso style murder-mystery case files all have helped users to understand and appreciate the value of tabbed navigation on the Internet.

3. Tabs are very Web 2.0 and if coded correctly using XHTML lists, are fully W3C compliant forms of navigation

Gone are the days where 59Kb worth of images were needed to create tabs. These days, Web 2 techno’s like Ajax and even old-school style DHTML can spit out tabs that not only work well, but are 1000% W3C compliant. Sick!

4. Tabs are aesthetically pleasing to look at

Some would say, tabs for navigation also greatly aid in the representation of the overall look of a website. In all seriousness, I really dig how well-designed tabs can change the look of a site – completely. I really think there is something to tabs that not only make the user experience that little bit better, but also easier on the eyes than old-school list-based (yet accessible) non-tabs naviation. And last but not least:

5. Tabs are a collective norm these days in terms of navigational structures

Unless you have lived on the moon or under a rock for the past century, if done correctly, anyone is capable of understanding a website’s structure and information architecture from tabbed navigation. It’s the way to go in my opinion and best of all, you know that you are not re-creating the wheel if you use tabs – because there are not only hundreds of examples you can find online – but people still find it hard to believe that there are ways to create tab-based nav that don’t have to look 10 years old, or like Joe Blo’s tab system from across the information superhighway. Stay tuned because some of those ideas will be discussed in an upcoming blog!

So what do you think about this whole ‘tabulacious’ tabs for navigation? Do you currently use tabs on your site? Do you want to? Do you even like tabs? Share your opinions with the rest of the web world.

Whether or not it’s considered a feature of the highly usable browser, if you set a style of ‘background-color’ on an form input, the default shine and coolness that is Apple’s Aqua – is gone! Gone I say! *Shock, Horror*

Safari seems to as nicely as possible, make the background colour, in the case as shown below, hex code #a8ddf8, literally that colour. Cool you might think? I dunno. Always been a fan of the whole simplicity side of Aqua’s interface – especially the drop-down’s form inputs and how they are custom-designed (very much bullet-style!).

On another matter, In Safari 3 on Mac OSX Leopard, (ahh, Leopard!) if you assign a background color to inputs, Safari likes to remove the aqua-style imprint on the buttons and replaces that with flat-button style to replicate the color you’re you wanted. Ingenious? Annoying? I guess that’s subjective. However, there’s a surefire way to get around it… Either create a new class for inputs with background set to none; .inputsMinusBg { background-color: none; }, or, simply kill the background colour.

Till next time…