Firstly, to counter the somewhat curmudgeonly tone of the title, I am definitely not the oldest or most experienced web developer—I’ve only been in this industry for seven or eight years, five or six professionally. However, I do remember when many aspects of web development were far more difficult than they are now. I remember trying to track down randomly appearing content in Internet Explorer 5, (that’ll be HTML comments after a floating block element), and why we used @import to link to stylesheets, (so Netscape Navigator 4 didn’t try to interpret them). I even remember the level of work it would take to support non-Javascript users, because having it enabled was not nearly as prevalent as it is now. By comparison, with the resources and information available to developers and the relatively good browser support we have, today it is pretty easy to get designs to ‘work’ in even the most reviled browsers.

So why is it suddenly so fashionable to advise developers to drop browser support for certain, often non essential, features? To not use certain proprietary fixes because they aren’t valid? Worst of all, why is it okay to advocate that if a client doesn’t agree with your views, you should turn away their business or quit your job in protest? It seems to be that, as it has become easier to build sites, developers are more determined to keep their code clean, less inclined to implement fixes and, most importantly, happier to sacrifice a subset of users for technical benefits that only they will really understand. The industry is so close to being in a golden age of reliable rendering engines, support for exciting advancements in technology and the focus shifting from ‘making things work’ to ‘doing cool stuff’. Unfortunately, we are not quite there yet, and impatience seems to be increasing.

My first, major issue with these opinions and those who express them is that, as I referenced so wistfully above, browser support is nowhere near as difficult as it was even three years ago. So many nasty browsers have fallen by the way side and those that haven’t can be extended with great examples of ingenuity. In this light, dropping browser support so often smacks of laziness. Of course, if the portion of your audience using a certain platform is negligible, and your client is happy to sacrifice them, and there is economic value in doing so, go ahead. But every case is extremely unique, and these articles seem to forget that. There almost certainly isn’t economic value in shunning even 1% of your users because you have to use a proprietary filter over a valid CSS property, or an almost certainly pre-existing Javascript work-around. You are kidding yourself if anyone but you really cares.

The second, more important, issue that I have is how un-constructive this opinion of educating your clients or firing them can be. It used to be that developers would publish inventive workarounds and document bugs so that bugs could be more easily fixed. Now they are happy to advocate an approach that 99% of their audience cannot feasibly take. In the current economic climate, not many freelancers can afford to drop a client. More importantly the majority of developers won’t be freelancers, and they are never going to resign over having to implement a fix or support a platform they don’t like, (and if they did, their CV isn’t going to be worth much to future employers—I certainly wouldn’t have hired a developer likely to walk out if they didn’t get their own way).

I am absolutely in favour of using modern techniques to implement features that might not be supported in older browsers, I absolutely believe a website doesn’t have to look the same in every browser, and I am absolutely in favour of dropping features for browsers that don’t play nicely, if it is feasible and not to the detriment of the user. What I am not in favour of is this current trend of developers deciding what is ‘feasible’ and what is not, and resorting to deriding their customers, or worse, if their views are not shared.

By far the most popular of any of my personal projects is Flickrshow, a Javascript slideshow that evolved from earlier gallery projects into the first public version in 2006. For those unfamiliar with the project, the goal is to allow as many people as possible to embed a slideshow displaying Flickr images into a webpage. The emphasis has always been on simplicity and ease of use, rather than complex features, and this has led to its use by scores of people who most likely would have resorted to poorer implementations or worse, none at all.

After a hiatus of over a year, I recently released the newest version of Flickrshow to public beta testing. The previous version had no real faults, other than a few glaring feature omissions, but was definitely showing its age. The goal of this new version was to add a few of the most requested features and, more importantly, remove another level of complexity by removing any framework dependance from the slideshow, (it was previously using the Prototype framework).

This version of Flickrshow uses only native Javascript functions, and contains its own animation and remote loading functionality. It now features auto-play, configurable pop-up controls, better themes, multiple shows per page and improved integration with Flickr. It is also compatible with all modern browsers, (although by making use of certain CSS properties it will look slightly less rounded in older software) and the size of the script has been reduced from 58Kb to 8kb. If you are interested in the project, please try out the new version and register any issues.

An old but fascinating article from Information Architects on how contrasts in culture between Japan and the West are exhibited in Apple’s Get A Mac advertising campaign.

Last Sunday, they started airing the […] ads here in Japan. And here’s a surprise: they’re different. The Mac guy isn’t particularly cool and the PC guy is a real “salary man” type. The ads aren’t as obvious as the Western originals. In Japan, you need to be more subtle.

I'm slowly studying the Japanese language and I’m constantly having this contrast impressed upon me. So often words are used to convey an opinion that, directly translated into English, would carry significantly less weight and offer far less resistance to a proposed path. Being able to express an opinion in this manner, and maybe more importantly understand when one is being offered, can be a significant challenge and seems to me to be a key factor in understanding and working within this society.

Something I and those close to me have known for a while, but that hasn't been mentioned on my personal site, (bizarrely)—today is my last day in charge of the technical team at Outside Line. From next week, I will be fulfilling a massive ambition of mine by moving to Japan to live and work. I’ve been Technical Lead at Outside Line for over two years, and have been fortunate to work with some of the most talented and creative designers and developers you are ever likely to meet—we’ve put together some brilliant websites in that time, and I am really proud of the work I’ve been a part of.

From September, I will be taking up the role of UX Engineer with Cirius, where I will be helping to develop and extend their products in the international market. I’m really looking forward to working with some very talented people in a fresh, agile environment, and all within a city as vibrant and exciting as Tokyo. See you all on the other side.

I've recently been developing a little something in Codeigniter that features an API that is as true as possible to the principles of REST. In order to do this, I had to extend the core Codeigniter Input library to allow access to properly escaped values from DELETE or PUT input in the same way as you would normally access GET/POST input.

The code is pretty simple, and unfortunately does require file_get_contents until I can figure out an alternative way of accessing the input. The whole class can be downloaded here.