One of the things that made me a proponent of tabbed browsing was that the myriad of browser instances which contained my random travails across the net hogged the space on my taskbar, rendering it useless.

At around the same time (in my adoption of it at least) windows started to group up instances of programs into single tasks on the taskbar and Mozilla browsers introduced tabs. This cleared up the clutter and the taskbar became useful again.

Since then I have some new frustrations that have evolved out of that shift in functionality.

Firefox hogs resources

I use Firefox because of its extensibility - I only run extensions that extend my browsing habits but because I run quite a few of them, Firefox’s memory footprint by late in the day is consuming 300-500 meg of memory.

Web-based applications are harder to get to, slower to switch to

Firefox is regularly tardy to respond, often busy undertaking loops for hundreds or thousands of Javascript loops which may appear to have equal priority. Windows is not great at managing multi-tasking either however I do think that it does take a more sophisticated approach than a browser’s internals.

This tardiness really frustrates me and creates friction for me getting to my core applications quickly enough.

I am not just browsing any more

It occurs to me that many of my Firefox tabs are not instances of browsing content but rather applications that I use either to do my job (web-based task systems, in-house utilities…) or to run my life (webmail, web-based calendar, contact manager…).

Applications should not be hidden amongst your browser tabs or competing for priority within a browser’s sub-system. They should have their own space, be easily accessible and be able to interact with other applications and your OS infrastructure (for example, notifications).

AIR, XULRunner to the rescue?

By making applications available in standalone, browser-based applications I think there is scope to bring our core applications back to surface rather than hiding them within the browser-space. Save that space for your research and other web meanderings.

Frameworks such as AIR  and XULRunner offer opportunities to rescue your core web-based applications from the fray.

My prefered editor for Javascript is Aptana. I put up with the occasional slow performance of the Eclipse Platform which underlies it (it seems to hate dealing with windows network shares and vpns) because the IDE is very well thought out and works with me rather than against me.

That Javascript has an IDE at all shows that it has matured much since the early days of its inception where it primarily validated web forms, generally badly. With maturity in a programming language comes other things such as documentation. The preferred method of documenting API information these days is the *doc family of specifications and Javascript, through the efforts of the people behind Aptana I believe, has ScriptDoc.

ScriptDoc support is integrated into Aptana and helps the IDE make more sense of the very flexible syntax that Javascript supports - I certainly don’t envy the Aptana teams’ task of programmatically wading through the sea of anonymous functions, literals, prototypes in order to facilitate their IDE’s syntax highlighting, autodocumentation and outline capabilities.

Reading through the forums on the ScriptDoc site and through the specification I can see there is room for a lot more growth and development of this specification.

Something that we have found in our own Javascript development at Hitwise that we feel would be a valuable addition to the specification would be the ability to explicitly declare what the value of ‘this’ would be for a given function (or more specifically, method where a function is part of an object prototype). I will explain my rationale.

One of the ‘quirks’ (from an OOP perspective, anyway) of JS which is exploited to (sometimes) good effect by many of the key libraries about these days is the mutable nature of the keyword ‘this’.

For example, events (depending on whether they are native or ones augmented by a framework such as YUI) will define ‘this’ to be something other than the object prototype that you may have attached your handler function to. This means that ‘this’ can have different properties within callbacks to every other function you have defined for an object and can be therefore confusing (particular to those with OOP experience in other languages).

Indeed YUI and likely each other major library even allows you to explicitly define what the scope will be - they do this using some tricky closure syntax - I will often use this functionality to redefine ‘this’ back to the instance of the object where my event handler is housed to give ready access to the objects properties.

Of course sometimes, if there aren’t many properties you need to access it can be more convenient to access the element where the event occured through ‘this’ or in other circumstances even access some other arbitrary object and it is this reason that you are likely to see variation in what ‘this’ actually is!

When looking at a function and its documentation, you want to readily know what the available variables in the function scope are set to. The parameters can be easily documented and documentation for this across languages is almost universal. You also know that certain globals may be available and of course ‘this’. And most times you even know what ‘this’’s properties will be.

But if you are writing a callback for an XHR call or an event handler then you can’t be sure what it will be. If you are calling an existing callback which may have dependancies it would be great to avoid looking at the code and go to the API documentation to see what the callback would like ‘this’ set to. You could achieve this by defining an additional parameter or a custom ‘@this’ comment definition for your function could save you or your colleagues time in the future and make your Javascript API docs easier to grok. Standardisation of such a property would allow IDE’s such as Aptana to use this information in its code insight functionality to inform you of this requirement as you write your call.

With the general level event-driven programming required in most web development these days this would be a welcome time-saver and reduce the mental switching required to determine what ‘this’ will be.

I am a proponent of tackling tasks which represent the maximum reward for the minimum effort. Why spend months focusing on 11 different things when 2 of them could substantially improve your product or your business proposition or your team’s effectiveness.

A couple of recent releases which have just caught the attention of slashdot.org (and now me) in linux land have struck me as being not necessarily effortless developments but in the face of their potential impact on Linux adoption, releases that deserve applause.

First up (and currently slashdotted it seems) is a windows installer for Debian. The other is also a windows installer for the ubuntu linux distro.

What does this mean? It means that two key reasons you delayed installing linux on your laptop or desktop just evaporated.

1. Partitions aren’t used apparently so risk of data loss for files already on your machine is greatly reduced.
2. The time spent learning how to install a distro, configure it to your liking and get it to a productive state dramatically decreases.

Live cds were the first step in wider adoption however my experience of them was mixed. A live cd have saved us on a number of occasions when working with sick machines. For use as a trial OS however I have found them to be slow. This may have been due to an old dvd drive more than anything else.

I’ve run a few installs of debian and redhat for development machines at home but found the time administrating them became prohibitively expensive as I reduced the amount of time I spent developing (as I increased general administration and project management responsibilities). Linux desktops have been progressing impressively and I find that my frustrations with ineffeciencies on my windows machine demand I try something else.

I applaud those who have championed, evangelised, developed, tested these two projects. You may have just created an upward-shift in the Linux adoption. It is time now for the various window managers and applications on Linux to prove themselves with their new-found audiences. I do agree with recent posts that disparity between linux applications user experience is a challenge which continues to affect uptake however could unifying tools which change the way people use their OS minimise the impact of such disunity?

I will be trialling Enso over the next 30 days so more on this to come…

Update: I came across a similar project that has been around longer. I am surprised it has not caught my attention earlier? Maybe evangelism is truly what is needed?

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).

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

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

It seems to run in cycles - the Ajax backlash - where seasoned developers can no longer bite their tongue on the Ajax issue. Alex Boswell lead the charge with Ajax Mistakes and followed a year later with the more meditative Rocky Shoals of Ajax Development

I think most tech blogs I read have gone there however most recently I caught Neil Mix’s Ajax as an Anti-Usability Pattern

I don’t want to cover old ground, anyone who sees Ajax as more than just another tool in their toolkit is kidding themselves, but I do think its worthwhile discussing what Ajax can actually be used for. Neil is right, it certainly doesn’t make things inherently more usable - in fact there are so many destructive elements of Ajax that have to be accounted for that to use it without the support of one of the major libraries can be a usability don’t or at very least a time-sink.

Ajax is only a usability enhancement insofar as any performance optimisation that improves perceived loading time is a usability enhancement.

I think that the most useful way to think of Ajax is as an optimisation. This will change your approach to web development in a number of ways however take these two tips and see how you go:

• Build an application which can have Ajax layered on unobtrusively. There are plenty of articles on this topic so I won’t expand on this further, but suffice to say it leaves the door open for Ajax and you can stop thinking about it and get down to building your application.
• When you have a functional version of your application and you are evaluating its performance both from the standpoint of raw metrics (total query time, total page load etc.) and percieved page load (ie. does the page or application just feel slow?); consider Ajax alongside all your other optimisation techniques.

My guess is that most times you are likely to opt for solutions other than Ajax. When confronted with a page with a number of distinct elements on it, you may elect to load each individually with Ajax if this decision-making is done at the head of a project. The danger is the buzz behind this technique has pushed it out of sequence, to the front of the decision making process. Ajax is not being evaluated alongside much longer established optimisation techniques because Ajax is being mistaken for an essential usability enhancement.

I find that when you put Ajax and server-side caching head-to-head in your first round of optimisations then you will get more bang-for-buck from the caching. This is because many web-applications are victim to the number of individual requests that make up a page - a problem that Ajax only exacerbates.

Once you’ve got your caching, your query optimisation, your initial client/stakeholder feedback you are now free to consider any further optimisation strategies which will potentially provide a more satisfying user experience. Who knows, you may even use Ajax!