Tonight I came across an update from the IE team. This topic was also covered at A List Apart. Its best to read those articles first - its on a key Web Standards issue (short version: to trigger ’standards mode’ in IE8 a new meta tag will be required on your pages) and I think a thorny one.

Sometimes you read something and instantly you feel that something is awry. I wasn’t alone either (although the author the esteemed Eric Meyer comes out with support for the solution):

As I read through Aaron Gustafson’sBeyond DOCTYPE: Web Standards, Forward Compatibility, and IE8, my immediate gut reaction was deeply negative. The version-targeting mechanism Aaron described was just wrong, completely backwards, the exact opposite of what we ought to be doing. Every one of my instincts, honed over a decade-plus of web development, was in opposition.

I should begin by saying - I am not one to bag all things Microsoft - I think too many people anthropomorphize companies like Microsoft and Google. In this situation however my gut reaction is to disagree with their proposed solution because it feels like yet another complication is to be added to publishing web content.

The burden of majority market share and a user-base of many millions is certainly something that will throw all sorts of confusing considerations into their pathway and thus I expect some missteps along the way (as I would from any organization).

The great thing about having the IE team blogging however is that there can be dialogue with the community and the best pathway can be illuminated through that dialogue.

The aspects that I feel are wrong about IE8 requiring a meta tag to enter standards mode are :

• The list of things developers need to do to accommodate for IE grows again.
• It feels like we are forced to trade an extra meta tag to get IE to behave.
• The article argues our mothers will have IE8. Maybe our Mums can wait for IE8 until the sites on the web incorrectly accommodating for IE7 are corrected? I implore you - ask your Mum about IE8 tonight - let me know what she says.
• I don’t like documents ‘knowing’ about what renders them.
• Something Mum once said about putting your best foot forward.
• IE9 will require a golden key embedded in your page to unlock its level 23 rendering engine.

The weird thing is I do like versioning things - we use versioning as a safety net - much as its being proposed for IE8. I guess it just doesn’t feel like the web I know. I like the idea of browser companies trying hard to render my site correctly rather than me trying to test and code for all the browsers out there.

I hate reading posts of dissent which don’t provide alternatives so here’s my hastily constructed one; Rename IE and no longer use any trace of that name to identify it.

The existing web with IE specific code only kicks in for IE. The new branded browser from Microsoft ditches the older rendering engines - drops its weight and runs like its a new entrant to the market.

Anyway, I note it here; I disagree.

I used to get frustrated when someone beat me to a post, especially when my post had been delayed due to other committments. I’ve shrugged that off these days as I like being economical and afterall, linking to existing related work is sort of the point of hypertext, right?

One of the blogs I subscribe to, ‘Software As She’s Developed’ by Michael Mahemoff covered and extended upon some thoughts and frustrations I’d been having with ecommerce sites recently (or forever, I guess).

I’d recently decided that I should get over my disappointment with the I-Mate KJam and should get a new phone. Having been burnt before I wanted to research the phone well and feel like I had surveyed what is available. Being in the field I am I surmised that online would be the place to undertake this research. It would be a pinch. A saturday morning would do it, surely.

I have now decided, after days of research, that it is impossible to do thorough shopping research painlessly online. I can only assume that the expense of setting up a good online shopping experience is beyond but the biggest of players. And even the good examples I found are not yet frictionless from frontpage to checkout and are also rarely localised to Australia yet.

This post covers a few technical reasons why many sites are more costly from a time standpoint than they need to be. I’ll try not to restate too much of what is said there as the post already covers it nicely and is worth a read.

Instead i’ll raise some additional rationale for why commerce online is still in its infancy and why many likely abandon it for the bricks and mortar encased sales-people of the real world.

So firstly, lets explore the why of the activity.

Why shop online at all?

If its easier to just go to the shop, compare products side-by-side and to interact with the sales people to clarify facts you are unsure on then why bother with online shopping at all?

Well, I did, in frustration abandon an online purchase for an offline one but I felt a few basic drawbacks from the experience :

• Sales people’s incentives do not always align with yours. A quick way to test this (and I did) - ask them a question about the product you already know the answer to and you will notice the response usually was what they felt you wanted to hear rather than factually correct.
• Its a massive task to compare products within a store as well as across competing stores. It strikes me as being suited to an online activity where data processing is common activity

Shop front clutter
Many sites lose me on the front page. I dig around a bit but generally a front page brimming full of thousand of links and thumbnails doesn’t bode well. Only oddball bric-a-brac types appreciate clutter - and only because they know it means normal people wont have found their precious treasures yet. I don’t want to see all your products and specials and categories on your front page if it obscures the basic information I am after (like, do they even sell phones?). With the phone buying experiment I found it hard to locate a full list of phones sold by a particular telecommunications provider.

Shop fronts on the web are not equivalent to shop fronts in the real world. They are more like what a shopper sees as the enter a real shop - everything! It of course could be much more effective than a real shop because you should be able to search for exactly what items you are after and get straight to them. My supermarket still fails me in this regard because I often find myself scouring the isles trying to reverse-engineer the reasoning behind why they placed the milk next to the pet food and not near the bread.

No feature comparisons
If you are looking for a phone, a tv, a car (and these items seem quite popular among humans) then you usually find yourself in a ‘feature-off’ where feature-laden products vie for your approval. Of course, certain aspects about you will help determine which features are important to your purchase decision (your bank balance/credit, existing items you own like the Blueray enabled PS3 you just bought etc.)

Having a dozen or more tabs open is a terrible way to compare obscure details between each of products. At this point I must give some kudos to shopping engines like the one powering tech.yahoo.com which facilitate easier feature comparisons. Why are their still so few ecommerce sites that support this functionality (and, indeed, when can I see a version of tech.yahoo localised here in Australia)?

Can’t bookmark ready for easy comparison

Hopefully most sites support bookmarkability these days (those that don’t are definitely missing out on sales) however, as cool as modern bookmarking tools such as del.icio.us are, they do not cater specifically for shopping and can’t extract the attributes of the products you’ve shown interest in. I’ve a feeling that before long we will see an extensible product microformat become widely adopted which browsers or shopping spiders could read however for now we must rely on the site to provide this functionality.

I’ve a feeling I could continue this list forever but I am interested in frustrations you’ve had with online commerce. What improvements can online stores make?

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.

A point I covered in earlier posts about Twitter which I would like to revisit is that of Twitter’s usefulness being less about letting people know ‘What I’m doing now’ (which, as readers of this blog may remember, I don’t find that useful) and more about it as the nexus point between various gateways.

Reviewing what I said in one of the earlier posts :

Something I haven’t heard much in the current conversations about Twitter and that I think is important is that one of the key strategic strengths of the service is infrastructural - the link between IM and mobile network messaging and the web is a useful one which many applications will build upon. I think one of the players in the industry, whether Twitter or Jaiku or a new player to come (and regardless, likely to be acquired by one of the big companies) will benefit from owning a reliable set of gateways maintaining these links.

Being a platform is hard work

As anyone using the service would have noticed - its hard work maintaining gateways and services and in general ’being the platform’ or nexus point for a variety of different consumers.

Some proof of this; another company, IMified who are in a very similar business to Twitter, recently plugged Twitter into their own service whilst the Twitter IM bots were out of action to allow users of Twitter to keep on Twittering :

Over the weekend we added Twitter as a new IMified service. We definitely feel their pain trying to keep an IM bot up and running. We’ve had our own issues in case you haven’t noticed ; )

And this cheekiness :

It appears the Twitter IM bots are still down, but have no fear, we just added support for notification updates to go along with the release of status updating last week. What can I say, we’re opportunists!

But being a platform can also pay off…

One of the coolest bits of functionality that’s actually useful that Twitter has afforded another service I use, RememberTheMilk, is the ability to use the SMS and IM gateways to post tasks to my task lists. This saves me money and time when I am out and about and I think of something I need to do/remember.

A ‘QuickAdd via SMS’ option to Google Calendar should be a straight-forward (and bloody useful!) addition  if utilizing the Twitter platform. I am sure a variety of other services leveraging SMS/IM will appear (Google/Yahoo/MSN Search?) benefiting from the effort the Twitter people have undertaken to ensure the infrastructure they provide stays accessible (and I am not saying they are there yet…).

If I make bold (and possibly long) assertion; assuming people continue to find use for these short message/short instruction services and the Twitter team can keep it all hanging together, ironing out the kinks and interruptions, we will see them become the platform of choice for short-message-in/short-message-out type services and in the acquisition path of a multi-national telco!

Anyone who has worked at an organization with more than a few developers for a reasonable period of time would have felt the pain associated with a growing codebase. The word ‘legacy’ creeps into the everyday language and the number of maintenance tasks soon exceeds the amount of time spent writing new code.

The maintenance tasks hopefully make your existing clients happy (’serve the client in front of you’) but the reduction in new code generally means less new features per developer and therefore is naturally linked to a reduction in your ability to increase the amount of product you can sell to your clients.

There is of course a correlation with the amount of code you write to the amount of maintenance it requires however exactly to what factor this is depends entirely on your processes and how they affect the technical debt you incur.

Relish deleting code

My first piece of advice to any developer (you never know when your own codebase will become a multi-developer maintenance monster) is to relish deleting code. Most code, after-all, is the application of standard algorithms and patterns to specific problems and is therefore not that useful or unique once it is no longer required.

Don’t keep code around just in case. You have it under version control so as soon as it is orphaned then delete that sucker. Have an active deprecation process that is regular and ruthless!

Campaign actively to deprecate unused functionality within your organization as well. The temptation to keep functionality around just in case is not reserved to developers; product development, sales and marketing all fall into this trap.

It is costly to leave unused functionality and code intact because it costs an organization in a number of ways:

• Developers have more complexity to deal with and this will always result in waste.
• Users have more unnecessary complexity which affects the usability of your product which in turn affects how your product is percieved.
• Technical debt is incurred over time - its like continuing to pay rent on an apartment you already moved out of.

The global namespace is not your playground

Making changes becomes the focus well before the codebase even reaches the inflection point of maintenance outstripping new code. This is because many features of any given software product are built on top of existing features.

The enemy of change is the dependency and the easiest way to create unnecessary dependencies is to create globals because if its in the global scope then other coders will use them. Declaration scope and JIT inclusion of necessary dependencies are your friends - use these wisely.

Those entry points into your codebase that are necessary because they are utilitarian or because they kick your application off should at least be namespaced off into a structure by using a pattern such as the Singleton. Don’t be fooled - a Singleton is still a type of global but it is much easier to attach documentation to and control the signature for it.

Divide your code into layers to assist in reducing coupling and avoid having lower layers called directly from layers that are not immediately above them. For instance - if your page or front-controller calls your database directly you will find you reimplement the same query creation code, query execution and object population code over and over. Its much better to abstract this functionality to an object hierarchy which can specialise in these tasks as there is nothing useful in seeing lowlevel logic scattered through-out the logic behind your presentation.

Much of this advice is available from a variety of sources and I do recommend reading up further on the topics I have mentioned if you found that some warning bells with your own organisation’s codebase started to ring. Codebases can become massive - particularly when their are multiple developers involved multiplied by a few years of time. Some continual investment in keeping the house clean will pay off by allowing you to spend more time on new code.

There is no denying that feature-wise Wordpress offers everything that an amateur or even a professional blogger could need.

Unfortunately, something I always suspected of WP but never wanted to admit was internally there was a level of chaos which might spill out and hurt me.

Well last night, hurt me it did. I am not sure whether an edit to the theme, a new plugin or a recent upgrade was responsible but I noticed the feed was no longer validating and various applications were having trouble with this including Feedburner.

Feedburner’s FeedMedic led me quickly to discover an errant white space at the start of the file.

Familiar with PHP as I am I thought that following the execution logic from the index page (to which passing a parameter would yield the feed to be returned) should eventually locate the mischievous white space.

The first few files seemed straight-forward and single purpose however the more I dug, the more apparent WP’s internal discord became. Globals, functions everywhere (including a whole stack in a file called ‘functions’), procedural code and the occasional class that of course gets instantiated into the global namespace.

After about an hour of checking through the end of php files trimming white space and double-checking every echo I could locate I decided to take another tack. I tried to create a simple file which just recreated the variables I needed for the feed file to work.

This work revealed a very deep hierarchy of requires - as I added in one require it would require further dependencies which as I proceeded seemed less and less relevant to the work required to render the feed.

Finally I realized that WP was not going to let me debug this issue in any sort of reasonable time (without setting up a step debugger or retracing my steps earlier with echoes until I located my space) and I should just accept that a space was being buffered and I should try clear it just before I echoed my feed.

Some quick research on php.net and the only function which looked like it might clear the default output buffering php uses was ob_clean. I’d always thought this would only apply to output buffers I’d explicitly setup but it seemed to do the trick for my feed.

So what to conclude from all this?

I believe blog software will continue to evolve - but I wonder whether Wordpress be able to keep pace with all its technical debt?

That a space can break an application is somewhat of a flaw in PHP. (Using a template system with PHP helps avoid that regular case of unwanted output creeping in after a close tag.)

That it took a few hours to get a resolution on this issue is a critical flaw with Wordpress. Whilst this doesn’t seem to have hindered what appears to be the healthiest plugin support of any blogging platform I feel it will ultimately limit the competitiveness of Wordpress as better architected solutions which can foster a dedicated plugin development community similar to Wordpress come to the scene.

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.

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.

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.