Coding Horror covers some general criticism of Javascript libraries reminiscent of a few criticsisms I eluded to in previous posts such as “Javascript: The Quickening” and “Yahoo’s YUI Drag and Drop Module”. I think it could be stretched to other languages as well however as javascript has been a focus of mine recently (and many others) I thought I would explore some frustrations with working with the YUI library (as well as some other libraries) I have had recently.

Firstly, a point in reference to the Coding Horror post. The veneer of documentation can be a trap. The YUI library has more documentation than most, including API documentation, general overview documentation, cheat sheets and many examples. All of that and seasoned OOP javascript developers can still find it quite difficult to use parts of it for work more complicated than the basic examples provided in the documentation. I am interested in exploring why this is.

I find that many examples are often not coded to a standard that would stand up to much scrutiny except somehow examples seem to be exempt from quality control. Procedural code seems to be generally preferred ‘to keep things short’ and they use short cuts such as inlining everything in your HTML which ignores the real issues that go beyond stitching a few API calls one after the other.

The more complex issues in using libraries to solve complex problems are ignored. Trying to get javascript libraries in particular, playing nice with other code can be difficult. Controlling when the code is called and when things occur are complex issues however looking at any Prototype examples you may think that randomly pasting script blocks throughout your code is a sane thing to do.

Another issue I find YUI and most other JS libraries have is not all files clearly state which other files they are dependant on. This appears to be because such documentation is not uniformly enforced across the library (This is a feature of single author libraries as well, I find).

With Javascript unable to natively define explicit dependancies it is more likely to fail with an obscure error or worse still run but incorrectly. It is a time-consuming practice to work through finding all files it may need from the library and all assets it may be relying on (CSS, images etc.). And generally nothing works at all intended until you get it just right… Javascript in particular is often dependant on the order of the includes as well.

To my mind, dependancy tracking is a key facility of documentation whether it be derived from package names or calls to ‘include’ type functions (see my earlier post for the blurred line between documentation and code).

The namespacing efforts of YUI and Dojo; and Dojo introducing linkers and the ability to dynamically include required scripts we may see this improve but until more mature solutions exist we are doomed to some very frustrating hacking – contributing to the mug’s game that is web development at the moment (a topic for a separate post).

The line between code and documentation is blurring with the introduction of regimented documentation standards. In PHP reflection (and likely other languages as well) you can use reflection to programmatically access documentation blocks meaning you *could* make code dependant on information in your doc comments! Scary!

More scary is that I discovered this via a colleague who was considering using this. You could argue it conforms to the DRY principle because we were looking to add more strict control of return types implemented in methods that are derived from an interface we defined. This would require us to redefine information already part of our doc comments should we proceed without the reflection API.

For now we have elected not to proceed because it violates the rule of least surprise. Developers do not expect edits to comments affecting code conditionals and thus our effort to enforce correct use of interfaces could backfire causing exceptions in classes implementing our defined interfaces.

At some later date when the trend has continued and there is no line between code and API documentation or at such point we are confident our unit testing will prevent deployment of exceptions due to incorrect documentation we may reconsider this approach.

There have been philanthropists in javascript development since the language was concieved by Brendan Eich. A few that I can point to as having provided tools and inspiration along my path in web development: Mike Foster and his excellent x library (and it predecessor) which just worked and added some bling to projects of a few years ago; Brent Ashley and the jsrs library code and examples which opened my eyes to a new form of optimisation I could use in the web applications I built; PPK for the never-ending resource that is quirksmode… I am sure you all could name others that facilitated your own web application careers – feel free to add to this article in the comments.

In more recent “web 2.0″ times it was the success of Sam Stephenson’s Prototype, defined by its syntactic sugar which reminded the web development community at large of the dual functional and OOP natures of Javascript (invigorating in the face of the millions of custom procedural functions that previously ran the web). This has driven the current increase in client-side scripting interest. Of course Prototype was also helped in part to the libraries which built on it such as Thomas Fuchs’ Scriptaculous and Open Rico and also those influenced by such as MooTools. I would argue that all this activity (and other developments) was itself fueled by the natural return to ascendancy of web development that was always imminent after the tech crash’s over-correction.

With exploration of Prototype (and Javascript in general) we also learned. We learned that messing with the Object.prototype is verboten and that there were better ways to include functionality than inlining everything. Ben Nolan’s Behaviour library demonstrated this best (well then, anyways, these days I now just include separate files which use the various selector functions in combination with the cross-browser Event Handler implementations found in each major library).

Mid-way through last year we were evaluating libraries, namely Prototype, Jquery, Dojo and YUI. YUI won out for a number of reasons. Jquery looked great but it wasn’t at version 1 yet and seemed to be changing on a weekly basis (for the better, but that was too much flux for a project destined for our end users). Prototype I had used in some of my demos but the documentation was sketchy and every example relied on inline script tags scattered through-out our templates. I trialled out Behaviour which was quite handy but some examples were not easily recreated when combined with Behaviour. We were also concerned that Prototype would not play well with others. We wanted to leave the door open to continue using other third-party libraries in the future.

Dojo looked awesome but again was low on useful documentation (They have much improved – in fact all libraries have, in this regard). The Dojo events package looked very cool with its AOP-style approach but I had reservations that it might add too much ramp-up time to our tight schedule.

YUI had a combination of API and example-driven documentation as well as coverage on all the key features we needed. Its namespace implementation was simple, allowing us to get in and comprehend their code quickly. Once undertaking the project we did find that the documentation could still have been much better, but such are the joys of open-source libraries and their documentation, right (php is an exception – the comments on the API pages was a stroke of genius)?

The last twelve months have seen Dean Edwards and John Resig and others team together to provide a cross-browser solution to detecting when the DOM content had completely loaded (at a time before assets such as images have completed downloading).

This month has seen Jack Slocum weigh in with faster DOM search functions, setting a new benchmark in the area that John Resig had previously thrown down the gauntlet. This sort of collective innovation is for the good of the community and is providing an accelerated environment of innovation. I don’t fully subscribe to information singularity as while I do think acceleration can be hyperbolic it will more likely form an ogilve, flattening at some point rather than continuing to approach infinite (there are, afterall, limits to our ability to process information and effeciently distribute it amongst the hive-mind that is the community that forms around any topic of learning).

Philosophic analysis of the phenomena aside I do think it is valuable to recognise the progress that has been made and the factors contributing it and encouraging everyone to continue providing and contributing to the environment that has allowed us all to flourish.

I’ve been using the mostly cool blogging firefox extension by performancing.com for at least 8 months now. There are a few irritations I have with the editor however for the most part these are issues I have with many formatted text editors out there (for instance when linking some text there is no obvious way to stop applying the link formatting – I always have to apply links last to get around this) so I am forgiving on these matters.

What I occured on Friday though was more than irritating, it cost me a detailed post. I was linking for somewhere to paste the links I was collecting for pasting on text once I finished drafting my post. I remembered a ‘Notes’ tab in the Performancing editor and thought I might be able to post it there. That would be conveniant. I saw two example “Notes” in there and clicked on one to see where it would let me input my Note. The text in the main editor was replaced with the text from the Note. Neat! I thought, I can switch between my draft and my notes right here in the editor! Now, how to switch back to my draft? 30 minutes of hunting around the interface and the forums brought me to the slow realisation that my work of earlier in the day was lost.

Why name something destructive with the innocuous title of “Notes”? Why not warn of non-obvious, destructive behaviour? The irony is that I am now using this feature to protect me from an event like this – I just have to remember to click ‘Save as Note’ first or suffer a similar event. I am, of course, now in the market for a good blog editor which will combine well with my web browser research on a single screen (for when I am using the laptop free of my second screen).

My silver lining is that events like these help create a stronger usability movement.

A new version of my original post is on its way – its taken a few days to build up to retyping it.

I finally got started on some script to make IE handle firebug debug calls (console.debug etc.) gracefully and to display what it could when I read that a new (and apparently much changed) version was soon to be available.

Then when I actually got around to downloading it I find that they now package firebug with a cross-browser javascript-only library. Including this in your development environment by including the ‘Firebug Lite’ script in your pages presumably works like my script by defining a console object and providing the same external interface to Firebug proper. This then allows you to test in IE without IE choking on undefined functions such as console.debug() calls.

I should have written this code ages ago as I would have saved time in not accidentally checking in Firebug calls which broke IE testing for QA. I am glad they have addressed this (even though I lost an afternoon writing some redundant code) and I am also really impressed with the latest version of Firebug.

I think it might be time to include a build step in my project to allow me to remove Firebug debug calls from production code (as well as compress our css/js)

If you haven’t already – grab a beta copy of Firebug 1.0 Beta

I have been signing up to all sorts of web2.0 tools looking for a way to leverage my list of feeds. Many tools come close but have yet to offer quite the functionality with the level of completeness I have been after.

Matt Cutts, on commenting about the new Google customised search features, had this insight to share…

When I played with the first version, I wanted to avoid the standard stuff
where you plug in 1-2 sites and get a custom search engine that isn’t
blood-pounding-ly exciting (”Oh, a search box, and it searches. Great.”). So
what I did was take my feeds (I was using Bloglines at the time) and exported it
as an OPML file. Running a command like
cat export.opml | grep "title="
| cut -d'"' -f6 | grep -v '^$' | sort | uniq
was enough to get the
blog urls that I was reading (not the feed urls), and I threw those urls into
the custom search engine.

And just like that, *BOOM* I had a search engine that
covered 70+ blogs in the search/SEO industry. If I searched for [bug], it would
return search engine bugs, not bugs in general. OPML-import was so much fun that
the Co-op folks promised to support it (I know that importing from Bloglines
works; importing from Google Reader might still need a tweak to the OPML
parsing). It’s nice that every blogger can have a custom search engine that is
centered around their interests.

Smart guy, cuts straight through the gloss to a key use of this functionality. Hopefully they support a regular OPML import/sync from a fixed url (say a public newsgator OPML file…) so I can keep an engine up to date based purely on my web development blogs.

Combine that with certain del.icio.us links and now I have a massive information resource minus the majority of noise (you see I am not in the habit of bookmarking splogs and the like…).

In the mean time my dummy spit over that post still has me looking at other engines… A suggestion from a commenter got me back looking at snap.com. I’ve gotta say – its actually a joy to use! A recommend giving it a shot, its got liberal use of web2.0 features but in ways that really aid usability. The best feature by far being keyboard support.

Robert Nyman wrote recently about the difficulty to get buy-in for accessible web pages. His article speaks to a greater issue however of the difficulty for organisations to address the detail of generating quality. I define quality to mean not only those aspects of a products finish that benefit an end-user but also those that benefit those that support and maintain a product.

The strategic decision makers often talk to short-term benefits as reasons
for taking short-cuts on quality. Sometimes I think the Google Offline Spider’s Archive maybe handy in settling once and for all how the short term thinking had lead to issues such as poor stickiness or excessive bug reports or that high exit rate from page x.

I have had various QA tester and QA Manager roles in my past (it was even my entry into my current company!). From this vantage point it often feels like the last thing anyone wants outside QA is a quality product.

Things aren’t generally that bad – of course once you experience different roles around the workplace you do realise that quality is being achieved despite conflicting incentives. I’ve done in-the-trenches development (I continue to moonlight with this every once in awhile to satisfy my hobby interest and to make sure I maintain a reasonable understanding of the work at hand), content direction and production, marketing and various managerial roles as well.

Developers and content producers generally are striving for quality in the face of deadlines, distractions and the conservative decisions of their managers (spending time on both sides of the fence I acknowledge that sometimes those decisions represent excellent risk management and othertimes fear/laziness of disturbing the status quo). Managers deal with distraction, the competing needs of other managers, the goals of the organisation and that estimating accurately is HARD.

In my post detail versus perspective I had discussed the trap of fiddling with details whilst the truly valuable contribution to the success of your organisation languished. This is not in conflict with achieving quality in your work as often quality (attention to detail, usability, accessibility, reusability, literate code – whatever it is that provides ongoing benefit inside and out of your ogranisation) is that truly valuable contribution.

So how do we all ensure we contribute to an overall environment of quality? There is no way to guarantee it but you can certainly do more than ‘your little bit’. To understand and facilitate others in their efforts to contribute to the quality of the product of your workplace is important. If QA request consideration to their workload and throughput then give it. In fact support any of your domain experts when they are suffering friction from decision makers when trying to address issues within their domain. And evangelize the aspects of quality that are key to your own domain succeeding.

Over time it is natural for any marketing department and development team/s to drift apart. I suspect it is often due to differing personality types amongst the decision makers – in development you often have ex-developers in management positions, in marketing you have a wide array of PR professionals and the more dangerous variety, marketing degree graduates ignoring everything they learnt in their marketing degree.

Many web developers have some marketing experience in their past – many web roles are about executing on marketing strategies – many more are multi-skilling producer/marketer/developer type roles (I’ve had experience in both).

Developers work well as marketers for certain tasks – particularly the measurable ones. Internet PR, SEO, SEM these are all tasks often undertaken by developers when there is no other implementers available. We also do some tasks terribly. Sometimes over-estimating clients and prospects. Sometimes under – we forget that they are not us.

A good marketer has been trained in all the tools and techniques to find out who the target market is. I often get frustrated when marketing lose sight of this and spend too much time engaged in PR activities (but maybe that will be the topic of a future post).

What is often overlooked is that the worst situation for a company is for communication breakdown between tech and marketing. Take the new site that one of the big 4 australian banks, ANZ, launched – designmycard.com.au. It went live with a TVC campaign – the purpose of which was to drive consumers to their website. The website is no doubt the hard work of some creative individuals as are the TVCs. The key point of connection is the URL. The ads use the more modern looking URL sans the www. So why the hell hasn’t anyone configured the webserver to resolve said domain??

As someone with a web development background I spotted the gaffe straight away and adjusted the URL I typed in the URL with the www added (after checking my internet connectivity and a host of other common issues that cause a site not to load…). But I can guarantee that the majority of people who saw the ads tonite and tried the URL did not. As Seth Godin says, ‘no one cares about you’ (that’s you ANZ).

The implementation fault is obviously on the technical side – its webserver configuration most likely. But the real fault is that a TVC campaign was launched directing people to a non-existant address. This sort of oversight I’d wager sits on the other side of the fence.

But the point of this post is not to gloat. I say wander down to your marketing manager’s pod or office and get reacquainted.

Is anyone else tempted to put an ID on every freakin HTML element so that they are easy to reference? As I write routines to locate my elements within the div an event fired on I wonder to myself – “Just what would happen if someone whacked some extra DIV tags in this template?”.

Most of our code is PHP and we put some effort into making stuff that wont fall over for our clients. I am not used to writing code which I know will break when inevitable changes are made. But what are the alternatives? Put IDs everywhere? I’d have to generate the IDs because most of my pages are dynamic. Should I attempt to write more forgiving routines that keeping searching until I find that img tag I am looking for? This brings in issues of performance and why the hell am I spending so much time writing routines to find elements on a page that I put there in the first place, just to frickin switch an image or fade some div!?

Awhile back I likened working with Javascript to an addiction. I think that is still apt and I am starting to see that the act is also fairly futile. Maybe I am just weary from a long project but maybe I am seeing the truth of this thing. I think maybe we are all blinded by the pretty moving, pulsating, bevelled corner DIVs and not being realistic about the disproportionate effort required to get a dubious gain in usability.

If you have some suggested reading for me which may ease my pain then drop me a comment and join the illustrious crowd of Dustin Diaz and some guy named John who have commented on my blog.

We’ve been working with YUI recently. There is plenty that is good about it – we were originally drawn to it because of its obvious amounts of documentation, examples, blog and the backing of a big, big company in Yahoo! (and their suite of javascript luminaries).

Its been quietish on the YUI front, recently however, there was a point upgrade, but I do think we over-estimated Yahoo!’s ability to keep the library bubbling along. I think there is a difference between the priority Yahoo! places on YUI when compared to dedicated library development efforts (prototype, jquery, dojo all come to mind).

The documentation in use comes fairly short of acceptable. I will try to elucidate on why because I don’t really want this post to be anything other than constructive. Afterall, YUI did end up achieving what we were after however I felt we probably ended spending too much time trying to learn the library and the quirks of its construction.

As part of the documentation an overview or survey of the library would have been great – many features we found too late and spent time retrofitting onto code we had already written. This process helped fix browser compatibility issues but ideally we would never have come across these if the prefered ways for changing styles and retrieving elements were highlighted. Further browser compatibilty issues could have been prevented with some more defensive programming within the library – there is definitely wrong input that you can put into the API which will yield js errors from within the library.

Other frustrations included examples which appeared to have their own custom additions to the library with little or no explanation eg. the DDPlayer objects in the Drag and Drop modules.

I also found the DD module had a few too many assumptions when it came to its events.

Drag events can work in a simple point mode (ie. the target is wherever the mouse pointer is) and intersect mode (events such as DragEnter, DragOver and DragOut get an array of targets which you can use to determine which you want to interact with). Intersect mode is, I believe, a preferred method because the drag item becomes the mouse cursor. This means users will expect interactions to occur with the item rather than the mouse cursor.

The problem I found was that the library did not pass me the true list of items I was over. It appears that it was caching items already found by earlier events. This was frustrating because now I need to mirror this caching in my objects and am therefore needing to peer behind the curtain to see how the library works.

Early on we found a bizarre class notation which was used in some of the YUI modules. It puzzled as to why use this over the more standard javascript approaches to defining objects (a js strength/weakness is its flexibility). It appeared to be used where you might usually use a static class or the singleton pattern in other languages.

Thankfully, only an hour after a colleague and I puzzled over this Dustin Diaz posted an article which illuminated it fully for us. The exposure of many Yahoo! staff via their blogs continues to be a compelling part of the support network for this library (and our saviour twice now!).

I think that YUI needs the continued support of Yahoo! to continue the good base that has been established. The library has clearly facilitated some great developments for Yahoo! with some very impressive product releases of late. The gains are measureable but the potential future gains from continuing to support and improve the library are also very real. Don’t do it for us – do it for your own developers. And then put it out to us