Monthly Archives: January 2014

Coding for Legacy Browsers, and the Internet Explorer Problem

As a coder, I hate Internet Explorer. Or at least I used to hate it: IE10 and IE11 are actually pretty good browsers. But we’ll get to that in a minute.

We continue to have some clients request that their sites support newer HTML/CSS features in IE9… and even IE8 in rare cases. These browsers are now 3 and 5 years old, respectively. Nearly ancient in Internet years! But even when released they lagged behind their competition. To understand why coding for legacy browsers–and especially IE–takes more resources, you need to appreciate how HTML works (or doesn’t).

The inner workings of web pages are primarily established by an organization called the World Wide Web Consortium, or W3C. Every few years they publish official standards which extend the functionality of HTML/CSS. To support the newest features, you also need a relatively modern browser that understands them. Typically websites will be coded to degrade gracefully for legacy browsers. In other words, content will still display but might be formatted differently and will lack some functionality. With an additional layer of Javascript we can manually replicate newer features in an older browser… but it requires more work, and more testing, for each legacy browser added to the support list. It also usually means some sacrifices need to be made for all users in order to make the experience consistent for the lowest common denominator. The ROI to do this is typically not justified unless you process a large amount of transactions online and can’t afford to ignore any browser fringe cases, no matter how small.

Of all the legacy browsers the most problematic is IE, which for years decided it would set its own standards apart from the W3C. Microsoft pushed their own proprietary features, which meant pages specifically created for IE wouldn’t work properly in any other browser. And they consistently lagged behind supporting the most recent HTML base spec, so IE was buggy and always required workarounds when viewing code that worked great everywhere else. While IE had a vast majority of the market share, Microsoft could afford to be the exception and force web designers to bend to its will. As recently as 2009 IE still had over a 50% adoption rate–even after years of better, faster, and more secure browsers had chipped away at it. Then along came Chrome, and later the rise of the mobile OS, and that was the beginning of the end. As of today, IE has around a 20% adoption rate and has been dropping precipitously.

And yet, even though IE8/9 combined comprise only around 5% of the 2014 market, we continue to see a unusually high number of institutional clients who are using these browsers. Why? One word: Vista. Microsoft’s Vista OS was so universally hated that users stayed on XP and refused to upgrade. For years, new PCs shipped with Vista installed would often be “downgraded” to XP. Along came Windows 7, and now 8, and many businesses continued stick with XP. As of 2014, this OS has a disproportionately large user base even though it’s now over a decade old. Why? Primarily because Microsoft has continued to support it’s flagship Office Suite for legacy systems. But, they abandoned any updates to IE long ago.  So many large organizations–whose IT departments don’t want to deal with the headache of updating or replacing a hundred machines–have locked their users into using an outdated version of IE on XP.

We are happy to report that Microsoft has finally conceded the battle, and both IE10/11 show great support of W3C standards and render modern pages reliably. And also that in mid-2014, they will stop releasing updates of Office for the XP operating system. This forced obsolescence means that the unnaturally high adoption rate of XP… and legacy IE browsers… will finally fade into the mists of Internet past. In the meantime, if you are still using XP, encourage your IT department to install Chrome or Firefox as an alternative. Both will greatly improve your Internet experience and are safer from a security standpoint.

We would love nothing more than to look forward than backward when designing and coding new websites.


The CMS and the Future of Content Publishing

Not too long ago, websites were a bunch of manually integrated pages of code. The IT guy made site updates because no one else knew how. Lacking a unifying structure, legacy web properties often suffered from entropy and devolved rather than evolved. Then along came the CMS to manage content and navigation, which also allowed anyone to publish a web page without being a coder. It ensured brand consistency and easy site maintenance. Initially too expensive for any but the largest companies, with the advent of open-source solutions this capability is now nearly universal.

While it’s substantially cheaper now, the decision to have a CMS manage your content still comes at a cost. The up-front fee of installing and configuring it is the obvious one. But perhaps more importantly, a CMS can be as limiting to content management as it is liberating. Because it is based on inflexible publishing rules, authors are forced to “draw within the lines” when adding new content. We usually do a great job anticipating our client’s content needs and designing a solution that meets them. But inevitably, they’ll create an exception… embedding a video on a page that wasn’t designed for it… posting a custom landing page… adding a unique call-to-action…

So we’ve started thinking about CMS development a little differently, beginning with the Spiezle redesign we just launched. Currently, nearly all CMSes are developed based on a fixed set of paged design templates. Each template is created to fit a particular type of content: a blog, or a contact page, or a home page. Choose a template and fill in the blanks. But… what if CMSes weren’t template driven, and instead allowed an author to select from a number of “content type” blocks that could be added, stacked, and re-arranged on a per-page basis? Instead of just a handful of templates, this would allow for a range of customizable page layout permutations. SquareSpace has implemented a system that is similar to this in concept, but because it’s a hosted service it’s not a good fit for large, complex websites with deeper functionality.

Spiezle was a proof-of-concept for us. Their home and project pages allow for a degree of flexibility, so the client can change the layout to prioritize content rather than tailoring the content to fit the template. We created a custom module in Expression Engine that allows for this functionality inside of an existing open-source CMS. It was so successful that we’ll be developing this concept even further future web sites. We can’t wait for the day that “templates” largely disappear and sites are no longer like a big Mad Lib… and neither can many of our clients.