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 think my account (or indeed the shard that I am on) has been upgraded with a hotted-up version of Gmail. This post explains the approach the team took to prepare Gmail for the future.

I am strong believer that the performance of an application is a key influencer in whether people continue to use it or not. For core applications (such as mail) it is critical that no unnecessary wait times be incurred as users notice when they are spending a disproportionate part of their day, everyday, battling their client.

For application authors, web or otherwise, who are seeking to place their app into the core group of applications users access frequently performance will be key. The goal is to remove friction between the user and the completion of their task.

On the topic of speedy Gmail, a few months back I wrote about web applications breaking out of the browser. Soon afterwards I came across the xul-runner-based Webrunner (apparently renamed Prism in the latest version) and used this to break Gmail and Gcalendar out into their own applications. I highly recommend you do the same. The suppositions I made in my post all held up; applications perform much better in their own process away from other web pages. The applications themselves are also much easier to access having been made available on the taskbar.

Webrunner and similar initiatives all have further to go but are already very usable and will save you minutes or longer everyday.

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.

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.

After a very satisfying break for a few weeks, holidaying in Turkey I have caught up with work and am now back online, back to virtual reality. I can highly recommend holidaying in the real world – I plan to do more of it.

I will hopefully cover some of my holiday on this blog over the next few weeks – we have many hundreds of photos to review and share – I can’t emphasise enough how great a destination Turkey is for holiday that both satisfies needs for relaxation as well as for new experiences.

I’ve also got a bunch of web development related posts I want to put together now I have completed some projects at work that were monopolising my time. Hopefully some of these experiences will prove valuable for those of you involved in building cutting-edge web applications.

Even better, if I could inspire people to visit a place like Turkey (which disappointingly has seen a downturn in tourism in recent times despite offering such amazing drawcards in its people and its overwhelming number of brilliant attractions) it would reward the effort I will put in to documenting my travels.

Look forward to a return to posting frequency benefitting from the reinvigoration my trip has provided me.

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.

I just read over at Joseph Scott’s blog that Google Trends appears to be dead. Some further investigation on the Google Group for Google Trends seems to confirm this. I think it would be a shame if Google Trends was to be decommissioned as the service provides a way for ordinary netizens to examine the behaviours of searchers online.

Whilst SEOs would be hardest hit I think that the loss for the rest of us is also significant. There are other similar services however I’d wager none would compare to the volume of data available to Google (dominating around 70% of search in most countries).

Don’t be too worried though, I wouldn’t be surprised to see the trends data appear in another format… Personally, I will keeping an eye on Google Analytics. Remember Google also bought MeasureMap, so by my reckoning there’s bound to be an uber analytics tool on the horizon. The free analytics tools are great for encouraging webmasters to continue to invest in Adwords and Adsense.

Update: Google buys GapMinder. They are really building up an arsenal of data analysis tools!

Update 2: Again Joseph Scott has the scoop on Google having updated the data available on Trends up to Feb 2007.

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.