Here is a little history for those of you who are new to the browser wars. The first major battle was fought in the late 90s between Microsoft Internet Explorer (IE) and Netscape Navigator. The result was a decisive victory for IE and what followed can be described as the dark ages of the browser world. Microsoft had over 90% of the market and as a result decided to stop developing IE. IE6 was released in 2001 and we never saw another major browser release from Microsoft until IE7 was released in late 2006. IE6 was a decent browser for its time, but it did have a number of quirks and bugs. These problems didn’t matter much since IE had such a dominant market position so everyone just assumed that was the way the browser was supposed to work.

There were other browsers available. Netscape was still around, Mozilla, which was the open source version of Netscape, and Opera were all other options. I was not a big fan of any of them, especially their interfaces. When I began working at zu, Shane introduced me to a browser called Phoenix. It was essentially a stripped down version of Mozilla. I started to use Phoenix on a regular basis and it opened my eyes to how IE-centric the web had become. Phoenix eventually grew up and became Firefox. Other browsers were starting to be introduced. Apple had the audacity to make their own browser called Safari and Google eventually introduced their own browser named Chrome, which is based on the same rendering engine as Safari.

Each of these browsers offered their own strengths. Opera has always been fast and feature-rich while Firefox has always been lean but had extensions which allowed you to add the features that you wanted. Safari had excellent CSS support and pushed standards groups to add new exciting features such as CSS animation. Chrome had a lightening fast JavaScript engine and each browser tried to copy and improve upon each others innovations.

This has created rapid and dramatic improvements in browser technology over the past couple of years. Standards began to pick up steam too. HTML5 started gaining steam and browsers began to eagerly implement features like the canvas tag. CSS3 development roared back to life after a long period of stagnation. JavaScript performance has increased dramatically which has allowed JavaScript intensive websites and JavaScript libraries to proliferate.

Even IE, the enemy of web developers everywhere, has finally begun to catch up. IE8 still lags in many of the advanced features that other browsers have, but IE9 looks downright promising. There are many web developers that think Microsoft should just replace IE’s rendering engine with WebKit (same engine as Safari and Chrome) or even drop the browser all together. I cannot agree with this point of view. Competition is good, especially amongst web browsers. When Microsoft conquered the browser world, they abandoned browser development. However, if Mozilla, Opera, Apple or Google had achieved the same type of market share that Microsoft did in the first part of the decade, I have no doubt that they would have stopped innovating as well. Long live the browser wars.

Obviously, I have not used every single CMS available. I have used a few, both commercial and open-source, as well as building my own. Off-the-shelf CMSs have some great features. The app is usually well-tested, mature and very stable. There are often many advanced features that are built-in such as flexible workflow and multi-language support. Many are quick and easy to setup for small projects. However, you are also getting a lot of other undesirable things. They are usually tough to customize, especially the admin interface. You often have slow turnaround time to fix bugs. There are often many features which you don’t need on every project which adds unnecessary complexity for the users. And the instructions are often non-intuitive. Additionally, many off-the-shelf CMSs work great for the IT guys, but non-techies have troubles understanding the interface and find them difficult to update. This is very evident when you support an off-the-shelf CMS.

If you, or your interactive supplier, build your custom solution correctly, you can have the best of both worlds: a stable, feature-rich CMS that perfectly meets your needs.

A custom CMS is not always a cheap solution, though. I don’t advocate trying to build a custom CMS for a client that is not willing or able to spend the money. However, a custom solution can be built for the same price it takes to purchase and implement a large commercial CMS. Using some pre-built components will be necessary to keep costs in line. There are many open-source frameworks and libraries that can be used to speed up the development process and therefore keep costs down.

To develop a competitive-cost CMS, you need the right interactive firm, team and people to build the solution. There are many inexperienced or inadequate web developers who promise the world, but can not deliver. Much of this is due to inexperience. Most custom CMS solutions fall short of delivering the tools promised in an easy-to-use system. This is why companies fall back to pre-built CMSs; they are scared to spend a large sum of money and end up with a terrible solution—or, even worse, no solution at all.

How can a company get around these fears?

Experience
If your web developer has a track record of providing quality solutions, then it will be easier for your company to trust that the project can be delivered.

Process
There must be a well defined process from start to finish. This will allow the developer to provide the client with more accurate timelines and estimates.

Communication
From the web developer’s perspective, you must keep the client informed at all stages of the project and be completely honest in communication. If there are problems or delays, advise your client. By hiding those and then failing to meet targets and deadlines, a web developer is only going to cause mistrust with the clients.

Documentation
For the developer and client to agree on a timeline and price, they must both understand what exactly is going to be build. The developer must provide on paper exactly what the system they are going to build.

One thing a business may be wondering is how big the project must be to make a custom CMS worthwhile. I cannot answer with a number or any definite rules. I will just say that every project is different and every project has a different solution. There is a lot of work that must go into breaking down the problem and finding the best solution. This process in itself can cost lots of money. If you want to provide service to a range of project sizes and types, you cannot support only one solution. You must be open to all solutions.

Standards are important because websites and applications run on many different platforms. Unlike desktop applications, web apps are expected to run on every operating system—plus, every web browser and every version of browser. This creates the challenge of successfully supporting dozens of combinations. Developers are expected to support at least 3 versions of Internet Explorer alone (IE6, IE7 and IE8), so when a browser renders HTML and CSS according to established standards, it makes our job a lot easier.

Here’s a quick tip to accommodate IE users who still experience outdated browser capability: by adding a simple meta tag to your (X)HTML you can force IE8 to render your website exactly as IE7 would. This provides an easy migration path to IE8.

At zu, we have been working hard to prepare for the release of IE8. We have executed an audit of all our existing websites to maintain a high standard of compatibility with IE8. Implementing compliancy standards for our websites has always been a priority for zu. We still maintain support for older versions of Internet Explorer and will continue to do so in the future.