Its hard to say whether Enso will go the way of my experimentation with browser gestures. Others I work with use the gestures fluently now making me envious of their reduced barriers to productivity. I do think I lose much time transitioning from pointer devices to the keyboard and back so I am inclined to think the people at Humanized have something.

For the uninitiated, what is it? I’d recommend watching the video they have placed on the frontpage of their site. The short rub is that Enso overloads your caps-lock - holding it down reveals the Enso dialog which hovers above your OS, transparently waiting for input. Its a command prompt for navigating your applications or for applying simple commands to your context; for instance some selected text.

It is clearly a polished product - I recognise a few elements from earlier memes they had successfully set loose into the sphere. Some elements such as their use of modal messages which appear in the user’s field of view are smart but maybe not as clever as they present them to be. But maybe they are - I am still training myself to look for the Enso interface in front of me rather than in the task bar.

I can’t help but wonder whether the task of testing this software out is somewhat of a catch-22. To test it properly requires one to learn a few keywords which drive the system and also to train themselves to use Enso rather than existing (slower?) ways of achieving goals. If you succeed at this then the system is probably working for you already and the ‘test’ is over before it has begun.

I guess it comes down to whether you believe this is a significant adjustment to the drag that ‘modern’ interfaces such as windows afford you. I personally think that windowing is working against you for most of the time. Fiddly dragging and resizing is time costly and doesn’t deliver much. If you need to fit two documents side by side then there should be a button or a command for it. Moving these things manually seems like pushing unnecessary work to the user.

Humanized present Enso as being grounded in the study of human computer interaction and they present a manifesto of how life using computers could be much easier. I don’t disagree, but is this product a step forward? Enso takes us back as much as it takes us forward. It reminds us of lessons many developers already know - of the effectiveness of the commandline. It consolidates what Google success has been teaching us - that typed text can lead to an infinite number of destinations and they have made even Googling a few clicks closer by having access always available from the keyboard alone.

Those with Google Desktop who have put up with its (in my experience) fairly regular crashes would be familiar with a similar capacity, in this case overloading the control key, a double-press brings up dialog Enso-esque but of course has in actuality beaten Enso to market to what appears Enso’s most interesting application thus far.

I do persist though as navigating many tabs and windows is my own personal goal and Enso may offer a path of lesser resistance to them. I will let you know how it goes.

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

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.