Web Interface Development

Building websites - how do you do it?

2009-11-19T14:32:00.002Z

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

2009-09-22T12:20:00.003+01:00

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

2009-08-10T13:48:00.004+01:00

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

2009-07-17T11:34:00.003+01:00

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

2009-07-03T08:42:00.004+01:00

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

2009-07-03T08:37:00.002+01:00

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

2009-05-14T22:12:00.003+01:00

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.

JSquared 2.1

2009-05-14T12:58:00.002+01:00

I am very pleased to announce that JSquared 2.1 has been released as of this morning.

Check out the website for yourself, follow the JSquared blog, download the code and read the docs.

Recent times

2009-04-24T22:48:00.002+01:00

I am sure you will have noticed that posting has been light on here the last few weeks and I thought it might be interesting to talk a little about what I have been doing.

I have spent most of my spare time working on JSquared. The code base is coming on nicely now. I have completely re-written some parts of it even since the latest release and I am getting close to being code complete for the next version. Some more demos will come soon as well, but you can get more information on that over on the JSquared blog over the coming week or two.

Recently I have achieved the status of Certified Scrum Master. This is something about which I am very excited. I believe that Agile with Scrum is a fantastic engineering process. I have seen it in action myself whilst I worked at LBi and I am actively looking to assist Betfair in making the transition to this process. It can be painful and without doubt we are not yet getting it right, but with time, I am sure we will.

Now that I am officially certified, I feel more able to push things forward with Betfair and I have gained a great understanding of the process. I even think that I might bring some of the principles to my "normal" life, though I am not sure my wife will like a daily scrum meeting!

Hopefully I should be able to work on some more exciting things over the coming months than in the last few and I will be sure to blog about any and all the exciting happenings in the world of Betfair. For now, it seems I am far more an observer than participant in this great interface development world in which I live and work.

JSquared 2.0

2009-04-05T18:12:00.003+01:00

For those of you that might have missed the news, I released JSquared 2.0 today, April 5 2009.

This version represents a massive step forwards for the library. There is a whole new website to go along with the massively revamped code base. The documentation has become much more extensive and the website now features demos of how some of the library works.

The best thing to do is to check out the website for yourself, follow the JSquared blog, download the code and read the docs.

IE6

2009-04-02T12:56:00.003+01:00

IE6 is a browser that all web developers hate. Or at least that is the case if you tow the line.

IE6 used to be by far the most common browser and once was the most advanced. However, things have moved on since 2001. Web developers hate IE6 for its poor implementation of standards. Web developers hate the vagaries of the IE6 rendering engine and the performance of its JavaScript engine. These problems are well documented elsewhere.

However, the important people, the ones who matter, the ones who web developers do all their hard work for - the users - they don't seem to care nearly as much. This can be evidenced by the proportion of users who still use IE6. Even today, 8 years after its launch, over 15% of users typically visit a website with IE6. If I were Microsoft, I might just be congratulating myself for making a product so beloved of its users. Of course, where I to do that then I would naively be ignoring the massive proportion of users who have no idea what browser they are using, that there are other browers out there or how to switch.

We as web developers must also not ignore this set of users. There have been a lot of campaigns started recently to end IE6 support. Some have gone even further such as this one I just came across. I support the idea of getting our users using a more modern browser, but its up to them not us.

I don't get the big deal here. I stopped treating IE6 as a "fully supported browser" about 2 years ago. I think the problem here is this idea that a website must look identical in all supported browsers. What is wrong with a website looking subtly different in different browsers?

Of all the websites I have built from scratch in the last 2 years, not one has looked identical in different browsers unless it has been demanded from the client. They all worked in an identical way, but they looked subtly different - generally because browsers have different default rendering styles.

These differences have never been an issue. In IE6 you might get simpler button styles, you might get a more linear visual layout or you might find text looking slightly different. When I have shown them to a client and explained why they are different, the client does not care either - in fact they are thankful for the money and time saved!

I have only had problems with IE6 when I have been maintaining a site where the client has it in writing that browser support will include IE6 and that the site will be identical in all browsers.

In the many many demonstrations to clients that I have made in the last 2 years, I have never once been asked to use any browser other than the one I picked for the demo.

So, I just don't get the big deal with IE6 these days. Lets make a big deal about why we need to make websites look identical in different browsers on different platforms. Lets make a big deal about making websites more accessible. Lets make a big deal about building standards compliant websites with the simplest possible code.

If we spend our energies doing this, then we are more likely to have built-in zero cost support for many many browsers including mobile browsers, not just a narrow set often defined well before the release of a website and therefore out of date at its release.

CSS Selector Engines

2009-04-01T23:16:00.004+01:00

CSS selectors are a great way to pick DOM nodes off a page and many JavaScript libraries use them extensively.

For those that have used JSquared, you will know that there is no CSS selector engine built in. Some people have asked why and I have always said that I think its simpler, faster, easier and makes a better performing application to use standard DOM methods to pick elements.

Well, yesterday I saw TaskSpeed and it got me thinking. I was about to start making a JSquared version of the tests in order to see what the performance was when I cam across this post which proved the point I wanted to make without me having to do any work!

Andrea shows that using native DOM methods is by far and away the fastest way to complete the tests. Whilst this isn't totally related to a CSS selector engine, it does show that native methods are the best and that certainly holds true for the few parts of the test where a selector engine would be used it it existed.

Of course, once all browsers in use support the Selectors API, all will be much improved,

What do you use?

2009-03-31T22:54:00.002+01:00

Every now and then I like to play with some new tools. Try a few Firefox plugins, maybe a new dev environment. This week is one of those times.

So make your recommendations, what do you use that is cool and why?

Just to get things started and to pre-emptively give something back, I have recently been playing with Spotify which I can recommend as a great way to listen to some new and old music.

I have also been playing with XUL Profiler which is a pretty cool Firefox plugin (a nightly of Minefield works best with it I believe) for profiling your JavaScript and analysing how much work the browser is doing to render your page.

Now its your turn...

Twitter

2009-03-25T11:27:00.003Z

Twitter is something I never looked at until very recently and for some reason I have suddenly decided to use!

So rather excitingly, I am now on Twitter and you can follow my antics (or whatever I bother to say on there) at http://twitter.com/nortools.

I hope you have as much as fun reading as I do writing.

IE8 - right, wrong or something else...?

2009-03-17T09:25:00.004Z

For those that don't know I was recently struck down by a rather severe bout of bronchitis which has laid me low for 3 full weeks. I am delighted to say that I am almost fully recovered. Though just to be sure, I am still "taking the pills" - a form of prevention as much as cure.

Its amazing how similar that situation is when compared to Internet Explorer.

For many years, IE was suffering from an infection - non-standards compliance. There was a lack of anti-bodies to kill it off. But Microsoft finally took its sick child to the doctor who prescribed a welcome initial course of anti-biotics and so IE7 was born. But all was not fully well, so a second course was required.

As Microsoft now force-feeds its child the last dose of that medicine, we see IE8 emerge. Standards compliant, much improved performance and an all round more open approach to development.

But the virus remains, dormant for some but nonetheless very real and there. It has mutated into compatibility mode. Luckily there is a vaccination, a form of prevention, and that is a valid doctype and standards compliance.

Of course, you could stop reading the drivel I am writing and read about what Jon von Tetzchner from Opera thinks of IE8.

Whatever you think of Microsoft and IE, you have to acknowledge that they are trying. They cannot please everyone and certainly the remaining prevalence of IE6 does not please me, but I do believe they are trying. Now if only they could speed up their release schedules, I could finally breathe easy.

Standards - again

2009-03-16T17:21:00.003Z

As if to reinforce what I was saying 4 months, the unique and unparalleled Douglas Crockford has articulated in part my own thoughts about HTML 5 in this blog post.

As I said back in November:
I want to see greater interoperability between the various browsers and as such I believe simplification would be better.

Changing style regarding changing style

2009-02-16T22:47:00.002Z

I was having a conversation with the esteemed Mr Alexander today about changing CSS styles based on whether JavaScript is enabled in the users browser.

This problem had consumed some of my thoughts in the past and eventually I chose to use the technique I termed progressive degradation, something I have blogged about in a previous post.

Progressive degradation involves writing your CSS with the assumption that JavaScript is enabled. You then include an additional style sheet in this way:

<noscript>
    <link rel="stylesheet" href="noscript.css" type="text/css" media="screen" />
</noscript>

This has generally worked well for me with the one caveat that this is invalid HTML. This has concerned me a little. The argument which both myself and Mr Alexander have used is that this is easily the simplest way to adjust styles depending on whether JavaScript is enabled or not.

I prefer to write my CSS with the assumption that the best possible experience is available and then include CSS to enhance the experience for those users with a less capable user agent as required.

Mr Alexander proposed another potentially neat solution:

<link rel="stylesheet" href="noscript.css" type="text/css" media="screen" id="noScriptCSS" />
<script type="text/javascript">
    var noScriptCSS = document.getElementById("noScriptCSS");
    noScriptCSS.parentNode.removeChild(noScriptCSS);
</script>

In this example, the noscript CSS file is always in the document and it is then removed using JavaScript immediately. I haven't tested this, but my first thought was that I would need to investigate if there would be a flicker on the screen as the page is reflowed, affecting the rendering performance of the page. My second thought is that this technique involves an additional HTTP request for all users not only those who need it.

There is another well known technique which involves writing your CSS assuming that JavaScript is not available and then including a script enabled CSS file using JavaScript as the page is being rendered. I am not a fan of this technique as I prefer not to write my CSS in this way.

There are a variety of other techniques as well such as changing a class on the BODY tag using JavaScript and cascading your selectors from that. If using this technique I would always have a noscript class on the BODY and then remove that (again, it fits better with the way I like to write my CSS).

This issue often raises its head and frankly I am now not fully satisfied with any of these techniques. So what do you think? What is the best way of handling this issue?

Browser detection

2009-01-20T14:56:00.002Z

I am not a fan of user agent sniffing. I think it is a wholly inappropriate way to find out the capabilities of a user agent accessing your website.

However, it has its uses. Steve Souders built UA Profiler, for gathering browser performance characteristics. This is undoubtedly an important and intriguing project. In order to detect which browser you are using, he has written his own user agent sniffing code as he describes in his latest blog post.

He also offers to make this code available through a web service. This is an intriguing possibility. My first reaction was to think that this was an excellent move. A high quality user agent sniffer, improved upon by the community and its breadth of use that we could all access via a web service meaning we would not have to ask our users to download the code to do the detection.

Having calmed down slightly, I started to think more clearly. Overall, I am not convinced this is the best idea. Generally I feel that detecting a user agent from its user agent string is dangerous. This makes the assumption that no user agent spoofing is taking place, that your detection is granular and perfect enough and that browser features and support will not change. None of these are necessarily true.

I prefer to use feature detection. If I want to know whether the browser I am using is capable of applying a particular method, does that method exist?

The only reliable way I have found to detect a browser is for Internet Explorer only using conditional comments, both in HTML (useful for including CSS and JavaScript files for specific versions of IE) and in the JavaScript itself.

I notice that the latest version of jQuery (1.3) is deprecating its user agent sniffing. This decision is to be applauded.

I also realised that the next version of JSquared will actually add the ability to determine if the browser you are using is IE and if it is version 6 or another version. Whilst I might be adding a limited set of user agent support to my library, I am trying to do it in a fail-safe way.

Using CSS3

2009-01-07T12:40:00.003Z

Despite ones personal feelings about it, I am really keen to start using CSS3. There are a number of browsers with support for some of the interesting parts of CSS3 and I think there is a new opportunity to use our skills of progressive enhancement to create some really exciting new effects.

If we wisely apply the appropriate properties, we can enhance the user experience for some users - and an increasing number of users - whilst offering a more than acceptable experience for the remainder of our users.

There may be a useful side effect here as well. When people see a site enhanced by the latest web browsers, we may get more users switching from older and less standards compliant browsers to the more modern and better newer browsers.

We may have to use vendor specific prefixes to get some effects to work, but I think that is a small price to pay to help push forwards the use of the good parts of CSS3.

The best part of all this is that as new browsers are released and used, our websites will look better and a good level of support is on the horizon. Safari 3 already has a good level of support, IE8 will have some and Firefox 3.1 will have a good level of support. With Safari having decent support for CSS3, it means all modern Webkit browsers should as well - read Chrome and the iPhone browser in particular!

So which properties might be able to be used in this way? Here are a few select ones that I think could be useful:

box-shadow
With this effect, we can create drop shadows around boxes. When this property is not understood, there is no detrimental effect and when it is recognised, a nice enhancement can be achieved.

border-radius
This effect allows us to create rounded corners using only CSS. I think this is useful as its simpler than any other technique and support can be achieved for IE by using conditional comments to include other stylesheets. Firefox 3 and Safari 3 already have support for this property - definitely one of the most useful to start implementing.

text-shadow
Similar to box-shadow, this effect will create a drop shadow effect around text. Another nice enhancement. Not strictly a new addition in CSS3, but support seems to be coming with CSS3 support.

There are other interesting effects coming, but I think these are the most potentially useful when applied using the principles of progressive enhancement. There are also a couple of useful new selectors coming, but its hard to see how one could use them with the principles of progressive enhancement.

I am excited about some of the new features of CSS3 and its great to be able to start using some. Indeed, the new JSquared website will feature some new CSS3 effects applied in this way.

What we do need to be cautious of though is creating a complete maintenance headache. Lets start using new features, but sparingly at first. We dont want to make development even harder with yet another class of browser to support.

Happy new year

2009-01-07T12:34:00.002Z

I wish you all a (slightly) belated happy new year.

2008 was a tough but amazing year. Some of its highlights for me included getting married, having an amazing honeymoon and having 3 different jobs!

Some of the less good parts included having 3 different jobs! I am working harder than ever now at home and at work and have had much less time in the last 6 months to blog or work on JSquared than I would have liked.

But things can change for 2009 and so I hope to only have 1 job this year, not get married again (as amazing as that was) and give a bit more time to blogging here.

As you can see on the JSquared blog, work has resumed on the project after a period of quiet and I have a new team member on board to make the project even better and an even bigger success.

This is hardly going to be a quiet year though as I hope to move house - here's hoping Mrs N and myself can find the right place!

I hope you all have a happy, healthy and successful year and keep reading....

A rant

2008-11-18T14:25:00.005Z

I have tried hard not to fill this blog with random off-topic rants. I am about to break that rule. If you do not wish to read my rant, please move on - normal service will be resumed shortly.

There is some (tenuous) relevancy about this rant. I will mention user interfaces!

My rant is about iPod's. No no, sorry, its about iPod users and iPod headphones.

I use an iPod. I use it because it was given to me and is 8Gb whereas my MP3 player of choice (a Creative Zen Stone Plus) is only 4Gb. It is a 3rd gen nano and is truly wondrous to hold and behold. I find the sound quality lacking in comparison to the two Creative players I have had, but it serves my needs adequately.

I am not such a fan of using the iPod. I often find myself getting frustrated at the imprecise and slow controls - I just want to move to a position within a track and change volume without waiting for the interface to allow me!

Anyway, I was sitting on the train this morning - not listening to my iPod - and the woman sitting next to me was listening to hers with the rather poor, but iconic iPod headphones.

She felt she had to have the volume turned to maximum just to be able to hear her music through those rubbish and very leaky headphones! This resulted in the whole carriage "enjoying" her music along with her. And I got the brunt of it.

In short - if you have an iPod, buy some decent headphones!

</rant>

Browser wars

2008-11-03T17:16:00.003Z

To finish up this little series of posts about browser standards, I wanted to refer to the browser wars and ask this simple question:

Do we need another browser war?

Well? What do you think?

I think we cannot have another browser war in quite the same way. When it was Netscape vs Internet Explorer, every user spoke (or perhaps didn't speak) and chose (or perhaps was simply given) Internet Explorer. What then happened is that all the proprietary features of IE could be safely used whilst knowing there was a very high support rate.

Since IE6 came out and the browser war ended, there was a little stagnation but really what happened was that people got a bit bored and wanted more. So Firefox came along as a viable competitor. That was the time to have a browser war. The moment has passed.

Right now there is too much competition (or maybe none - its hard to tell) between the browser vendors. The market is too segmented. We now need the vendors to follow a standard spec. And so we get into the sordid world of the W3C and standards.

Standards?

2008-11-03T16:56:00.003Z

Yesterday, I posted about some of my thoughts on web standards. It raised some questions for me. It was a post I was reluctant to make but only because I could not reasonably say in one post how I feel and what I think about the current state of affairs. I don't want this blog to descend into a series of rants about the W3C and standards etc etc.

I will attempt now to clarify my thoughts on where we should go from here.

Firstly, I think we do need to make progress. We need to move things forwards. We cannot stagnate. We must find ways to innovate. However, I don't think we have even scratched the surface of what is commercially possible and viable given today's technology. The browser has proven itself to be a remarkable platform capable of producing almost any sort of UI.

So here are some thoughts for each proposed standard:

HTML 5
I am unconvinced by large parts of the spec and I think it is far too large a specification. I want to see greater interoperability between the various browsers and as such I believe simplification would be better. I also strongly believe that the next spec should enforce an XML type syntax. Its easier to maintain and easier to find errors. I would encourage the browser vendors to simplify their parsing engines, not force them into more complicated solutions.

CSS 3
The power of CSS is in its expressive simplicity. This will not be lost within CSS 3, but do we really need much more on top of CSS 2.1? Do we need to have 4 rendering engines in wide use which are trying to implement a load of new CSS properties that will not be widely used? Are we not better off getting the current specs properly implemented with perhaps a few additions (multiple background images comes to mind) which can be progressively applied using the principles of progressive enhancement?

JavaScript 2
I do not think JavaScript should gain classes and I do not think the language should be greatly extended. Interfaces may be a useful addition, but generally I just think a little tidying is needed. Its in the DOM that work is required. Lets get the DOM objects of the various browsers to be more closely aligned with each other.

What I am generally advocating is a simplification of the specs to make them manageable for browser vendors. Lets give the browser vendors an easier task to get themselves up to scratch and then lets ask them to add new features. As always these new features should be able to be applied using the principles of progressive enhancement.

The savior for us all could be JavaScript libraries. They transcend the browser differences hiding them conveniently. Of course that creates a level of ignorance about those issues amongst some, but they are undeniably popular and successful.

But the world of JavaScript libraries is amazingly similar to the early world of the browser. They all do basically the same things but in quite different ways. Some libraries do some things well, others do other things well. Funnily enough, libraries need to converge on something of a unified API. Just like the browsers.

So for the foreseeable future, the web developer will continue to bridge the gap with ingenuity, cunning, blood, sweat and tears. Its OK for me, but will it still be OK in 10 years time? Will we still be in the same situation in 10 years time? Sadly, I think yes. Does this dull my passion for my job? Absolutely not! I enjoy dealing with these vagaries and having to think on my feet every day!

Surely though, we can sort this out, one way or another...

Standard nonsense

2008-10-31T15:47:00.008Z

My thoughts on web standards change on an almost weekly basis. I now consider myself a sceptical evangelist! I believe in web standards as an end but I do not agree with the means by which we seem to be getting there. I think we should be using web standards, but I live and work in the real world where web standards remain nothing more than a laudable goal and an occasional convenient excuse.

Currently, we have HTML 5 and CSS 3 and JavaScript 2 as the shining examples of where we are heading with web standards. I am aware that JavaScript 2 is no more (the end of a great folly in my opinion), however, these three serve to demonstrate my point.

The vast majority of users on the web, and surely its the users who are most important - not us developers, are using Internet Explorer as their primary web browser. IE is a fine product for browsing the web today and I suspect it fulfills the needs of those users in the vast majority of cases.

A good proportion of users are using Firefox with many using Firefox 3. This too is a fine browser. As is Safari which dominates the remaining small proportion of users.

At this point, others may launch into a diatribe about how users should switch browsers. Some may wish to analyse the statistics on a deeper level. But I wish to just re-iterate that for users, their current browser works fine! Why are we - the developers - getting so upset about users not changing their browser?

HTML 5, CSS 3 and JavaScript 2 are (or were) all meant to be innovations and additions to the interface developers toolkit, allowing us to do exciting new and innovative things. Creating new types of web pages, allowing the user to interact in new and exciting ways. Hmm. Writing that makes me think of AJAX. AJAX was meant to be an innovation and an addition to the interface developers toolkit allowing us to do exciting new and innovative things. AJAX was meant to allow us to create new types of web pages, allowing the user to interact in new and exciting ways.

Why did it work with AJAX? Its because support was already in the users browser. When AJAX started to become popular, there were some older browsers in use almost as much as Firefox 2 is in use today. Well, those older browsers disappeared as users could not access the websites that used advanced AJAX techniques. The other very helpful factor for AJAX was that computers became very cheap and very powerful and so users were upgrading more easily and more frequently. Most users only change browser when they change computer.

I believe there are the following 3 main reasons that HTML 5 and CSS 3 are not in common use today and will not be for at least 5 years from now:

The W3C
A large slow moving organisation that seemingly cannot decide in which direction to lumber. There has been some progress over the last year, but they have absolutely set the pace. The gap between HTML 4 and HTML 5 being proper standards will be mirrored by the gap between users using browsers which implement those standards.

The browser vendors
More slow moving organisations. The era of co-operation never began and never will be. There seems to be more effort being made to improve the performance of existing browser features rather than in implementing anything new. This in itself is a positive, but it does not really move the game forwards. This is the vendors playing catch-up so the websites we already build can run in a more reasonable fashion.

There appears to be so little real competition in this market that vendor specific features are becoming acceptable again within the web development community. As developers we just want something shiny and new to play with!

The Users
The only group that should really matter. Users have not been given any real incentive to change browsers or to support those vendors attempting to implement and push forwards new standards. Users will only shift their position on this in response to catastrophic security issues or a family member who knows better and has a convincing voice.

Users still use older browsers such as IE 6 and Firefox 2 because there is nothing that the newer browsers offer which is compelling enough to make the change. Users are not technically savvy and nor should they have to be. Users only demand reliability, usable performance and security - even IE 6 can provide that.

Ultimately, there is no business case for building a website implementing new standards. Indeed, the opposite is true - it is better for businesses to ensure their websites work on the widest cross-section of browsers out there which means implementing old standards.

So is this all a cause for depression? Absolutely not. Do we need new standards? Not really! Wow, that was a controversial statement. I would like new and more appropriate standards, I would like those standards to be adhered to so I don't have to deal with cross browser issues. But, I am still doing really exciting and innovative work, I still find new bugs and issues with the browsers and I am yet to see a design or specification for a website which I could not build with today's existing technologies.

The Quiet

2008-10-30T16:15:00.004Z

Its been pretty quiet on this blog for the last 6 weeks or so. I have been very busy working on an interesting, fairly complex and fairly large JavaScript application during the day and then recovering from it at night! I also had the pleasure of a lovely week away in this period of quiet.

I have also recently got my hands on a rather sexy new phone - an HTC Touch Diamond - and have spent a lot of time playing with that. Its a Windows Mobile PocketPC and its been an interesting experience, particularly Opera 9.5 Mobile which is the default browser.

Browsing on a handheld device has been a new experience for me. My phone comes with Pocket IE installed as well, but that is rather archaic. I have done all I can to avoid using it.

Opera Mobile however is a fantastic browser. Its fairly fast, pretty standards compliant and renders most pages rather well. It has also given me a useful insight into a different type of user agent for browsing the web. Its quite a different experience and its easy to see which sites are well designed and which are not.

I have taken away a couple of important lessons from my experience. Firstly, clear interface design is very important on this type of device. The browser can zoom into pages but when a page loads, it is zoomed out and most text cannot be read clearly at all. However, a site with good design is very usable as I can zoom in on just the right area. Clearly defined navigation really helps with browsing on a mobile device.

The second lesson I have learnt is that the easiest sites to use employ a liquid or semi-liquid layout. My phone has a resolution of 480x640 and if a site can flow its content to fit into either of those widths, that helps greatly. If I were designing a website today, I would definitely ensure it works in a browser width of 640 pixels!

The final lesson I have taken with me thus far is that the size of elements on screen really matters. I use my finger to navigate a website and having links tightly packed together with a small font size makes life very difficult. Having small form fields or form fields with a small font size and another link right next to or just underneath the form field can make it difficult to select the element I want to interact with. Finally, having heavily styled buttons, especially image buttons makes submitting a form harder than it needs to be, particularly if pressing enter on the keyboard does not work.

For me, the most noteworthy new aspect of interface development that I will carry with me is the importance of keyboard interaction with a form - never ever stop a form being submitted with the enter key!

There is much more to say about this phone and browsing the web using Opera, but at least for now, the quiet is no more!

Another JavaScript pattern - private members shared between object instances

2008-09-17T16:10:00.000+01:00

In this post, I will introduce another pattern to add to my previous post about my JavaScript patterns. In fact, this is an extension to those patterns and combines both patterns together! This is a singleton pattern that creates a constructor!

In this post I will also make use of some aspects of JSquared, so please refer to the JSquared website for more information on those.

So, private members shared between object instances. What does that mean? What it means is that I want to have some private variables and functions which are accessible to multiple instances of a constructor but without them being part of the constructor or the objects the constructor will create. A fairly well known way of achieving this is by making the prototype of my constructor an object built using something similar to my singleton pattern. This would allow public and private members on the prototype of my object. But that will not give me all I wish to achieve this time and it can be a clumsy syntax.

The code I will use to help explain this concept is designed to be a simple panel object. The object will manage a series of panels on a webpage which are linked. Only one panel can be open at a time. Typically one would construct this with a singleton object which finds all instances of the panels in the DOM and adds some handling to each DOM node accordingly. I will do this in a different way. This code example is of course merely a skeleton.

var Panel = new (function() {
 
    //add a DOM load event 
    addLoadEvent( function() {
        //get all DIV elements with a class of "panel"
        document.getElementsByClassName( {cssClass: "panel", tags: "div", callback: function() {
            //create a new instance of the Panel constructor for each panel
            new Panel(this);
        } } );
    } );
 
    var panels = [];
 
    function closeAll() {
        for (var i = panels.length-1; i>=0; i--) {
            panels[i].close();
        }
    }
 
    //return the Panel constructor
    return function(panelNode) {
        this.open = function() {
            closeAll();
            //perform the open logic
        }
        this.close = function() {
            //perform the close logic
        }
        //add this instance to the all instances array inside the closure
        panels.push(this);
    }
});

Lets step through each part of this example and see what it does:

var Panel = new (function() {

Create a new variable called Panel using the singleton pattern.

    //add a DOM load event 
    addLoadEvent( function() {
        //get all DIV elements with a class of "panel"
        document.getElementsByClassName( {cssClass: "panel", tags: "div", callback: function() {
            //create a new instance of the Panel constructor for each panel
            new Panel(this);
        } } );
    } );

Using JSquared methods add an event handler for when the documents loads. The handler will use another JSquared method to find all elements in the document which are DIVs with a class of panel and for each one run the supplied function which will create a new instance of Panel passing in the DIV node with the class panel that was found. (see the JSquared docs for more info on how getElementsByClassName is used)

    var panels = [];
 
    function closeAll() {
        for (var i = panels.length-1; i>=0; i--) {
            panels[i].close();
        }
    }

These are the private members which each instance of Panel will have access to. We have an array of panels which will get filled with each instance of Panel that is created and we have a closeAll method that loops through each instance of Panel and calls its close method.

    //return the Panel constructor
    return function(panelNode) {

We are going to return a constructor (using the standard constructor pattern). The variable Panel that we created at the top of the code example will now take the value of this constructor. In other words, Panel becomes a constructor which we can create instances of using the new keyword.

        this.open = function() {
            closeAll();
            //perform the open logic
        }
        this.close = function() {
            //perform the close logic
        }

Create open and close methods which will perform those actions. In the open method, we first want to close all the panels ensuring only one can be open at any time. To do that we call the private closeAll method which is available through the closure around Panel.

        //add this instance to the all instances array inside the closure
        panels.push(this);

Add this new instance (this line of code is still part of the Panel constructor) to the private panels array also available through the closure we have created.

To recap, we use the singleton pattern to execute some logic before returning a constructor which is then available to us later on in the page execution. We can use the closure this creates to make private members, declared inside the self executing function which is the singleton pattern. These private members are available to each instance of the constructor but the members are not available anywhere else within any JavaScript - as is usual for a closure of this type.

This can be a very powerful and useful pattern. When building a large application, I believe it is good to keep public members of all objects to a minimum and I also prefer not to use the prototype of an object unless I am using inheritance. This pattern achieves both of these aims in an elegant and encapsulated way.

Google Chrome

2008-09-02T21:23:00.002+01:00

So, its finally happened. Google's next step towards world domination is here, and its a web browser! Its also pretty clever. Indeed, I am writing this post in the new browser.

Its called Google Chrome. The Google Chrome chrome is extremely minimal and I like it. The tabs have certainly taken center stage and got a nice feel to it. It is extremely fast to use and the JavaScript engine appears to be fast and well, I am impressed!

Its well worth a download and a play, and dont forget the developer tools - yes, they are included in the browser.

I wont go into any technical details as Google have done a good (if somewhat unusual) job of explaining things. Check out the website for more information.

My favourite feature so far is the way the browser remembers searches you perform on other sites and makes it so easy for new searches to be performed.

If this is how Google are approaching their application development - and lets face it, no-one expected anything different - then I have high hopes for Android. On that subject, I have recently become the proud owner of an HTC Touch Diamond which is a Windows Mobile phone and I am keeping my fingers crossed that Chrome Mobile is coming soon!

As an aside, being a Webkit based browser, I was hoping that JSquared would "just work". However, I will be doing some testing and you can expect another report soon, especially given the new JavaScript engine.

The future of JavaScript

2008-08-21T17:29:00.007+01:00

For those who have not heard, ECMAScript 4 is no more. That also means that JavaScript 2 is currently at best paused. Some will mourn this as a great loss. I am not one of those.

JavaScript 2 had some very interesting ideas in it, but I am far from convinced that it was the future. I firmly believe that JavaScript 1.x has a long long way to run yet.

It is not often that I will link to an article on Slashdot, but this one piqued my interest.

The future of JavaScript is very much tied up in the present and future of browsers. Much of what I have to say here is also true about future versions of CSS.

The problems we as web professionals face today is not due to a shortcoming of JavaScript or CSS or HTML. They are due to shortcomings of the browsers. Until browsers support the standards, there may as well not be standards.

So we have options. We can introduce new ideas and new technologies which will only be supported by a sub-set of users for a fairly long period and will then fall into a category of technologies we are reticent to use due to the need to support older browsers.

Or, we can wait for the browsers to catch up with the standards so that we can exploit them to the full, with guaranteed compatibility.

Well, I dont fancy waiting something like 4 or 5 or even 6 years for browsers to catch up with the standards, I want to do cool, new and interesting things now. So, we are left with the former of the 2 options I present above.

Of course, the thing which allows us to push forward and use the new technologies of CSS and JavaScript which are being introduced and still provide a good level of cross browser support is JavaScript! Look at how the innovative use of JavaScript, largely by library authors, has driven the W3C and browser vendors to introduce new native features to the browsers. This is only of benefit to us.

I firmly believe that changing the core nature of JavaScript now would undermine a lot of the good work of the last few years and it would also be to deny the true power of JavaScript as it stands today. Yes, there is a barrier to people wanting to learn JavaScript - it can be complex, it is difficult to master - but this also is a good thing. Ultimately the standard of JavaScript development will improve and we don't need a new version of the language to make this happen.

JavaScript is an amazingly flexible language and finding new ways of bending it to our will is going to define the next set of standards, the next set of tools that we want to see, and it is the next set of standards that are far more likely to be adhered to than the current generation.

We must not stifle innovation, we must encourage it. Keeping a massive level of embedded knowledge whilst JavaScript is still at its infancy of true professionalism is the right way forward. Maintaining the core of the language as it stands moving forward must be a good thing. Yes, lets play with other languages in the browser, lets even use and support them, but where JavaScript is concerned, my message is clear - don't go changing!

Complex assignments

2008-07-30T21:00:00.000+01:00

I find my coding style continues to evolve as time goes on. This suggests to me that I am still a long way off getting it right! However, it also gives me the chance to play with new ideas and introduce new concepts to my code.

One new pattern that I seem to now be using more and more is one I call Complex Assignments.

To introduce this, it is useful to look at simple assignment code first. An assignment is simply setting one thing equal to another:

var myVariable = 1;
 
this.myMember = "Some text";
 
this.myMethod = function() {
    ....
}

These are all simple assignments. Sometimes though this is not enough. Sometimes you need to set the value of a variable based on some parameter, eg:

function( myParam ) {
    var myVariable;
    if (myParam === 1) {
        myVariable = "Some text";
    } else {
        myVariable = "Some other text";
    }
}

Now of course this is a trivial example, but you may find yourself needing a more complex set of rules. In that case, the logic around this assignment can become complex. To alleviate this problem we will often delegate the assignment logic into a function. This is perfectly acceptable and actually desirable and in a JavaScript object we can make a private function to do the work:

function myObject() {
    this.someValue = getSomeValue();
 
    function getSomeValue() {
        //do some work
        ..... 
        return someValue;
    }
}

However, if this function is only going to get called once, there is no need to make it a named function. In fact I find it neater to make it an anonymous function. Of course, if its an anonymous function that only gets run once, we can make it a self invoking function. To rewrite the example above:

function myObject() {
    this.someValue = (function() {
        //do some work
        ..... 
        return someValue;
    })();
}

In this instance, the code looks very similar (if somewhat neater). But, with this anonymous self invoked function, we are actually creating another level of scope which will get destroyed once the function has been executed. This can be very useful and can be very efficient. I also think the code is simple to understand and even better encapsulated.

This is particularly useful for the setting of constant like variables. I find myself using this pattern more and more as I find more occasions where I want a function to be used to assign a value to a variable.

Coupling, API surface area and change change change

2008-07-17T14:08:00.004+01:00

Recently I started a new job focusing much more heavily on JavaScript than before and having been in this new role for a little while and having got the release of JSquared 1.1 out of the way, I have had some time to think about what I have learnt so far.

Firstly it must be said that I am thoroughly enjoying working more heavily with JavaScript and I have already learnt some wonderful and interesting things about the way that JavaScript operates and how to make it go a bit faster. No, a LOT faster! I will be talking about some of these things in the future and applying that knowledge to JSquared!

Also, I have recently read the excellent book from Douglas Crockford espousing about the good parts of JavaScript. However, what I saw in my new role did not conform too closely if at all to the Crockford way of thinking (which I happen to largely share).

First off, the code that exists here is of a very high quality and is well organised, but I have started to realise that there are a number of things I would look to do differently if we could re-write all the code from scratch.

The code has become fairly tightly coupled over time with one object requiring and expecting another object to exist and the second object creating a back reference to the first. There are a number of circular references if one looks through the various objects closely enough.

References to objects are being passed around freely and there is little control being exercised over how values should be accessed and a distinct lack of singletons being used when I believe they should be.

This leads to a very large API surface area. By this I mean that there are a large number of methods that each object needs to expose and a large number of object references being passed around when a smaller API with singletons where appropriate would be simpler.

The combination of the above two things leads to a problem. If you want to rebuild all or part of an object, it becomes more difficult as the objects have very little private code. If an object exposes just a few methods and properties as its API, and retains the rest of its working as private internals, it becomes much easier and simpler to re-write or add to it.

This is a JavaScript application which undergoes constant change by multiple people. Whilst this is good, it does mean that there are more and more objects with wider and wider surface areas. I personally believe that this will lead to the need for a complete re-write of large parts of the application sooner.

This brings me on to my final point, a positive and a negative point. The application is harder to learn and takes longer to become confident with because of this large API surface area. I enjoy that though as I want the challenge!

JSquared 1.1

2008-07-12T14:31:00.002+01:00

It is with pleasure that earlier today I was able to announce the launch of JSquared 1.1. See the blog and the website for more details.

Not lovely...

2008-06-30T11:02:00.000+01:00

Well, its not often that I have had a bad word to say about Mozilla Firefox. However, for the second time in a week, I now do.

I have been aware of issues with the Mozilla implementation of eval for some time, but the latest exposure was news to me and seemingly many others.

Full details can be found here. There is no reliable way round that I can find as yet so I will continue along the assumption that in the JavaScript world, nothing is safe.

I will still use a module pattern (as I have discussed before in a previous post) and I will still call "private" members private. I will also continue to discourage the use of evil eval.

Douglas Crockford has a few things to say about Firefox in general and had his own comments about this latest issue.

I am deeply disappointed frankly. Firefox 3 ruined my week last week (well, truthfully, Firebug was as much to blame) and now this. I suppose its nice to see that other browser vendors make mistakes!

Lovely...

2008-06-29T01:22:00.001+01:00

This is a lovely little tool.

There is nothing else one can really say about it!

Firefox 3

2008-06-24T08:00:00.000+01:00

Well, it has been a good few days now that I have been running the release version of Firefox 3 and I thought I would share some of my experiences - both positive and negative.

First off, I like the interface updates, the "awesome bar" and the speed improvements. I have been very impressed with its stability as well.

However, I have found difficulty using a number of plugins and in particular Firebug. This is simply unacceptable. I have tried using a number of different versions of Firebug but to no avail - all were slow and often crashed Firefox.

Whilst this has proven to be just about acceptable for working at home on things such as JSquared, at work it has proven utterly useless and I have downgraded to Firefox 2 and Firebug 1.05. The improvement in performance of Firebug was immense.

How are you finding Firefox 3 and Firebug? Have you found a combination that works for you?

My JavaScript patterns

2008-06-09T22:57:00.002+01:00

Since posting about my JavaScript "rules", I have had a number of requests to expand on the patterns I use for developing my JavaScript objects.

I use two main patterns, a singleton pattern and a constructor pattern. A singleton is an object which will have only one instance within an application. A constructor is a function which when invoked with the new keyword will create an object based on its definition. These objects are known as instances.

Constructor Pattern
A constructor pattern is something which JavaScript has native support for. Douglas Crockford has previously talked about this pattern at length.

function EventHandler() {
    //constructor
 
    //private members
    var registeredEvents = [];
 
    //public methods
    this.registerHandler = function(func) {
        if (typeof func === "function") {
            registeredEvents.push(func);
        }
    }
    this.fire = function() {
        for (var i = registeredEvents.length-1; i >= 0; i--) {
            registeredEvents[i]();
        }
    }
}

A constructor is simply a function which defines various members and contains its own variables and indeed other functions. You can also define constructor logic with a series of statements which do not declare methods or private variables or functions.

Its a fairly simple pattern and it is just as easy to use. To declare a new instance of this constructor, the code is simply this:

var myEventHandler = new eventHandler();

Singleton Pattern
My aim with a singleton is to have a highly readable object formation pattern which allows for private members and the exposure of a public interface. The syntax also must ensure that only one instance of the singleton can exist though of course there is nothing to stop the object being inherited from.

I also wanted the pattern to look similar to the constructor pattern above. This should make it easier to code and maintain.

For this example, I am using a simplified version of an object in JSquared. JSquared makes extensive use of this pattern as much of the library is built up from singleton objects. The object I am using here is the cookies object. For details on how to use this within an application of your own, look out for a post on the JSquared blog.

var cookies = new (function() {
    //private members
    var cookies = {};
 
    //constructor
    //get the current set of cookies
    var currentCookies = document.cookie.split(";");
    var cookie;
    //loop through current cookies and add their values to the cookies collection
    for (var i = currentCookies.length - 1; i >= 0; i--) {
        cookie = currentCookies[i].split("=");
        if (cookie.length >= 2) {
            cookies[cookie[0]] = cookie[1];
        }
    }
 
    //public methods
    this.set = function(name, value, expiration) {
        document.cookie = name + "=" + value + ";expires=" + expiration + ";path=/";
        cookies[name] = value;
    }
    this.get = function(name) {
        return cookies[name];
    }
    this.delete = function(name) {
        this.set(name, "", -1);
        delete cookies[name];
    }
});

You will I am sure notice how similar this singleton pattern is to the constructor pattern above. The major difference is that the singleton pattern created the constructor as an anonymous function and then invoked an instance of that anonymous function immediately.

Just like when creating a new instance of a constructor, an object defined as per the constructor function will automatically be returned from the invocation. So in the example above, the variable cookies will contain the singleton.

The syntax may look odd, but it has proven itself very resilient and extremely effective. It allows for private members and functions, the public methods have access to those private members. It contains constructor logic and of course parameters can be passed in to the constructor just like they could be in the constructor pattern shown above.

As I seem to often say, its as simple as that!

My JavaScript "rules"

2008-05-27T21:05:00.000+01:00

In my day to day life, I see a lot of JavaScript code. I see a lot of code written by others and a lot of code which I have written in the past. As I look back over my own code and my coding style over the last 2 years or so, it is easy to see how far I have come and how much better my code is now.

None of this is meant to suggest that it cannot be improved. Nor am I saying that it is even that good! But, I thought it might be useful to talk about some of the ideas I have employed. These are my JavaScript "rules". I try to apply them in everything that I do:

1. Be unobtrusive
This is an absolutely imperative and key rule. Unobtrusive JavaScript code is easier to read, easier to write and is encapsulated within a JavaScript layer in your application. Writing unobtrusive code means having no JavaScript in the markup of your documents. Make use of browser events (onLoad, DOMContentLoaded etc) to apply the JavaScript enhancements to your pages. Use ID's and if necessary classes to pick DOM nodes from the document to work with.

2. Name your spaces
Namespaces make for much friendlier JavaScript. If nothing else, a namespace will stop you polluting the global scope of the document. I always have one root namespace for an application and then other namespaces off that to define the functionally different regions of your application. Always group similar functionality. If for example you have a bunch of objects which are used for handling forms and form validation, group them all under a common namespace. Creating a namespace is as easy as creating an object. Here is an example of creating a root namespace and 2 sub-namespaces:

var Nortools = {};
Nortools.Login = {};
Nortools.Forms = {};

3. Cry over spilt milk
I always encapsulate functionality within relevant objects and namespaces. Dont let that functionality spill out of the object or the namespace. Use private members in objects to hide the secrets of an object and strengthen your code. This will prevent your application from being changed or interfered with in any way by other JavaScripts on the page. I use self executing functions to create completely closed and hidden objects, neatly encapsulating my code. It is even possible to have private members on the prototype of a constructor using this technique:

var myConstructor = function() {};
myConstructor.prototype = new (function() {
    var myPrivateMember = "some value";
    this.getPrivateMemeber = function() {
        return myPrivateMember;
    }
});

This code may look odd, but the prototype of myConstructor is now a self creating singleton object which cannot be forced to give up its secrets. I use this technique for creating all singleton objects - its encapsulated!

4. Separate
I always separate the various types of code in my applications strictly. If I am dealing with data, I create a data layer to manage all that logic with as few public methods as possible. If I have business rules, the same applies. All presentation logic should also be self contained and independent of the data and the business rules which translate that data into objects which can then be displayed.

5. I object
Use objects and use them extensively. I never store any value within global scope and with everything in a well organised object model, you always know where things are. Use the singleton pattern above (or the many others which are just as good) to create singleton objects - an object that only has one instance.

6. JSON
JSON is extremely useful and powerful. I always use JSON for storing and transferring data in my applications. I also make extensive use of object notation for providing options to my objects. Passing in a JSON object to a constructor can be much easier than handling optional parameters. This is one method for handling optional parameters:

var myConstructor = function(param1, param2, param3) {
    param1 = param1 || "defaultValue";
    param2 = param2 || "defaultValue";
    param3 = param3 || "defaultValue";
};
var myInstance = new myConstructor( "value", null, "value" );

With this method, on creating an instance, I have to know which parameter is which and what order they are in. Its also slightly clumsy looking.

My preferred method is:

var myConstructor = function(options) {
    var param1 = options.param1 || "defaultValue";
    var param2 = options.param2 || "defaultValue";
    var param3 = options.param3 || "defaultValue";
};
var myInstance = new myConstructor( {
    param2: "value", 
    param3: "value"
} );

Much neater and I find it much easier to understand and read.

7. Be a detective
I always try to code defensively. I dont want errors to even be possible in my code. To this end, I always want to detect whether the operation I am about to perform is possible. Sometimes this means checking my own objects for a feature, sometimes a built in object. This is much more effective than user agent sniffing for browser features. Not only do I not have to know what each specific browser supports, but I also do not have to keep changing my code each time there is a new version of a browser. It makes my code future proof!

if (document.getElementById) { //check the browser supports getElementById
    var myElement = document.getElementById("myElement");
    if (myElement) { //check an element was found
        //perform some action
    }
}

8. Lets go native
Always use native functionality when its there. Its the fastest method. If you want to have a getElementsByClassName function in your application, check if the browser already has it built in and use that method if it is there. Replacing it will only make your application slower.

9. Delegation's what you need
Events are very important when building web applications. But adding event handlers to lots of nodes can be bad for performance and lead to management overheads. If for instance you have a list of items and clicking on an item in the list performs an action, consider adding the click event to the parent of the list items and using a delegation pattern to handle the event. For a more detailed explanation see this excellent article.

10. Get organised
I always try to organise my code well. It is vital during a build phase of a project to be well organised. I only ever put one object or constructor in a JavaScript file and I name the file accordingly. If the full path (taking into account namespaces etc) to my object is MyApplication.ApplicationSection.ObjectName, then I will name the file MyApplication.ApplicationSection.ObjectName.js. In a large application, my folder structure will represent the namespace hierarchy as well.

Choose a coding style for your application and stick to it. I have my own coding style with naming conventions etc, and I always stick to it. It makes the code more consistent and easier to read and understand.

Comment code wherever it is needed to help understand why the code does what it does. Dont comment code when the comments will not add to the understanding of the code.

11. Dont panic
Writing JavaScript is hard. Writing web applications is harder still. Dont panic. Help is at hand. Use a library.

JSquared 1.1 Beta 1

2008-05-24T23:17:00.004+01:00

Just a quick note to point you to information regarding the release of JSquared 1.1 Beta 1.

Usability and accessibility

2008-05-14T21:45:00.004+01:00

In recent weeks I have been spending much of my time at work thinking about usability, commenting on it and trying to convince others of my ideas.

This thought has been focussed almost solely around two tasks. The first of these was an interesting proposition - to demonstrate that projects previously completed using Flash could be built using JavaScript. As a useful by-product, I have been able to make some more use of JSquared and particularly my alpha build of FXSquared!

There were two particular products that I have been looking at, the first of which was a finance tool for Fiat. I spent 2 days working on this task and as such was only able to make part of this tool.

I started by building the dials which are the main control for the tool. This involved building a number of animations and some simple interactions. I then worked on the panel which flashes as the values change. Amazingly, in only two days, I was able to match all the functionality of the dials and get the values updating in the panel and get the panel to flash.

Accessibility was not an important consideration however, when reviewing the work I was able to complete, the markup I had written was valid and semantic and the product fully accessible. It was certainly no less usable than the Flash, and due to the keyboard being able to control the tools, it was perhaps more usable. It was accessible and worked without CSS and could be made to work without JavaScript very simply. It was a triumph.

The other product I worked on, was in a similar vein and was a similar success.

The original project manager on the Fiat project could not tell the difference between the two products and it was entirely cross-browser.

The point I am making here is that by writing the tool using semantic HTML and progressively enhancing the code with CSS and JavaScript, I was able to make something more accessible and more usable all at the same time.

My second key experience was joining a project that had a significant development effort behind it already. I was asked to point out where I thought the product was not usable. I found myself pointing out 8 areas that I had issue with. When I took a step back and looked at these comments I realised how each of them could also have appeared on a list of changes to make the product more accessible!

These experiences have really driven home for me how closely linked accessibility and usability are and how investing in one will inevitably be investment in the other. What a great selling point for spending more effort on these vital areas that are sometimes overlooked by clients.

The JSquared blog

2008-05-11T18:39:00.002+01:00

I am excited to announce the launch of the JSquared blog - http://blog.j-squared.info/.

From now on, this blog will discuss general web interface development issues whilst the JSquared blog will discuss features of JSquared and provide news of updates etc. You will see the latest few items in the left pane of this blog as well for convenience.

I have copied over the relevant posts to the JSquared blog. Please let me know if you have any comments.

JSquared update

2008-05-08T23:08:00.002+01:00

First of all, apologies for the sparsity of posts in the last few weeks. Its been a busy couple of weeks, but there is plenty to discuss. More of that to come in the next week or so.

The big news however is that JSquared has a new home - www.j-squared.info. There will be a major update to the website to coincide with the release of JSquared 1.1 in late June or early July. JSquared will have its own blog, freeing this blog for non-JSquared related topics generally. More on that in time to come.

An update on the progress of the goals for release 1.1:

JSquared Testing Platform
Using JSUnit, I have had much success testing JSquared. I have about 20% code coverage in the core library so far. My aim is still to have full coverage of the core library for version 1.1

Documentation
Using JSDocs, I have documented around 40% of the core library and I am getting close to a full API reference. This will be available along with a quick start guide for JSquared 1.1

FXSquared
The core FX library is complete. It is based on plugins and I am working on two plugins. I have been using the FX library for a few weeks now and it is nearly ready for release. It will be released with JSquared 1.1

IE 8 Beta Support
There has been some work on general compatibility updates and JSquared continues to improve. It is unlikely that JSquared 1.1 will be fully tested and working on any beta platform, but there will be compatibility updates to help with IE 8 and Firefox 3 support as well as improved Opera 9.5 support.

I hope you are as excited as I am by these updates and new developments. JSquared work continues at a good pace (despite protests from my wife) and I am hoping to increase the usage of the library over the remainder of the year.

Just to keep you all excited, Chris Heilmann gave a talk at AKQA last week and he has posted about it.

Enhancements to CSS

2008-04-27T23:49:00.003+01:00

This post presents an interesting idea, that of CSS variables. On the surface, this could be a brilliant idea, though there are some potential flaws.

Firstly, there is the issue of redefinition - if a variable is defined and then redefined. This is particularly pertinent if the variable has been used before it is redefined.

Then there is the issue of CSS injected via JavaScript. The final issue I will raise about this is browser support.

Browser support is an issue which is close to my heart and about which I feel strongly. I firmly believe that with progressive enhancement, sensible design and tolerance of some differences between browsers from the client, a website can be made to support multiple browsers with minimal effort.

New innovations are fantastic and should be encouraged, but changes in the CSS specs can cause issues. We cannot start using this sort of new feature until a major proportion of users are accessing your website with a browser which supports the new feature.

So, what can we do about this? It is hard to reconcile the need for general cross-browser support and the desire for improvements and more features in the underlying specifications we use to build websites.

As I see it, there are a number of things that can be done. Firstly, we can educate our clients that it is ok for there to be differences. Secondly, we could build websites in "the classic manner" and also include the CSS style rules introduced by updates to the specification - but this may not work that successfully for obvious reasons.

As always, us interface developers will generally overcome these issues with a combination of techniques based on the principles of building to web standards and that of progressive enhancement.

What do you think we can do to overcome these issues? How can we bring about changes and enhancements as wide ranging as CSS variables without compromising the installed base of users who do not support new features and who can take many years to upgrade?

When perfect is not perfect

2008-04-23T17:17:00.005+01:00

I must recommend this post by Marcus Alexander. He moves the argument against pixel perfection - which I have already talked about in a previous post - forwards.

It is my belief that achieving cross browser pixel perfection across a wide range of different browsers costs a project a disproportionate amount of effort and distracts interface developers from the truly important aspects of a website which should be perfect. I am talking here about minor differences, generally related to the rendering of standard elements - form fields for instance.

We should be aiming for valid markup, high quality well organised CSS and unobtrusive object oriented JavaScript - we should never have JavaScript errors. We should be working towards best practices and we should be implementing web standards wherever possible.

We should be listening to what our clients want and delivering a high quality solution which successfully addresses the problems the client wants solved.

However, we should not be expected to work around every single minor layout issue or to change system defaults. Users understand how their default system controls work, they are inherently usable and accessible. A user also does not care if a bit of a text is a few pixels out.

Lets take an example from another aspect of life - television. Television producers will ensure that their program is executed perfectly with a fantastic script, perfect camera work, flawless sound etc. However, if you are viewing a program being broadcast in wide screen on a non-wide screen television, you will miss part of the picture - the edges are removed to fit onto the television. This is a good example as the producer can decide which part of the picture gets cut off.

I must re-iterate however, that it is vital to produce high quality work which conforms to industry best practices and is accessible to as many users as possible. There is a big difference between accessible to all users and perfect for all users.

As Marcus states, no end user of the website is going to be aware of small differences between browsers - and nor should they be. They will only be unhappy if the website does not operate or is so poorly laid out as to be unusable on their browser of choice.

I am not suggesting that anything will do. I am suggesting quite the opposite. We need to be perfect in most things. But as long as the differences are small, the basic site layout is not compromised and the full website is usable to all, achieving pixel perfection does not produce the returns its cost surely demands.

Asynchronous JavaScript Part 5 - The JSquared AJAX Object

2008-04-22T20:36:00.005+01:00

In my previous post in this series, I introduced some of my thoughts on AJAX. I will now go into detail as to how to use the JSquared AJAX object.

The AJAX object just like ADIJ is an instance based object. That is to say that for each AJAX request you wish to make, you create an instance of the object and then call a method on it to send the request. The same object can be reused or new instances can be created.

The AJAX object will require certain parameters to be provided and generally it is easiest to do so in the constructor, however, the object has methods for setting these values later.

Only one parameter is required and that is the URL the request is going to. The full list of parameters is:

URL - must be provided either in the constructor or using the setUrl method
method - the HTTP verb to be used for the request. Defaults to GET
onSuccess - the callback function if the request is successful
onFail - the callback function if the request fails
scope - the scope in which to run the onSuccess or onFail handler (the scope sets the value of this within the callback function). Defaults to the handler function itself
timeoutLength - the maximum time to wait for a server response to the request before timing out the request and calling the onFail handler. Defaults to 12 seconds
headers - an array of objects containing key and value pairs which are the additional headers to add to the request

Each of these parameters can be set once the object is created using a method.

To send the request, simply call the send method:

var myAjaxRequest = new J2.AJAX( {url: "myAJAXUrl.html"} );
myAjaxRequest.send();

The send method accepts an argument which is the string of data to add to the request. This argument is optional.

As you can clearly see, the parameters are passed into the constructor as a JavaScript object using object notation.

If you provide an onSuccess handler, that will be called if the request completes successfully and will have the AJAX object passed in as the first argument to the function. This will allow all the properties of the request to be accessed.

If the request should fail, the onFail handler will be called. The first argument passed to the fail handler is the AJAX object. The second argument will be the failure code. The code can then be examined by comparing it against the value of the AJAX failure codes object which looks as follows:

J2.AJAX.FailureCodes = {
    general: "xx1",
    unauthorised: 401,
    notFound: 404,
    timeout: 408,
    server: 500    
}

If you do not provide an onSuccess or onFail handler, then the object will simply do nothing - there will be no error shown.

Once again, I have to say that it is as simple as that. This is a really powerful but easy to use AJAX object.

This is the end of the series on Asynchronous JavaScript. I will be writing more about the other features of JSquared in the near future.

JSquared road map and update

2008-04-21T16:20:00.004+01:00

I have literally been swamped by a request for a road map for JSquared. In response, I have created this wiki page.

I have some ambitious plans for JSquared and it may not all be possible - much depends on how much my wife puts up with me working late into the night. But my aims are stated there.

I will be releasing periodic compatibility updates in between these major releases.

The single most requested feature for JSquared thus far is documentation and it is high on my priority list. I am intending on providing this as a set of object models output using JSDocs and an accompanying guide. Following that, I hope to be able to get a JSquared website up and running full of example code.

A set of unit tests and indeed a full testing platform for JSquared is also very high on the priority list and progress is being made on this. The intention for JSquared 1.1 is to get the core functions unit tested.

FXSquared is making good progress with a basic FX module ready for some heavy duty testing. FXSquared is built around plugins to allow for maximum flexibility.

IE 8 support continues to improve with each commit of the code. I expect IE 8 support to match that of all other browsers for JSquared 1.1

Please use this post or the wiki on the current JSquared home to comment on the road map, especially the form that the documentation should take.

CSS reset and pixel perfection

2008-04-17T10:02:00.005+01:00

This recent post from Jonathan Snook nicely sums up my feeling on CSS reset files.

I have often argued that CSS reset files will end up causing more problems than they solve. Indeed, I am not convinced they solve a real problem.

The problem seems to be that each browser I support does not apply the same default styling to some elements that I may use in my website.

The solution proposed by CSS reset files is to create a base line set of CSS rules which will on first inspection solve this problem. However, I am not sure I agree that the problem is as stated above.

I believe the problem is that each website I code looks and behaves differently and does not use the same set of default styles as other websites I have developed.

The solution I propose is resetting only the CSS styles I actually need in order to make the website look correct in as few styles as possible. Only then will I be interested in the difference between browsers. I would still use the * reset myself as I find that generally is useful and makes a fairly large difference when designing my CSS. I would not employ any more of a reset than that.

As an example, my website may not use any level 3 headings. In that instance, my CSS code will not try and select any 3rd level headings at all. If later during development I need to use a level 3 heading, I will use the tag and add the relevant CSS code. I have always employed this approach and it has so far never let me down.

For more details on my approach to structuring CSS, I suggest reading this post. Of course ideas change over time, but it is still relevant.

I always believe in code being as lightweight as possible, not purely for speed of download but for ease of maintenance and the retention of my own sanity!

The other point raised by the post I mention above is that of producing cross-browser pixel perfect layouts. This is a topic that probably deserves its own post if not a series of posts, however, I rarely strive for pixel perfection. I just do not believe it is that important any more. I would argue that users are becoming aware that websites will look very slightly different on different platforms. I definitely did not perfectly explain my position in my previous post about browser support so I will clarify it here.

In that post, for level 1 browsers (the only relevant browsers in this discussion) I state:

All features of the website are fully functional. All content is available. The web pages will match the designs provided completely. The web pages will look the same across all browsers at this level.

What I should have said was:

All features of the website are fully functional. All content is available. The web pages will match the designs provided completely with the exception of system entities such as form fields and rendered fonts which may cause a layout to differ slightly. The web pages will look the same across all browsers at this level within the constraints of the different rendering methods for each platform.

That more fully expresses how I feel about pixel perfection. Sometimes it can be done, sometimes it cannot. We should educate our clients that pixel perfection is not always important.

WOW - Seriously

2008-04-09T13:34:00.004+01:00

I saw this post on Ajaxian and could not resist posting it here myself.

It is truly quite awesome!

Super Mario in 14Kb of JavaScript

outline:0

2008-04-08T17:00:00.003+01:00

There is nothing more annoying for those who wish to navigate a website using the keyboard than the extensive use of outline:0 in CSS code. For a more detailed explanation of what this is and what it means, I suggest you read this blog post.

Although I luckily do not suffer from any form of disability and do not actually require any effort to be made by a web developer towards accessibility, I do like to browse using the keyboard on occasion and this can be a highly frustrating problem.

CSS reset files such as the one mentioned in the post can leave developers without a full understanding of the nuances of the platform they are developing for. It is at least in part for this reason that I dont use a CSS reset at all.

My message to all would be to not remove this extremely useful and built-in behavior but actually to enhance it. Try navigation the London 2012 website with the keyboard (a site I led the development on) to see how nice it is to have the outline behaviour enhanced rather than removed.

Documenting JSquared

2008-04-07T23:12:00.003+01:00

One of the biggest missing aspects from JSquared is documentation.

I have been looking at using an automated tool to build documentation from comments in the code (another thing which is currently lacking) and this is going to be a major push for me over the next 2 months.

I have almost settled on using JSDoc. I would be very thankful if the readers of this blog could give any thoughts on JSDoc or any alternatives that I should be looking at.

Thanks in advance.

Safari 3.1 and IE8 Beta 1 support in JSquared

2008-04-07T22:55:00.005+01:00

With the release of Safari 3.1 on PC and MAC, the handling of keyboard events has changed as detailed in this post on Ajaxian.

I am delighted to say that the auto filter object in JSquared 1.0 is fully compliant with Safari 3.1 and no changes to the code are required. This is the only object in JSquared with keyboard handling at present.

The big news recently though is the release of IE8 Beta 1. I am currently testing JSquared with this release and things are looking good. I expect there to be some minor changes to the code which will precipitate the release of a JSquared compatibility update. More news on this in the next few weeks.

Asynchronous JavaScript Part 4 - AJAX (a quick introduction)

2008-04-05T23:47:00.004+01:00

In the previous 3 parts of this series on asynchronous JavaScript, I have talked at length about ADIJ. I suggest starting at part 1 to catch up!

AJAX is a term which has been bastardised to describe any sort of interactive behaviour in a web page. A number of years ago, these interactions were known as dHTML (dynamic HTML). Neither AJAX nor dHTML perfectly describe these types of interactions, but I prefer the latter name.

AJAX to me should mean Asynchronous JavaScript and XML. This is not perfect as it is often the case that XML is not appropriate and sometimes JavaScript, JSON, HTML or even plain text is required instead. Nonetheless, the acronym AJAX still has one definite meaning to me!

For the purposes of this post and the remainder of this series I will use it to mean any form of asynchronous HTTP request whose response will be handled using JavaScript code whatever form that response takes.

AJAX is a very useful and powerful technique invented by Microsoft for Outlook Web Access and later adopted by other browser vendors. When used in a fairly light touch manner, AJAX techniques can give the user a greatly enhanced experience.

AJAX involves sending an HTTP request to a web server and getting a response asynchronously which is handled in JavaScript. This means more data can be requested from the server or passed to the server without the user seeing the web page refresh.

An asynchronous request happens in the background - it allows other operations to be performed whilst the HTTP cycle is completed. You provide a callback function to the AJAX object which is called once the HTTP cycle is complete. I wont go into more detail around implementation and what it all means as there are many excellent tutorials already written. The W3Schools has one of their own.

Using AJAX it is possible do things such as post a form or update the content of a web page without the user going through a page refresh cycle. This makes the web page seem more like an application and can make it better for users to interact with.

Of course, JSquared has an AJAX component which is extremely simple to use yet offers flexibility and power. In part 5 of this series, I will walk through the AJAX object and then discuss how to use it.

Future proofing

2008-04-03T08:56:00.003+01:00

With updates to some of the most popular and widely used browsers soon to appear - namely IE 8 and Firefox 3 - the question has to be posed about how and when to support them.

It is a fairly simple matter to test your websites in the new versions of these browsers as there are beta versions of both available, however, it can be very time-consuming to fix issues and clients can find it a bitter pill to swallow.

The biggest problem here is a lack of overall transparency about how and when these browsers will be released. This issue is much much greater where IE is concerned.

We know that Firefox is slated for a June release and it is likely that the automatic update system will offer users the new version. It is therefore reasonable to suppose that there will be a fairly rapid surge in the number of users for Firefox 3.

As far as IE is concerned, we cannot be sure of a release date or the mechanism by which the update will be delivered. It is possible that there will be a split between IE 7 and IE 8 users for some time until IE 8 is pushed through automatic updates as a high priority update. This in a way is what has happened with the IE 6 to IE 7 transition.

I think it is reasonable for an interface developer to support 2 versions of a popular web browser (perhaps at different levels of support), but I do not like the idea of having to support 3 versions at any level, particularly when one of those is IE 6!

So, the question is, what to do? I am unsure at the moment, though I am considering testing my websites in Firefox 3 as of now and attempting a good level of support. As far as IE 8 goes, if its IE 7 mode works well, then that is a very good reason to not support IE 8 until it is actually released.

If Microsoft released a road map with release dates for IE 8 and the version afterwards, then I could plan my browser support strategy much more easily. So come on Microsoft, talk to me....

Progressive degradation

2008-03-31T20:43:00.018+01:00

I should start this post with a disclaimer. I did not discover or invent this technique. It was suggested to me by a now ex-colleague, Marcus. He also does not like what I have named this technique. But you can make your own mind up.

We should by now all be aware of progressive enhancement, what it is and why to use it. Well, progressive degradation actually assists with progressive enhancement and in some ways turns the idea on its head to make life easier and simpler. Whenever I have employed progressive degradation, I have found things easier to develop and maintain.

Progressive enhancement generally involves writing high quality semantic markup and then layering onto that additional elements which do not in themselves add additional meaning but enhance the visual presentation of the content of a web page or make it easier and nicer to use.

Generally progressive enhancement will mean layering CSS on to the markup to make the web page look nice, and JavaScript to make the web page easier and nicer to use. Progressive degradation turns that idea on its head.

With progressive degradation, we still need high quality semantic markup. That is always the base. We are still going to layer CSS on to the markup to make the web page look nice. The big change is with the JavaScript.

Using progressive enhancement, we would write the CSS in such a way that if the user does not have a JavaScript enabled browser, the site works well and looks correct. If the user does have a JavaScript enabled browser, the JavaScript code itself would make changes to the way the CSS is applied (and perhaps to the markup as well) to give the web pages a slightly different look and additional behaviours.

Using progressive degradation, we apply the CSS to the markup in the assumption that the user has a JavaScript enabled browser. Let me just make that clear. We make the assumption that the user has JavaScript enabled within their browser.

So where is the magic? The trick is that we include an additional CSS file for those users who DO NOT have JavaScript enabled in their browser which will re-style the content to be usable without the JavaScript enhancements.

This technique is not suitable for all occasions, but when I have employed it within a website, I have found a way to use it for every enhanced element.

The major advantage of progressive degradation is that there is no page flicker as the content is altered by JavaScript code even when the JavaScript code is run on page load as the CSS code that is loaded with the page sets up the page for the JavaScript enhanced version from load.

Its an extremely simple technique to apply and the following code is all you need:

<noscript>
    <link rel="stylesheet" href="noscript.css" type="text/css" media="screen" />
</noscript>

As you can see, all that is involved is the addition of a CSS file inside noscript tags. Whilst this does make the markup for your web page invalid, I believe it is a small price to pay for the power it brings. To demonstrate that power, an example could be useful.

The example I will use is that of a form which will add an item to a list. Without JavaScript, the form will always be visible. With JavaScript, there will be an add button which when clicked will show the form. How the form submission is handled here is not important but one could use an AJAX request for those user agents which support it and a postback cycle for those which do not.

The 2 versions of this page element look as follows:

With JavaScript enabled:

Without JavaScipt enabled:

The markup is as follows:

<div id="ListContainer">
        <ul>
        <li>Item 1</li>
                <li>Item 2</li>
        </ul>
        <form action="page.html" method="post">
                <label for="NewItem" id="NewItemLabel">Add item</label>
                <input id="NewItem" type="text" />
                <input type="submit" id="SubmitForm" value="add" />
        </form>
</div>

The pertinent CSS for the purposes of this article is:

#NewItem, #SubmitForm {    display:none;
}

This CSS will hide the input field and the submit button.

The following (somewhat rough) JavaScript will make the progressive enhancement work so that when clicking on the label for the form field, the input field and submit button will show:

<script type="text/javascript">    window.onload = function() {
        document.getElementById("NewItemLabel").onclick = function() {
            this.style.display = "none";
            document.getElementById("NewItem").style.display = "block";
            document.getElementById("SubmitForm").style.display = "block";
        }
    }
</script>

So, we now have a working form module as described above. When the page loads, some elements are hidden - there is no flicker whilst the JavaScript kicks in on page load and hides the relevant elements as they are already hidden! Clicking on the label will hide the label and show the relevant elements.

Now for the progressive degradation:

<noscript>
    <style type="text/css">
        #NewItem, #SubmitForm {
            display:block;
        }
    </style>
</noscript>

And that is all there is to it. Without JavaScript enabled in the web browser, the user will see the complete form. With JavaScript enabled, the user gets an enhanced experience. If you re-read the last 2 sentences, you will notice how right it sounds and yet we are mixing the concepts of progressive enhancement with those of progressive degradation.

Of course we could take this example much further, writing some JavaScript to allow the user to return the page to its load state if they changed their mind and did not actually want to add another list item. We could write code to handle the form submission etc and all this would be progressive enhancement, but progressive enhancement made even easier by starting with the concept of progressive degradation.

The key to how progressive degradation makes this easier is that we know the non-JavaScript version of the page will work perfectly and we can add as much progressive enhancement as we like and concentrate on writing fantastic JavaScript to enable exciting but as always simple and light-touch enhancements to the web pages we build.

JSquared 1.0 released

2008-03-24T18:09:00.002Z

Just a quick note to point you to JSquared 1.0 which is now in release. Please feel free to feedback on your thoughts.

JSquared auto filter list

2008-02-18T14:12:00.005Z

One of the updated objects released with JSquared 1.0 beta 2 is the auto filter object. This is a powerful object for filtering lists and is proving useful in a variety of circumstances, not least the creation of auto complete drop down lists for instance for searching.

At present the object only handles static lists, but by the time JSquared 1.0 is in final release, it will support live lists and a host of further options. That is to say that you would be able to provide a JSquared ADIJ or JSquared AJAX object as the list of values and the auto filter object will use that object to retrieve the list of values each time it needs to perform a filter.

The object is designed to work with a text input field and to respond to key presses to perform a filter. Within this structure, it is quite configurable. Lets have a look into the object and how to use it.

To initiate the object, create an instance using the "new" keyword. The constructor of the object takes 3 parameters, the third of which is optional:

field - a reference to the DOM node which the auto filter object will respond to and work with
data - the list of items to filter as an Array
options - some options for how the object should perform

The options

objectMember - the array of data to filter can be an array of objects. If it is, the auto filter object needs to know which member on each object in the array contains the filter data. This option defines that.
minLength - the minimum number of characters to be entered into the text field before filtering starts. Defaults to 1.
hoverCssClass - the css class to add to the node which is hovered over (or selected) by the user once the filtered list is displayed
matchAnyCharacter - a boolean value which if true will match the characters entered into the text field against any character in the data list. If false (the default) it only matches from the start of the items in the data list

Events
In addition to these options, you can respond to various events. Pass in event handlers with the options as follows

onItemBound - fired when a matching item in the data list is found and bound to the document
onItemSelect - fired when the user selects an item from the filtered list
onFilteredListDraw - fired after the filtered list of items is added to the DOM tree

The first 2 events defined above run in the scope of the DOM node representing the relevant filtered list item. They both will get passed a parameter containing the original data for that list item. If the original data list was an array of objects, the whole object will get passed.

The third event defined above runs in the scope of the list of items.

The HTML
When the user enters a value into the field which is to support the filtered list, a list of matching items is added to the DOM immediately after the field. Assuming the value in the field is "value", this list will by default appear as follows:

<ul class="autoCompleteList">
    <li><strong>value</strong> 1</li>
    <li><strong>value</strong> 2</li>
    <li><strong>value</strong> 3</li>
</ul>

This HTML can be styled by CSS. The css class defined for the currently hovered over item (or "hover" by default) is added to the appropriate list item.

Selecting an Item
When the user selects an item either by clicking on the item in the displayed filtered list or by using the keyboard (up and down cursor keys to choose an item and enter to select it), the value of that item is written into the field.

That is pretty much all there is to it. Its quite simple really!

JSquared Packages

2008-02-18T14:09:00.002Z

With the release of JSquared beta 2, I have provided one file containing the full library which is also minified. This file weighs in at 29Kb! I would always recommend using JSquared in its componentized format, just including what you need at any time.

JSquared 1.0 Beta 2

2008-02-18T14:02:00.003Z

JSquared 1.0 Beta 2 has just gone live and is available for download now.

This version has a number of enhancements over beta 1, not least the deployment method! You can now upgrade from beta 1 to beta 2 by just replacing the old code with the new. I have also provided full versions of the library with all its components in one file in both compressed and uncompressed formats.

There have been a number of improvements and additions since beta 1:

Better DOMReady handling
Much faster "trim" method on strings
New image rollover object - back to the future!
Delegate handling pattern
New auto filtering object. Highly configurable.
A URL manager object for adding entries to the browser history and allowing bookmarking in an AJAX application
Loads of little bug fixes

For those who still want it, beta 1 is still available for download as well.

Keep an eye on this blog for more information about all the JSquared features. You should already know about ADIJ!

Lack of posts

2008-02-12T14:23:00.000Z

Apologies to all those avid readers out there for the recent lack of posts on this blog.

This is what happens when you are less than 3 weeks from being married!

I will attempt to complete my series on Asynchronous JavaScript techniques (only 3 more parts to go) before heading off to Thailand for 2 weeks for our honeymoon.

Roll on March 2nd...

HTML 5 and Web Standards

2008-02-04T16:58:00.002Z

With the recent publishing of the W3C HTML 5 Working Draft, and the debacle which is IE versioning through meta tags, I have been having some thoughts about web standards.

It so happens that I am not the only one! Molly E. Holzschlag has also been thinking. Whilst her thoughts are somewhat more drastic than mine, I felt it time to put forward my thoughts on the next generation of HTML on the web.

HTML 5 is a massive specification introducing many new tags and attributes of which without a doubt my favourite is the irrelevant attribute. I would personally be quite happy to wrap large parts of the spec in such a tag!

I believe strongly in simplification and I do not believe HTML 5 simplifies HTML. What I think we need is less not more. There is one very specific point which grates. HTML should enforce an XML syntax - tags should have to be closed and have to be well formed. HTML 5 allows unclosed tags and this to my mind is a step backwards. Indeed, I see the spec contains code a bit like this:

<dl>
      <dt>Radius: <dd> <meter min=0 max=20 value=12>12cm</meter>
<dt>Height: <dd><metermin=0max=10value=2>2cm</meter>
</dl>

This is some ugly stuff!

I believe HTML 5 should actually be XHTML 5 (or version 2 or whatever version you like!). It should contain a small set of semantic tags including paragraph, emphasis, lists, audio, video, anchors, images, divisions (or sections) amongst others, creating a small set of recognised tags with well defined default rendering for each. As an author, I should be allowed to create ANY OTHER TAG I LIKE as long as it is well formed XML. The default rendering for each unrecognised tag should be as an inline element and they should offer no semantic meaning.

The tags I "create" should be able to be styled through CSS and accessible as DOM nodes via JavaScript.

Its simple. Or is it too simple?

IE8 - Version Switching

2008-01-25T13:47:00.001Z

There has been much talk over the past few days about IE8 and its new concept of version targeting.

There is a lovely post by Robert Nyman where he considers an alternative. I agree with much of what he says.

My feelings on this matter do differ in some ways. I have a strong conviction that IE8 should render things as well as it can all the time. I wont object to the doctype switch - it has been around too long now - but there should be strong discouragement of its use.

I am well aware that for some the web will be "broken". But surely this is OK. It seems that browser vendors and especially Microsoft are helping those amateurs who think they can do web interface development. I have no problem with people building their own websites at all, but it is time to realise that writing good XHTML and CSS is not easy. Its time to put things right, have some short term pain but get that long term gain.

This combined with Robert's approach of standalone versions could make the world a better place. Tools for building websites "properly" will appear in time.

Just remember, XHTML and CSS are hard to do well, we want to encourage amateurs to have websites - everyone should be able to have a website - but its not easy.

Asynchronous JavaScript Part 3 - Using ADIJ

2008-01-25T10:32:00.001Z

In part 1 and part 2 of this series on asynchronous JavaScript techniques, I have introduced the ADIJ object. Now, I will demonstrate just how easy it is to use the object with an extremely simple code example.

varmyAdij = new J2.ADIJ( {
    URL: "/getADIJdata.json",
onSuccess: successHandler
} );
myAdij.send();

function successHandler(myAdij) {
varjsonData = myAdij.getResponseText();
    ....
}

In this example, I create a variable called myAdij which is set to a new instance of the ADIJ object. I pass an object literal of values into the constructor of the ADIJ object containing the URL which I wish to request and the success handler which will get called when the ADIJ object gets a response to this request.

I then call the send method which will send the request.

When the ADIJ object gets its response, successHandler will be called. It will be passed one argument which is a different form of the ADIJ object now containing a method getResponseText which will return the JSON object sent as the response to the ADIJ request.

Once successHandler had finished being executed, the original ADIJ object can be garbage collected by the browser assuming there are no other live references to it.

It is also possible to create and send the ADIJ request in one line of code and without assigning it to a variable. This can be useful in instances when the original ADIJ object will not be needed again.

new J2.ADIJ( {
    URL: "/getADIJdata.json",
    onSuccess: successHandler
} ).send();

function successHandler(myAdij) {
    var jsonData = myAdij.getResponseText();
    ....
}

Note that the send method is now called in line with the construction of the new ADIJ object.

It is as simple and easy as that! So go, play and enjoy and when this series returns, we will be discussing AJAX and particularly JSquared AJAX.

Structured CSS

2008-01-18T09:52:00.001Z

One of the most challenging aspects of starting a new project is deciding how to structure the CSS. Often, not all the designs are complete, and sometimes very few are done and things are not signed off etc. Therefore it is always important to have a structure which allows for quick and easy changes and even the retrospective coding of a style guide into the CSS.

I am personally not a fan of CSS resets such as Eric Meyer's but I do like to have flexibility and structure in my work.

Whilst I get some arguments from colleagues about my approach, those who work on projects with me have so far not had cause for complaint and have commented that my approach seems to work. The crux of it is that I like to do the majority of the CSS work up-front and do as little as possible as more and more pages are added into the site.

I still subscribe to the global reset:

* {
    margin: 0;
    padding: 0;
}

I then like to set all the defaults from scratch on the core elements: headers, tables, anchors, paragraphs, lists etc.

My other practice which causes discussion is my file structure. There are different ways of organising CSS files and some people like to take the one file approach where everything is put into one massive file. I cannot abide this approach - how can you find anything!? The answer is often that good commenting helps, but I don't think developers are very good at commenting well!

My other issue with the single CSS file is that for every page the user has to download every line of CSS and in a rich website, there can be a lot!

I prefer to separate the basic CSS into the following files:

global.css
All global styles including my mini-reset as above, basic styles for the common tags (lists, tables etc). Styling for global site elements.

typography.css
Basic typography styles - paragraphs, headers and text colouring for different elements. Anchor styles as well including hover styles etc.

forms.css
Basic form styling. I always insist upon forms looking very similar across the website so I can style them once.

navigation.css
All global navigation styles typically including primary and secondary navigation (tertiary if it is applicable), footer styles, any in page tabbed navigation etc

ie.css
Included for all IE versions 7 and lower through conditional comments.

ie6.css
Included for all IE versions 6 and lower through conditional comments.

Each of the above files would be included on every page of the website. I would then create further style sheets by section or template or functional usage depending on the website. I would normally not create a style sheet per page or per module, but I do normally create additional special style sheets for the website home page and for search results if it is different enough.

Within my style sheets I try and implement rules such that each section of CSS is commented eg:

/* Inbox styles */
table#Inbox {
    ....
}
....

I like to have the styles in a sensible order which is normally the same as the markup order. So styling for elements which are children of or appear after the table with ID Inbox would appear later in the CSS file.

And that's it. No magic, nothing too special, just a structure borne out of experience and specifically the experiencing of managing badly written CSS.

CSS is not easy, but a good approach can at least make it simple.

One special note - consistency of approach to CSS on a project is absolutely key until some decent development tools come along.

Asynchronous JavaScript Part 2 - The ADIJ Object

2008-01-09T17:26:00.001Z

In a previous post, I discussed what ADIJ is.

ADIJ is now open source and you can get ADIJ here.

This is part 2 of my series on asynchronous JavaScript and today I will focus on how the ADIJ object itself works. In part 3 of this series, I will discuss how to use the object. Later in the series, I will introduce my AJAX object which is also open source and available along with ADIJ. These 2 objects share a simple interface and so can be interchanged fairly easily.

How does ADIJ work?
Whilst answering this question, we must bear in mind that ADIJ is an asynchronous tool which ultimately will make an HTTP request and indirectly handle the response of that request. JavaScript is simply the intermediate layer which processes the HTTP response and passes that response back to the ADIJ object.

ADIJ is an instance based tool. You create instances of the ADIJ object and apply properties to that instance. Each ADIJ instance is given a unique ID which is used to identify each ADIJ object. This is most useful when handling responses.

The following properties can be applied to each ADIJ instance (and ultimately each request made):

URL - this is the URL which ADIJ will use for the src attribute of the script tag which will be injected into the document when the ADIJ request is sent. The response from this URL has to be JavaScript formed to work with ADIJ.
onSuccess - this is the function which will handle the response. It is similar to the handler for onReadyStateChange in an AJAX request.
scope (optional) - this defines the scope that the onSuccess handler will run within. Scope is a larger JavaScript topic which cannot be covered within this post. Suffice to say that if this optional property is supplied, it should be an object and defines the value of the this keyword in the onSuccess handler function.

Once you are ready to send your ADIJ request, call the send method. The ADIJ object will write out a script tag into the document which will look something like this:

<scripttype="text/javascript"src="MyADIJUrl.js?rid=ADIJ_1&uqid=1199900579224"></script>

ADIJ will add 2 items to the querystring of the request:

rid - this is the ADIJ request ID which the server will need to be aware of
uqid - this is a date and time stamp of when the request was sent. This is used to stop ADIJ requests being cached.

How does ADIJ process the response?
When the server gets an ADIJ request, it needs to respond with JavaScript. It is very important that the interface developer works closely with an application developer to ensure the server side of the application is setup to handle ADIJ correctly.

The final response to the onSuccess handler defined on the ADIJ object will be JSON, but the response from the server will be a function call which will look something like:

Tools.ADIJ.prototype.handleResponse( id, json );

Tools.ADIJ is the ADIJ object itself.
Tools.ADIJ.prototype.handleResponse is a function on the prototype of Tools.ADIJ
id is the ID of the ADIJ request as passed to the server in the querystring of the request. This ID is auto-generated by the ADIJ object and automatically appended to the specified URL for the ADIJ request
json is the JSON object to pass back to the onSuccess handler defined in the instance of the ADIJ object given the ID id

By this method, multiple ADIJ requests can be sent from and handled by the client side code with ease.

In part 3 of this series, I will show just how simple it is to write the JavaScript code to use ADIJ.

No $

2008-01-08T13:48:00.002Z

Over the past few months, I have been developing and testing my own JavaScript library. I am delighted to announce that JSquared is now open source software and available at Google Code.

I will be blogging about the features of the library over the coming few months. The library includes some asynchronous JavaScript tools and you can read part 1 of my series on asynchronous JavaScript.

Is CSS the ultimate expression of progressive enhancement?

2008-01-07T16:01:00.004Z

Following up on my previous post about progressive enhancement, I wish to pose the question:
Is CSS the ultimate expression of progressive enhancement?

To help us address the question, lets briefly remind ourselves that progressive enhancement is a technique whereby the way a web page operates is enhanced if the user agent being used supports certain features but if the user agent does not, then nothing is lost. The user can still see all content and use all features of the web page.

So, does this hold true of CSS? Well, given valid markup, I believe it does and I certainly believe it should.

That does not answer the question posed though. I am firmly of the opinion that the answer is yes. CSS is so powerful and so able to change the way a web page looks but without itself forming any part of the content or functionality of that web page, that I believe it must be the ultimate expression of progressive enhancement.

Do you agree? Do you disagree?

Asynchronous JavaScript Part 1 - ADIJ

2008-01-03T11:46:00.001Z

This is the first in a series of posts regarding asynchronous JavaScript techniques and tools.

In this edition, I will introduce ADIJ. I will ultimately provide code and examples for each of the tools I recommend using.

The What
Asynchronous DOM Injected JSON or ADIJ is what I have termed a fairly common technique found today for getting data from a server using JavaScript in an asynchronous fashion. This technique is more commonly known as the script tag hack.

The How
Its a very simple technique which involves simply adding a script tag with a valid src attribute to the DOM tree. When the script tag is added to the document, the browser will make a request to the URL specified in the src, and load the returned content which will be interpreted and executed immediately.

The Why
I have found ADIJ most useful thus far in mapping mashups. The data returned will normally be in JSON format and this is efficient for parsing and adding points to a map. But the technique can work very well for any public data which needs to be delivered asynchronously to the browser.

Any issues?
Any data returned using ADIJ can be intercepted and in theory, scripts can be injected into your page. However, I normally ensure that I only accept valid JSON containing Objects and Strings. I would never execute a function returned by this technique. This is not a major issue, but one to be aware of. Only ever use ADIJ for fully public data, never for secure data. Be aware that all cookies are provided when the request is made.

Why ADIJ?
ADIJ is more than just a silly name for the script tag hack. ADIJ is a helper object which can allow you to send multiple requests on demand and receive valid JSON data back with co-operation from the server.

Using ADIJ, you provide a handler function (similar to the callback in AJAX) which will receive the JSON data when the request completes successfully. The ADIJ object will manage your requests and handle all the responses for you, ultimately passing the response back to your specified handler function.

The ADIJ object provides a powerful first item in your asynchronous JavaScript toolkit.

In part 2 of this series I will go through the ADIJ object and provide an example.

Browser support

2007-12-18T17:50:00.001Z

This is an issue which crops up in one form or another on almost every project I have ever worked on. Its normally the project manager who will approach me and say in a sometimes off-handed way something like "I assume we will support this list of browsers (which someone gave me back in 2001)."

My usual answer is "No. We will support this standard support matrix."

I then proceed to hand the project manager something which at the time of writing includes the following:

Internet Explorer 6+
Firefox 1.5+ (all platforms)
Safari 2+ (all platforms)
Opera 9+ (all platforms)

This is all well and good, but the real purpose of this kind of browser support matrix is actually to fulfill some sort of contractual requirements with a client and to appease the project manager.

I also consider this matrix to be a testing guide for the testers of the website. Most testers are not completely familiar with ID concepts, and they need some help. I have seen testers using up to 20 different browsers and raising bugs if they are not all perfect. This is obviously very costly on the project - testing takes a long time and fixing the bugs is extremely tedious and often not really possible.

To get around this issues (and to help with dealing with the client who still happens to be using Ie5 on Windows 98) I normally talk in terms of graded support. At the time of writing, I use 2 level of support:

Level 1
All features of the website are fully functional. All content is available. The web pages will match the designs provided completely. The web pages will look the same across all browsers at this level.

Level 2
All features of the website are functional if only in a fall back manner. All content is available. The web pages will largely match provided designs. The web pages may look slightly different between browsers at this level and those at other levels.

This provides a sensible testing structure as well as fulfilling all other requirements. If an awkward browser (such as IE 5.5) absolutely must be supported, we have the option of only offering level 2 support - the key here is that all content will be available.

In reality, browser support only matters for the visual and enhanced behavior of the website. If the website is built using the principles of progressive enhancement, then all user agents, all browsers should be able to access the website in some form or another. It is the content of the website which is most important, and using well structured, semantic HTML should ensure that this content is available to all.

The message here is that agreeing a sensible browser support matrix is very important in both a business sense and for testing. It is also imperative to adhere to the agreed support levels, but the principles of progressive enhancement, particularly starting with well formed, semantic HTML will ensure the widest possible support even if that is with a degraded experience.

Its our job

2007-12-14T11:19:00.001Z

I cant agree with absolutely everything in this article, but it certainly does make some very good points - accessibility should not be an inconvenience!

Progressive enhancement

2007-12-13T22:17:00.005Z

In the world of interface development today there is one technique to which I fully subscribe without hesitation or regret - progressive enhancement. It is for me the guiding principle behind almost all of the work I do.

Progressive enhancement can mean a number of things but in a nutshell, it involves taking a base line for a web page and layering on enhancements which are not required in order to use the web page or to understand the content of the web page. If the browser being used can understand these additional layers, then they will be applied and will enhance the way the web page operates or looks.

The base line is the HTML code of the web page. The HTML code defines the content of the web page. The HTML of course should be semantic and where possible valid. In order to define the content of the page, the HTML code should be well structured, for example having a sensible header nesting order.

Given semantic and well written HTML, the content of a web page should be accessible to any user agent. The job of progressive enhancement is to layer on some additional "features".

There are two main forms of progressive enhancement used presently. It is in fact possible to argue that there are 3 or possibly 4 forms (and maybe even more), but the two main forms are CSS and JavaScript (I would perhaps also say that images are another main type of progressive enhancement - with well written alt attributes on image tags, the images are not necessary to understand the page).

So what do these forms of progressive enhancement do and how do they work?

CSS
The way the web page looks is defined by the CSS code used to style the page. The stylesheet uses a series of selectors to select elements defined in the HTML code and apply one or more of a wide variety of styling effects. These include applying borders, text colours, background colours and images, sizes and many many others.

JavaScript
Any behaviours not handled by the browser by default can be added through the use of JavaScript. JavaScript is a programming language with a C type syntax which is the language of choice for the web. The JavaScript code can perform a massively wide variety of different operations. These range from simple form validation scripts to whole applications such as Google Maps.

Progressive enhancement gives us a very powerful structure to building web pages. Using this technique, we create by default a separation between code for content, visual style and behavior. We are compelled to consider the implication of our enhancements and to make visual and behavioural aspects of the web page just that, enhancements and not requirements.

What will the page be like to use if the user agent does not support CSS? How will the core functions of the page operate without JavaScript enabled in the browser? By considering these questions, we are forced to write better HTML. In fact we are forced also to write better CSS and JavaScript. Everything needs to be considered carefully to ensure the separation of code remains and that the web page will be usable without the enhancements being available.

Not every web page can be progressively enhanced. In that instance, the appropriate alternative is a fallback version. Try browsing to Google Maps with JavaScript disabled in your browser and you will be taken to a page which will work without JavaScript. Not all fallbacks are this drastic, but a fallback allows the principle of progressive enhancement to be applied even in those few cases when the effort involved in using this approach is prohibitive.

The vast and overwhelming majority of the time, progressive enhancement makes writing a web page easier. The code will be better, cleaner and more maintainable. The web page more accessible and inclusive. The interface developer can be happy with a job well done!

What is Interface Development

2007-12-12T16:28:00.004Z

This is a very very good question. I often get asked what Interface Development really is (other than the obvious answer). Many people will know it as front end development. But its easier to answer the question in the form of a skill set.

I consider the core skills for a Web Interface Developer (or ID) to be:
HTML
CSS
JavaScript
User Agents
Accessibility

So what do these terms mean?

HTML
Fairly self-explanatory really. But an ID should know about HTML and XHTML in all its different forms. That is every widely supported doctype around.

CSS
Also self-explanatory. Everything up to CSS 2.1 is useful at this time.

JavaScript
Another one of those obvious ones. This is not to say that all IDs should be expert in JavaScript, but all IDs should have a good working knowledge

User Agents
This is less obvious. But I think an ID should know all about the most common browsers in use in the market today. How we define common is perhaps not a subject for this post, but once you have decided what is common, an ID should be able to write code to be compatible for all of them and should be able to understand their foibles and quirks

Accessibility
Well here is something that is a bit more contentious! IDs should ultimately be versed in best practice. Accessibility is a large subject and deserves many posts all of its own, but suffice to say that knowing what the WCAG say is not enough. Understanding best practice and why some approaches are good and others bad is far more useful.

So this is what an ID is. Its what we preach and what we practice and these are the topics that this blog will discuss. Enjoy.