Yesterday I learned that all our RSS feeds fail to render in IE7. This was a surprise, as feeds are often the least worrysome areas of output, normally bypassing rendering and compatibility issues. IE7 reported:

This feed contains a DTD (Document Type Definition). DTDs are used to define a structure of a webpage. Internet Explorer does not support DTDs in feeds.

We defined a DTD only to ensure encoding of certain characters, as a number of our feeds are generated from (x)html based, content-managed information and often have content mishandled via software such as MS Word. In the past we have had some problems providing editing tools to suit certain departments resulting in encoding and character-set problems, and the DTD assured us some control over this.

The Microsoft RSS Blog outlines the reason for the failure:

Feeds that reference a DTD are not supported by the RSS Platform. A DTD is used to help XML parsers with validation of the document. However, DTD validation is a potential source of security issues for XML parsers, and validation is not required for feeds to work correctly in aggregators.

The MSDN article referred to outlines situations where a malicious DTD could be used to launch a DoS attack from an untrusted source. Our fatal DTD however, was inline:

<!DOCTYPE rss [<!ENTITY pound "&chr(34)&"£"&chr(34)&">]>

I can’t say I’m wholly impressed that my implicitly trustworthy (requested) content has, according to IE7, untrustworthy components.

The solution is -unsurprisingly- to remove the DTD entry – I call this a proprietary hack – and to keep an eye on the entities which have for operational reasons failed us in the past.

My article on using requestAction() and custom layouts to add XHR functionality in CakePHP is now live on the Bakery.

This tutorial outlines a method for creating or modifying Cake apps that work swiftly for XHR(XmlHTTPRequest)-enabled clients and degrades well to non-XHR/AJAX (even javascript disabled) clients.

Not being able to change the boot options on most machines in the office, I needed a quick n’ dirty way to run a Gnoppix LiveCD on my machine. Enter VMWare… Continue reading →

How important are Website statistics?

Increasingly we hear about the importance of our personal information to marketers, companies and other organisations, but is that information worth more than the actions we might perform – whether it be purchasing an item or accessing a resource?

There will be cases where it is true: If you wish to target a specific group with your direct mail marketing campaign knowing their interests is essential for financial viability. Likewise – but irrespective of the number of people you market to – knowing how to speak to them, to take advantage of their interests, desires and culture is information that could make or break a campaign.

E-mail marketing can to some extent use sheer numbers to overcome lack of information, while websites may benefit from viral campaigns, advertisements, and the stumble upon factor – but would you sacrifice your stumble-upon traffic to gain information about the rest of your visitors?

I use a custom HOSTS files in order to block certain advertisement sites and web statistics servers, requests to them going to localhost instead. The main reason I do this is to block adverts on some social networking sites, where the various banners strewn about the page make the content tougher to read. Recently a number of sites I have visited have failed to return pages when I click on their links, simply because my zealous hosts file spots that the URL is a webstats server such as uk.sitestat.com with the true, requested resource tacked on the end as a redirect.

The resource provider has chosen to deny my request unless I provide some data to their third party statistics provider. The ethics of this are interesting, in that the resource provider could harvest the same information from me if they were to handle it themselves, but by outsourcing (in this way, or rather by this method) they empower me to refuse.

But should I still have access to the resource, despite my protestations? Who loses out the most – I do not get access to the resource, but the resource provider has failed to inform me and failed to gather my information. One of the sites I commonly visit (a technology retailer) has failed to promote a product to me, while another (a charity) has failed to inform me of their campaign.

As I’m the one who can simply copy the requested resource straight from the querystring and paste it into the address bar (or use Greasemonkey to automate the process) , reasonably assured that using a third-party statistics provider probably means that my data isn’t even being stored in a useful way, I think I probably win. However, my habits, my interests, my hit, doesn’t register with the resource provider, so my kind lose out too.

I’m currently participating in a rollout of SiteStat, and their ClickIn feature uses just the method outlined above. This is not a method I would ever consider deploying – and conversation with the people behind some of the sites I visit show that when you point out the problem, they’re concerned about it too.

edit: There are a few other concerns I have about this method – it’s effect on otherwise RESTful URLs for example, and the mess it may make of your internal search spidering.

For some sites denying a resource under these circumstances would be perfectly fine, however is it wise to document and promote this method to your statistics-hungry customers, with all it’s pitfalls? Is a counting mechanism sound if it cannot count those who don’t want to be counted?

It turns out that the SpeedDial extension for Firefox not only gives you regularly updated screenshots of the sites you add, but they’re scrollable too.

Damned useful for photo sites.

Web 2.0 in action?

(I continued to browse the site – “with reduced functionality”)

I tend to come across pages like this only when I’ve disabled JS for developing purposes. What I find interesting about this page is that while the user is told that they can continue, the wording and the requirements box to the right make it sound so important that Javascript is enabled.

Particularly, to say that the site will not “work properly” implies a failure on their part to make it work according to the basics. A catalogue, a search and a shop shouldn’t require this, though they may be enhanced by it.

I had a wrangle over just this issue in a telephone call a week or so ago, resulting in the vendor of the hosted shopping cart system (names omitted to protect the redeemed) changing their JS based menu system to plain old HTML. The changes simply meant their links worked without JS, with absolutely no change to the user interface or mode of use. An easy, but for some elusive, solution. Jakob Nielsen has noted the very same trend.

It’s probably fair to say that the majority of users have JS disabled inadvertantly and this is their way of guiding them back to full capacity, but error pages – which this is – stop a visitor in their tracks, highlight failure, and apportion guilt – the customer is of course, wrong.

Better surely to give them the same functionality of searching, viewing and buying just the same without script. Those users that aren’t scared away by the error page may instead be insulted by it. If there are scripted features you want a user to see, give them a nudge, not a banana skin.

I noticed no difference using their site without scripting than from the last time I visited with, and in the end it was their poor product search that really made the experience worthless.