Building websites - how do you do it?

From reading the title of this post you might assume that I am about to talk about what I do every day and have always done. You are only partly right.

The specific topic I am interested in is the building of completely flat websites. That is to say the type of delivery to a client which is made up of HTML, CSS and JavaScript that will never be integrated into a back-end, never have any other coding wrapped around it but will be kept as a series of flat pages.

This is something I have had to do recently for the first time in some time and the question of how to achieve such a thing in an elegant manner keeping the trials of development to a minimum occupies some of my time now.

What I did in this instance was use server side includes to include all the common components of each page from a central resource - this includes things like global navigation, a footer etc etc. When it came time to send the code to the client, I then ran an ANT script (as supplied by the esteemed Mr Alexander, once more a colleague) to output the flat pages.

This seemed to work well for me. However, I was not happy with the way this worked for the CSS and JavaScript code.

During development, I wanted the CSS and JavaScript code broken down into many files to help me find where code was, organise new code and bug fix. I wanted the convenience of loading Firebug and being able to see exactly where my style declarations came from on any particular node.

For the final delivery, I wanted one CSS file and just a few JavaScript files. But how to make that happen without breaking my ideals during development? Well, I could end up using ANT to piece it all together just like the HTML code. But that felt a bit messy and frankly, hand crafting XML is about the worst thing I can think of doing.

This is where I stop providing solutions and pose a question. How would you have prepared your build? How would you have made sure that during development you could pull in only the bits of JavaScript that should have been on each page and then built the flat files correctly? Its more complex than it at first appears....

Reflecting on a return to action

I have now been with my new employer - EMC Consulting - for four weeks and to be frank, I now have a lot more of interest to discuss on this blog. So, I thought I would re start my posting here with some thoughts on these first four weeks.

I have spent the last fourteen months working almost exclusively on a large and complex JavaScript application and I wont deny that I did learn quite a little bit during that time. But I still find myself glad to be back working with all of my skills in a more balanced fashion. Its been refreshing to see how much people care about UX and accessibility and it is a pleasure to be able to combine that with my passion for high quality and minimal CSS and HTML code.

Already, pragmatism has reared its friendly head and is guiding my path. This is something I have to reacquaint myself with and I am enjoying that process. There is little to rival the feeling of writing code to fulfil a purpose, getting it done and working and moving on.

Yes, I now have to fix IE6 bugs again, but at least I am able to do so in the shadow of Borough Market and the delights that can be found within!

jQuery browser history manager

Despite being the creator of JSquared, I have recently had cause to use jQuery.

For the project where it is in use, I needed a browser history manager and after a very rapid cursory search, none came up that caught my eye. So, I decided to port my browser history manager from JSquared to jQuery and I woule like to make it available for you to use as well.

It works like all other browser history managers, appending named items with a value onto the hash portion of the URL in a QueryString like format.

The port is based on the new browser history manager that will be part of the next version of JSquared and it extends the jQuery object. You can download it here.

Using it could not be simpler. You set up named items you wish to listen for changes on and provide a callback function for when the change occurs. You can also update the value of an item as well.

To listen for changes, simply do the following:

$.url.listen( "myItemName", function(e, itemValue, itemName) {

    //perform some actions

});

Your callback function will be called when the user goes back and forwards and the value of your named item changes. The callback function will also get called if the user comes to your site from a bookmark and your item has a value.

To update the value of an item and create an entry in the users history, just do the following:

$.url.update( "myItemName", "myNewValue", false);

The third parameter to the update method is called "dontUpdateUrl". When set to true, the value shown to the user in the URL will not change, but the value internally within the browser history manager will. This is useful is you are updating many items and only wish to create one history point.

The new value can be any string and the object does not check that the length of the URL is safe - most browsers restrict URL's to around 2000 characters.

Please do feedback on whether this is working well for you.

position:fixed

Well well, I have learnt something new this morning. I think this new thing comes under the category of "how did I not already know this" but equally there is always the category of "kill IE6, please!".

I suspect that had IE6 dies off a good few years ago, I would already know this new technique as it is not supported in IE6. But I am very much of the opinion that we no longer need to support IE6 perfectly. I do not want to go into detail about browser support, I have spoken often enough about my thoughts on the matter.

So, onto the interesting part. Have you ever wanted to create a layout with an element which has a height of 100% minus some pixels? Or an equivalent for the width of an element? I know that I have on many occasions. Each time, I have had to either accept it cant be done or utilise some seemingly clever JavaScript to achieve my goal.

But, no more! position:fixed can now be our saviour. Picture the situation where you have a two column layout with your navigation in the left column and content in the right column. You want the left column to have a solid background colour and be 100% in height but leave a 50 pixel space at the top of the column. You might use the following markup:

<!DOCTYPE html>

<html>

<body>

<div id="LeftNavigation">

    <ul>

        ....a series of links

    </ul>

</div>

<div id="Content">

    ....some content

</div>

</body>

</html>

Now if you apply the following CSS:

#LeftNavigation {

    position:fixed;

    top:50px;

    bottom:0;

    background:#cccccc;

    overflow:scroll;

}

#Content {

    margin-left:310px;

}

You should see things exactly as I described above. The key styles are on the LeftNavigation DIV, the position, top and bottom styles. You should be aware that this is not supported in IE6 but I have found it works in all the browsers I have tried.

If this is also new to you, have a little play - it has certainly brightened my day!

Jamesnorton.com

I have launched my all new website at http://www.jamesnorton.com.

I wanted to get something out there to represent me and who I am and what I do, but the site is not complete. It will move forwards and change and be enhanced over time.

One thing you can all help me with is a potential Webkit bug particularly prevalent in Chrome but also an issue in Safari which I just cannot get to the bottom of. If you view the site in a Webkit browser and you get weird large white patches at the bottom of the screen, please do reply to this post with details of which browser you are using.

Otherwise, enjoy the site and feel free to provide any feedback you like.

Macro to micro blogging

You will obviously have noticed the quiet on this blog over the past 6 weeks.

Yes, its true, I have moved most of my activity onto Twitter now.

I have neglected my blog. I have found that I have a little less to say on here than I would like because I now only talk in units of 140 characters! I would encourage you to follow me on Twitter and that way you wont miss out!

I will endeavour to make more updates to my blog, but I will always keep updating Twitter...

Process

There is nothing like a discussion about process. Everyone has their own ideas, every company works differently.

I have recently taken a lot more interest in process. Last month I became a Certified Scrum Master and those who know me will know that I am a Scrum advocate. I think its a fantastic process. I have worked on a couple of projects that used Scrum and it has proven itself to be very successful.

Its a deceptively simple process which is far too often badly implemented. A poor implementation of Scrum is more damaging than not using Scrum in my experience.

I am not going to attempt to explain how Scrum works, I will leave that to the Wikipedia. Whilst not the best explanation, it will suffice. I personally enjoy using Scrum as it involves doing lots of small pieces of work which are well understood and can be fairly accurately estimated leading to reasonable expectations from clients and higher quality end product. I also believe that the speed with which issues can be surfaced is a massive benefit.

Doing Scrum badly will lead to more problems than if you were not doing Scrum at all. It is for this reason that most Scrum trainers will suggest that until you are experienced at using Scrum and implementing it well, you should follow the Scrum process pretty much to the letter.

A bad implementation of Scrum can force issues down and stop them being surfaced, can lead to inefficiencies as everyone attempts to work out what is going wrong and instead of opening up the process for all to see, it closes down the Scrum team and cloaks the detail in useless rhetoric.

I want to work on projects using Agile with Scrum. I do not want to be agile when I should be Agile nor vice-versa. I make a distinction between agile and Agile and its an important one.

When talking about agile with a lower case "a" I mean that I will show a more literal agility - responding to change, trying to prototype quickly and generally being flexible. This is great for a client but dangerous. Too much agility will lead to timelines slipping or the dreaded overtime!

Agile with a capital "A" on the other hand is a process and a set of techniques including but not limited to Scrum and XP. When I am being Agile, I will not respond to change in the same way, the person requesting the change has to follow a specific process, a simple process and one which is totally transparent. I have never heard a client complain about having to do that when the result turns out to be a better product. The process protects me and my Scrum team from being distracted, allowing quality to rise whilst also forcing the clients priorities to be my priorities.

From this realisation I have chosen to be Agile not agile.