Guy's Blog Blog from September, 2008

There seems to be vast numbers of people mistaking Google's new chrome browser as something that's designed for the open internet. It's not, it's designed to kill MSIE on corporate networks...

I've already made a post similar to this in response to Charles' blog on Chrome where, like many developers he's compared it to Safari and Firefox and wondered why Google bothered releasing Chrome. And why on earth would they make the initial release Windows only?

I'd argue that Chrome has no intention of making it big on the open internet or competing with Safari or Firefox. It's not remotely intended for home use, although I'm sure vast numbers of people will use it at home as it's such a clean and simple interface.

Google have pumped vast amounts of money in to Firefox and have worked closely with the Webkit developers to make the open internet a better, more standards compliant and open place. Every day, more and more sites drop support for MSIE6 because there's just no point in supporting such an ancient browser. As I recently found out, Internet Explorer 6 is actually older than East Timor! IE6 was 7 years old as of last month - that's a whole geological era in Internet terms!

Yet, despite the fact that it's the most despised and broken browser in existence, there are still vast numbers of people using it - on corporate networks.

This fact hurts the entire web industry - instead of fixing bugs, adding requested features and improving usability and performance, every single web developer spends around 60% of each project hacking and bodging their site or web app work in MSIE6. Don't even get me started on the self-destructive tendencies that web developers have to prolong their own pain by supporting MSIE6.

So, it's no surprise that Google, like the rest of us, want to see IE6 die pretty damn quick.

And like the rest of us, they've realised that's just not going to happen in the next decade because corporate intranets depend on IE6 - they are built for IE6 from the ground up and won't work on any other browser, including later versions of IE. Worse still, later versions of IE, including version 8, are still woefully inadequate compared to all other web browsers.

Corporate networks are stuck with IE6 for their existing browser based apps. And now they're stuck in a really hard place - Microsoft are going to make MSIE8 (currently in beta 2 release) "standards" compliant by default, guaranteeing that it won't work with all those old crappy corporate intranets.

To make matters even worse, corporates are ill served by the alternatives:

• Firefox is way to extensible and customisable to be safe to use on a corporate network
• Safari is too "Apple"
• Opera isn't enterprisey enough
• And they won't even have heard of all the other browsers out there

From a corporate IT managers' perspective, they have two choices:

• Don't upgrade anything - stick on Windows 2000 / NT and IE6 for the rest of time. But they can't do this - their old machines are breaking and being replaced with newer machines that mandate the use of Vista, etc.
• Upgrade everything - in one fail swoop. Again, this just can't be done - the disruption alone would kill the business. To make matters worse, they'd have to install Vista! Thanks Microsoft!

They can't run multiple versions of MSIE alongside each other - it's just way too painful a task and would confuse the hell out of end users.

No matter what option they choose, they're going to die a slow painful death. That's why they're putting off making a decision either way - it's the only way to prolong their survival.

Then, suddenly, just as large corporates are realising just how shafted they are thanks to their utter dependance on MSIE6 and chums, Google releases a seemingly pointless browser called Chrome.

Only I think it's far from pointless. Let's look at some facts:

• It has no feature bloat - it's trimmed back to the bear essentials, making it easier to maintain and reducing it's memory footprint to a level that's friendly for older systems
• It's super simple to use - there's no cluttered button bars and menus for users to learn, very little tech support and no training required!
• End users would struggle to break it - it's not like there are vast swathes of plugins and extensions for them to install.
• It's not marketed as a web browser - it's marketed as an interface to web applications, a web desktop.
• It's not trying to compete with MSIE, it sits along side it. It's a whole new branch of thinking for corporate intranets that allows them to install and transition to modern web apps that Microsoft struggle to understand.
• It works with all the shiny new web apps that enterprises are desperate to move, freeing them of the museum of bad software they currently have to live with.
• The multi-process architecture and JS engine performance is stable enough to allow mainstream applications to be ported to the browser
• There's a nice cartoon explaining the browser in corporate terms - any IT manager reading it will be ticking boxes and rubbing their hands together with a big smile on their face.

I bet there's even a hefty set of lock-down options to restrict which sites, plugins, etc., the browser can access.

It's perfect for a corporate environment!

So, whilst Microsoft work on their next shipment of fail - MSIE 8, including useless features like web slices rather than critical features like, oh, I don't know, a browser that actually works FFS! - Google have literally sidestepped them and offered large corporates a killer solution and a path to freedom.

Nice one Google, I think you've just provided an extremely viable solution to the MSIE problem!

I always keep an eye out for new JS libraries that might be useful in our products, so I was obviously interested in an article on Ajaxian about some upcoming libraries...

The Ajaxian article links to 10 Promising JavaScript Frameworks on Six Revisions website - unfortunately, none of them really float my boat although there are a few that get worthy mentions...

SproutCore

SproutCore markets itself as:

SproutCore is designed to make desktop-like apps for the web. Imagine the possibilities by sampling some demo apps.

When I first heard of this library, and what it evolved from, I just had to scratch my head and wonder "Why?". However, I decided to take another look at it now some time has passed... I looked at the various demos and wasn't particularly bowled over by the UI - any desktop app, and vast numbers of web apps, have far better UI. That being said, they do seem to have one of the more solid panel layouts I've seen.

I dug a little further and found that SproutCore is not just JS, there's a back-end component that you need to install on the server. Sorry, not for me., it's just too damn messy and I have to change the way I do things in order to use it.

Spry

Spry, from Adobe, markets itself as:

The Spry framework for Ajax is a JavaScript library that provides easy-to-use yet powerful Ajax functionality that allows designers to build pages that provide a richer experience for their users. It is designed to take the complexity out of Ajax and allow designers to easily create Web 2.0 pages.

Spry is split in to: Spry Data, Spry Widgets and Spry Effects. It's obviously got lot of good documentation and Adobe behind it so it will make ground in corporate circles. But I still don't really see the benefit of it other than "yet another framework" to choose from? Do we really need Spry when things like jQuery exist?

The Data part is good, but nothing special compared to jQuery.

The widgets are again are pretty solid, and possibly more stable than jQuery UI, however they seem lacklustre, especially considering this is from Adobe. I was expecting MUCH better.

The effects are pretty slick and possibly a bit more fluid than those in some other libraries. Again, nothing special compared to jQuery and if you want truly awesome effects go look at UIZE.

I get the distinct feeling that Spry is just part of a process for getting developers in to Flex development: Want better data connections, widgets and effects? Use Flex! - yup, I think Spry is more of a marketing tool than anything else.

JavaScriptMVC

JavaScriptMVC is a library that describes itself as:

JavaScriptMVC is a framework that brings methods to the madness of JavaScript development. It guides you to successfully completed projects by promoting best practices, maintainability, and convention over configuration.

It's the first time I've encountered this one so I spent a bit of time digging in to it...

Their website has the world's most annoying chat panel that pops-up over the page, on every page view, even if you're not remotely interested in it! This sort of UI disaster instantly made me worry about this framework. I'm looking for information, not chat rooms!

Anyway, the library itself is pretty solid. However it reminds me of ExtJS (but without the glossy finish) in that it really does expect to take over the whole web page - this isn't the sort of thing that you'd want to try embedding in an existing web app.

So, if you want to create full-page web apps that have a feel of a Windows desktop app, JavaScriptMVC is worth a look. I think ExtJS is probably the better option if you have cash to throw at a project, otherwise JavaScriptMVC is a good free alternative as is Cappuccino.

It should be noted, however, that frameworks that require you to adapt to their way of working, can turn around and kill you. It's all too easy to assume the framework does everything you want and then get 90% of the way though a big project and hit an insurmountable brick wall that you never recover from. You have been warned!

qooxdoo

qooxdoo (WTF?) markets itself as:

qooxdoo is a comprehensive and innovative Ajax application framework. Leveraging object-oriented JavaScript allows developers to build impressive cross-browser applications. No HTML, CSS nor DOM knowledge is needed.

No. No, no, no, no, NO! Avoid like the plague! That's all I have to say on this library.

midori

Ah, midori... It markets itself as:

JavaScript is nice, but it can be a lot nicer. midori does exactly that without making you relearn things.

This library is a bit like jQuery without the plugins. It does many of the same things as jQuery - the obligatory selectors and effects are included - but jQuery does them much better IMHO.

I really can't see the benefit of this library in comparison to jQuery - jQuery can easily be stripped down to make it much smaller than midori and jQuery does so much more.

Archetype JavaScript Framework

Archetype JavaScript Framework is another library I'd not heard of before - it markets itself as:

Archetype is a structural JavaScript Framework. It is designed to provide a framework for JavaScript and Ajax application that ables developers to use JS for heavy clientside developments.

Hrm... I was already carefully stepping away, backwards, from this library. In fact, I started stepping away when I saw the lengthy and drab name of the library.

I read on and found this page which just struck me with horror - this library is designed to create a JavaScript Zoo! By the time I got to this page - where they show how it eases development - the nail was in the coffin, this library is going in completely the wrong direction.

Picture it this way: Archetype will encourage you to make a big bloaty enterprise application... in the web browser! Nooooooooooo! Cats and dogs living together! Human sacrifice! Run away! Abandon all hope!

Really, if you let this anywhere near a project, please quit web development and go and become a goat herder or something.

June Framework

June Framework - yet another library I'd not heard of, hopefully it won't be as bad as Archetype! It markets itself as:

JUNE is a javascript library inspired from the Core library published by Kevin Yank and Cameron Adams in their Simply JavaScript book. In its initial form, the Core library didn't offer too much except basic DOM manipulation using the Object literal notation. I liked that, and because at that time I was looking for a library (having a similar structure and not wanting to use Prototype or JQuery) to help me building some of my projects, I decided to extend it so it will better fit my requirements.

Hrm. Ok. I kept reading down the page, looking at code samples and eventually realised that this library is, in my view, pointless. I'll explain why later.

But what really put the nail in the coffin was that JUNE commits the worst imaginable sin: It puts all sorts of crappy methods and properties on core javascript objects such as Array and Object. Do not pass GO! Do not collect £200 GBP. Go directly to JAIL! JUNE is fired for gross misconduct and crimes against javascript!

UIZE

UIZE is another framework I've not heard of and it kind of jumps out and slaps you in the face. It markets itself as:

You can call it an "Ajax Framework", an "Ajax Toolkit", a "JavaScript Framework", a "JavaScript API", a "JavaScript Toolkit", a "JavaScript Toolbox"... whatever you like! We call it the The UIZE JavaScript Framework (or just "UIZE" for short).

Oh no, wait, it's...

UIZE is an object oriented JavaScript framework for creating more effective user interfaces in your Web content and Web-based applications and services. UIZE is open source. UIZE is free to use (distributed under the terms of the GNU General Public License). UIZE is in active development, and is used on a high profile, consumer facing, e-commerce Web site.

Ok, so it's free to use but takes away your freedoms (GNU license) and it hopes to do all sorts of things but nobody is quite sure what or why. This one was going to take a while to work out...

Let's start with the easy bit - it's got one of the snazziest effects libraries I've seen to-date. Quite how useful those would be in a business product, I'm not sure, but I still thought they were pretty awesome. Unlike almost every other effects library I've looked at (with the exception of script.aculo.us which I no longer use) it doesn't suffer from occasional judders at the start of an effect and on top of that it has some of the most unique effects I've ever seen in a JS library.

As I continued to look through their site, examining code examples and the plethora of demos, I came to the following conclusions:

• It's some pretty awesome JS coding
• Lots of cool UI things, but I couldn't really see myself using any of them
• It's GPL so this whole post is academic anyway

The library seems to have a split personality - on the one hand it looks like a bunch of coders are showing off all the crazy cool things they can do and on the other they have things like an extensive coding style guide that makes it feel quite business like.

I'm really lost for words. I'm going to keep an eye on this library to see how it evolves over the next year or so as it has me intrigued.

SimpleJS

SimpleJS is what June Framework and midori should have been. I've seen it before and think it has a future. It describes itself as:

SimpleJS is a simple and light javascript library which proposes functions ready to use to make the the exploitation of ajax easier. First developed for the beginners and the small projects, SimpleJS is a free library which can't be compared with Prototype or other professional framework.

And it does exactly what it says on the tin! Look how small the files are:

• simple.js : simpleJs base library (5ko)
• simpleajax.js : ajax functions (6ko)
• simpleacco.js : accordion effects (1 ko)
• simpleslish.js : easy create Slide Show (2ko)

While this library wouldn't be useful for our plugins (because Confluence has jQuery built in anyway so we might as well use it), I think of all the 10 libraries reviewed by Six Revisions SimpleJS is the one that actually differentiates itself from the crowd and has a clearly defined use.

If you're writing a small web app or web site and need to just add a sprinkling of functionality, this library is ideal.

Fleegix.js

Fleegix.js is a library I'd not heard of before, which describes itself as:

Fleegix.js provides an extremely lightweight, cross-browser set of JavaScript tools for building dynamic Web-app UIs.

Hrm, sounds good... until you realise that uncompressed it's only half the size of jQuery and compressed it's practically the same size! Uhm, how does that make this a lightweight library?

By the time I got to the build instructions explaining what you need to do with Ruby, I must admit I'd given up on the library. It does less than jQuery and in a less pleasing manner. I just don't see the point.

Summary

Use jQuery, unless you need ultra-light footprint in which case use SimpleJS.

MooTools, not reviewed here, is also worth a look. It's like a modern-day prototype + script.aculo.us and from a developer perspective it's pretty powerful. It'll be around for a very long time.

DOMAssistant, also not reviewed here, is another library to keep an eye on - it's arguably faster and smaller than jQuery, but is perhaps more "niche". I think it'll still be around for a long time.

ExtJS, mentioned but not reviewed on this page, is arguably the best library for creating full-page desktop-like applications in the browser. But be warned, it forces you to code within a framework and can turn around and bite you!

Spry is also worth a look if you're heavily in to Adobe stuff, but struggle to see a future for it compared to jQuery. I guess it'll end up in Adobe apps like Dreamweaver, but with the huge and growing popularity (and simplicity) of jQuery even that probably isn't enough to guarantee its future.

UIZE is just barking mad. I don't know whether it'll just fizzle out or turn in to something that's truly useful, so keep an eye on it. It's arguably the craziest JavaScript project I've ever seen.

Another upcoming library is Cappuccino - I've really not looked in to this one but it looks like a solid alternative to things like ExtJS and JavaScriptMVC.

As for all the other libraries on this page, death and obscurity awaits them. If you're thinking of creating a new library, avoid stepping on jQuery's toes because you've got virtually no chance!

Compare to jQuery

Reviewing this list of upcoming JavaScript libraries has made me realise just how amazing jQuery is in terms of the features it packs in to a relatively small file size.

jQuery doesn't try to turn JavaScript in to some other language or impose a rigid framework upon me - I can just use it where I see fit to make life simpler.

Contrast to SproutCore, JavaScriptMVC, qooxdoo, Archetype JavaScript Framework, ExtJS

jQuery has a staggering array of plugins, all written with a fairly high degree of consistency - if jQuery doesn't do something out the box I can likely find a plugin that does or write my own.

Contrast to the other libraries, pretty much all of them, which have awful plugin architecture or no plugin architecture.

jQuery can be stripped down to almost nothing - all the selectors and other features are actually implemented using jQuery's plugin framework. If you need to shrink it's file size, it's trivial to do.

Compare to libraries such as midori and JUNE which claim to be small but aren't. Only SimpleJS actually achieves this goal better than jQuery.

jQuery is completely namespaced - it doesn't pollute core JavaScript objects and the only thing it puts on the global scope are $ and jQuery variables - and even those can be removed with .noConflict(true). It's clean and tidy!

Contrast to things like prototype, script.aculo.us and JUNE that pollute things on purpose!

If you've not tried jQuery, I'd highly recommend it. Some people find it odd at first but after a while they simply can't imagine web development without it - and for good reason.

Ok, time for me to get back to work...

Anyone who follows my blog will know that I've not been a fan of NatWest bank, however in recent months I've seen some subtle changes that have really turned things around...

Things were pretty terrible - we could never get in touch with our bank manager, online banking was pathetic and getting anything done was nigh on impossible without a 2 hour trip (of which at least 30 mins would be wasted waiting for them to find out who our manager was that day) to their main Warrington branch.

Then, out of nowhere, I got a letter from our new account manager. Account managers at NatWest tend to change jobs very regularly and nobody ever seems to know who the current manager is, so even getting this letter was an improvement as, for the first time in months, we finally new who our account manager was.

But it got better. He came out to see us and I went though all the pain we'd had, in particular never being able to get in touch with our account manager. He solved this by handing me a tiny piece of paper - his business card. For the first time ever we could contact our manager by direct phone number, mobile and... EMAIL! YES, EMAIL. That's right, the bank had discovered the modern age.

I can't quite stress just how massive an improvement being able to email your bank manager is. At any time of day or night I can fire off a question or instruction (anything involving money needs more verification than just an email, obviously) and to my amazement the bank manager responds within a day or two and actually gets stuff done!

This one factor alone drastically improved the service offered by the bank, bringing it practically to the same level as HSBC in terms of responsiveness and avoidance of wasteful 2 hour trips to the main branch.

Then they landed this one on us:

You'll notice we've made a few changes to improve our online banking facility. For example, you will now be able to view up to 6 years worth of account statement and transaction history. To view a statement, simply visit the 'Statement' section.

(Emphasis mine)

OMFG! Excuse my language, but that is a fucking awesome improvement! It's been one of my biggest gripes that online banking couldn't show long-term history of an account, and they've just gone and solved that issue way beyond my wildest expectations!

I don't know of any other bank in the UK that offers more than 6 months, yet alone 6 YEARS, of online statement review. That brings NatWest online banking in to close competition with PayPal, although they've still got a massive way to go before achieving the standards set by PayPal, but they've at least entered the modern age.

I've still got some gripes with NatWest and our other bank, HSBC, but I'm really pleased at the recent improvements made by both of them. It finally feels like banks in the UK are waking up to the importance of making customers happy or, at the very least, taking a more modern approach to the service they offer.

So, here's something I thought I'd never say: Great work NatWest!

With such a flurry of important news about potato related trivia, I just had to blog about spuds...

Interesting facts:

1. I do not want to fire a potato gun up my nose. (in reply to suggestion from Emma Rush)
2. Adaptavist's Theme Builder plugin is used on the official World Potato Atlas
3. Peru has a National Potato Day, 30th May, every year. And I missed it!
4. The UN have declared 2008 official Year of the Potato

Now, you can be assured of a good nights sleep knowing that vital information.

I'll be here all week.

EDIT: More important potato related facts, myths and trivia: http://putnam.k12.il.us/Potatoes.htm

And yes, I am about to start the 4-week-long brain numbing admin task that is year-end accounts.

My favourite IM client, Digsby, just got support for LinkedIn...

When I first read about LinkedIn support, I really couldn't work out why anyone would possibly want that - sure, I've got a LinkedIn account but why would I want my IM client to integrate with it?

Well, Digsby once again made me a happy bunny. It adds a "sys tray" icon (near the clock on the Windows "Start" bar) which when clicked displays all recent activity for my LinkedIn network.

When anything happens in my LinkedIn network I get a nice status message popping up to let me know.

And the icon in the sys tray shows me how many unread messages, invites and job applicants I have on LinkedIn.

All in all, it's just made LinkedIn vastly more useful for me.

As well as the LinkedIn support, they've reduced RAM consumption by about 75%, fixed over 3000 (yes, three THOUSAND) bug tickets and made connections to IM networks far more reliable.

Find out more at http://Digsby.com

One of the tasks that's been literally annihilating my time recently is our current review of all our legal contracts. Now they are nearing completion I took a look back over the work we've done on them and realised we've applied many web design techniques to them...

Back in January, we started working on a new set of contracts for our [Support] services which have been rapidly growing in popularity. If I'd known that I'd still be working on them to this very day, I'd HAVE RUN FOR THE HILLS SCREAMING!

What seemed like a fairly straightforward task on the surface quickly became a project of mammoth proportions and resulted in a complete overhaul of the way we approach our support services, sales process and all sorts of other things.

However, what I really want to discuss is the way we approached the SLA contract from a web design perspective...

Agile Development

The contract development and all online discussion related to it has taken place in our wiki, our Legal Extranet to be precise.

By using the wiki we were able to start with a rough draft and then quickly improve it whenever needed.

We've used the open source AutoWatch Plugin so that everyone who contributes is automatically added as a watcher of that page - when subsequent changes are made or comments added, they get an immediate email notification.

You might be wondering how I can call the process agile considering it's taken 8 months already. Well, the editing of the contract itself has been highly agile – it's the countless changes we've made to our support methodologies, sales processes and systems, whilst in active use by over 2000 customers, that's taken 8 months.

Version Control

Confluence's ability to review different versions of a document, in particular the ability to show me everything that changed since my last edit, became extremely important when the need arose to see how a clause had changed over time.

Semantic Markup

The document markup uses semantic HTML such as heading and text styles. This is by design - like all our contracts it will be available on our public website when it's finished.

In particular, the ability to mark insertions and deletions in Confluence is hugely useful – we'd often leave changes marked up in this way for a few versions of the document while people discussed them.

Accessibility

An immediate benefit of using semantic markup is that the contract will be accessible to users browsing with assistive devices such as screen readers.

But, as many a web developer has learnt, accessibility isn't just for individuals with disabilities, there are all sorts of other scenarios where making content accessible is highly desirable such as browser plugins that display the table of contents for a page based on headings.

The only area where Confluence didn't quite meet our accessibility requirements is that it's not possible to define which row/col headers a cell relates to, however with assistive technologies getting better all the time and the ability to export to other formats such as MS Word, we overlooked this minor irritation.

Usability

Contracts inevitably end up containing legalese or other unwanted verbosity and cruft. Our contracts were no exception.

Roughly 50% of our revisions to the contract have been due to us making clauses easier to read and understand and, recently, we've also been making architectural changes so that the majority of the clauses are set out in a logical and natural order where the "flow" of information is humanised.

Aesthetics

When someone mentions a legal contract, you don't instinctively think of aesthetics - however, we did. There are places in the contract where we've used shiny graphics to depict things like Service Availability - we also include the information in text form, but when it comes to making certain information really quick and easy to absorb you just can't beat a shiny graphic IMHO!

Aside: You know a contract is nearly ready for public consumption when the lead Java developer starts commenting on the text formatting for heading level 4.

User Testing

Throughout all key stages of development, we've released beta versions of the contract (and in some cases just excerpts) to key people who it will affect:

• In-house developers and support team
• Customers who use practically every product and service we offer
• Customers who only use our support service

There has also been a constant information flow about the effects the contract will have to all staff, but if you ask almost any member of staff they won't be aware of this...

As the contract has developed and it's interaction with all aspects of the business has become more fully understood, I've been checking over everything form our sales processes, accounts system, online documentation, master price list and support services to make sure everything fits together perfectly.

Aside: One day I'll try and write about our company-wide matrix where every single thing interacts in countless ways with everything else, but I'm afraid my brain will scamper out of my head and run towards the hills.

The feedback (whether directly requested or covertly obtained) has been essential in making the contract make sense to as many people as possible and has resulted in major structural changes to the contract over the past few weeks.

Exporting

As well as providing wiki markup and HTML versions, Confluence also lets us export to MS Word and PDF formats as well. With the recent release of the Office Connector and other export tools such as Scroll on the horizon, we feel confident that we've chosen the right format for our contract creation and deployment.

All in all, we've found that applying various web design techniques to the contract has helped us drastically improve the readability of the contract (considering how much information it is required to convey).

If you've not used a wiki for drafting legal documents yet, I highly recommend it...