In the realm of written content there has always been a relationship between how much work went into the piece and the depth to which consumers engage with it. Now I know this may sound like a gelatinous concept but bear with me as I explain.

Books generally render deeper, more memorable experiences than magazines; magazines more than newspapers; newspapers more than pamphlets etc. But even these pulpier written forms will yield more attention (and retention) from the reader than content on the web.

The rise of the blog has introduced an even faster medium which is more catered to scanning and bulk consumption – sort of like reading’s equivalent of fast food.

The active nature of computer screens mean reading from them is tiring and the sheer amount of content available without the physical restrictions of the real universe mean content can be shifted and consumed much quicker. We write content so it can be easily scanned – we try to remove anything that might cause friction with the user getting our core messages. The messages themselves can be delivered in many ways, in bite-size chunks. You do not interact the same way with this information as you would a book or magazine.

To help picture what I mean – imagine working your way through the same amount of individual texts as you have in your most recent blog reading session and then imagine doing that using a paper-based media. You are in a bookstore, tearing through page after page, jumping from book to book like a maniac, leaving a wake of cast-aside material trailing behind you. You move through content like pacman through pellets.

The atomicised web-based content accelerates our desire to move through content quickly looking for small morsels of cerebral nourishment, each nugget of which can excite a brief sensation of satisfaction. These small rewards encourage a desire for more as well as an impatience with content that doesn’t instantly satisfy.

This is not to say that there is not great content on the web, there is plenty, but the best content knows what it is, it knows how much attention the user has to give – for similar reasons, McDonalds never tried to sell you McCaviar.

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.

We seem to rediscover every few months that many users are typing the name of the search engine they are on into the search box. I read many disparaging remarks directed at this very large group of users and I wonder why the remarkers would think this behaviour is ‘clueless’ or ‘dumb’?

Forgetting what the user ‘should’ do, lets consider the two options for a moment. Firstly, in terms of physical and functional composition, both methods of navigating the web comprise of a single field and respond to the enter key; so no difference there. Further, one is placed at the top of the screen, the other often nearer to the centre. I’d say thats one factor that the search box has over the navigation bar.

Moving on, the navigation bar will in most cases punish you for mistyping. Google and other engines will offer a link to (most likely) the site you intended. Now thats handy! I’ve started using the search method for those times its handy. Google Desktop makes it easy to get to a search box (just hit ctrl key twice). This is much easier than ctrl-tab a few times combined with another key-combination to open an URL (and then you get to type the URL…). Who wants to be doing what they ‘should’ do anyway? That sounds clueless to me!

Not all instances of a search engine name being entered into a search engine is for the above reasons, though. ‘Google’ is entered into the Google search engine because who can remember where all their products are housed. Google, in their effort to deliver a ‘simple’ homepage, avoid the portal type page so typing ‘Google’ can be all users can do to find their many great products.

Another point to consider are those keywords put into the navigation bar which aren’t legitimate URLs are often sent to a search engine in browsers such as Firefox. Who wants to spend time repetitively typing the fairly redundant ‘www.’ and ‘.com’ anyway…?

What can we learn from all this anyway? Well next time you consider calling a user stupid, stop yourself and look for the efficiency they are seeking. It can teach you alot about how you could make your application easier. Not everything needs to be reduced to a unthinking action but its worth taking the thinking out of the tasks that don’t require it so that effort is most effectively spent.

Maybe browsers should ditch the navigation bar? Maybe the navigation bar and search box should be one? I’d like to know your thoughts.

Since you are here and reading this I figure you have time to try something out. Don’t worry, this may just save you some time in the future or it may even lead your current project to success earlier.

It sometimes takes an external reminder (something that snaps you out of the myopia that can take hold when working) to provoke you into acting on an simple optimisation; whether it be in your own day-to-day workflow or in your business practices or in the flow of activity your customers pass through.

In web development, a common issue that is overlooked when in the midst of upgrading functionality to a property is that the entry page linking to that feature is underperforming in the delivery of users. I have seen teams toil away, moving mountains only to ignore that traffic will not make it to their creation!

Take the time now to consider your current project. How effective is the page where your users land upon to login or to navigate to your tools or content? Do you measure this page? Is there a high incidence of users bailing without further progression? Are they going to the areas you want them to? Have you made adjustments and measured the affects of those?

I build time into my schedule to do this regularly and always find adjustments that need to be made which would have been overlooked if I had just kept my head down, plowing forwards. I am more recently trying take a similar approach and analysing how I use my tools and whether I can simplify or automate regular tasks.

If you do make some discoveries which are not to your liking, I suggest you take some time to address this before embarking on further development. It will be time well spent.

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?

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.

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.