Developers love to build things from scratch, by building a system from the ground up, they have an intimate knowledge of every part of it. Unfortunately, in a commercial agency environment, limited timescales and budgets force corners to be cut and these systems – unless tightly planned and controlled – can become a nightmare of kludgy code added to satisfy bespoke requirements for a number of very different projects.

The CMS landscape

Web-based content management systems are a fairly mature technology these days, ranging from high-end enterprise systems to well-supported open-source solutions and some recent projects designed to support the latest thinking in usability and web-standards.

Most of these system are under continual development, either by dedicated programming teams in the case of commercial software or by communities of coders, each lending their specialist skills to parts of open-source projects.

Agency built solutions on the other hand are generally only updated when a specific project requires it. The gap between the functionality offered by the agency’s CMS and that offered by the third-party alternatives grows over time.

Sensible use of resources

When an agency starts work on a project using their in-house CMS, it’s often the case that the developers need to do a significant amount of work just to provide basic functionality.

By using a suitably extensible CMS the basic functionality is done and dusted from the get-go, developer time can be more productively used in building any bespoke functionality within the CMS framework. An added benefit is that if the bespoke functionality is built in a modular way, it becomes a re-usable asset.

Who’s to blame?

Nobody really, or possibly everybody. The problem usually occurs when non-technical client-managers ask the developers for estimates on building a site to a certain specification. Developers naturally think in terms of coding the whole thing themselves, after all, it’s their job to build software.

One approach

A good approach is to try and match the requirements of each project to the capabilities of an existing system. The systems evaluated will depend on factors such as:

• Budget

  Depending on the scope of the project, a licensed commercial CMS may be required to fulfil the requirements. These can vary greatly in price so identifying such a requirement early in the project lifecycle can be paramount.

• Hosting Platform

  The agency will not always be able to specify the hosting environment for the site, the platform in use will limit the choice of CMS.

• Familiarity

  If the project requires some bespoke coding or complex configuration, it may be safer to stick with a CMS with which you have some experience. Reducing the learning curve is another good way to cut development time.

Third-party CMSs will not fit the bill for all projects, but it’s worth taking a little time to find out if you can skip weeks of re-inventing the wheel and set developers straight to work on custom functionality. You will also have the advantage that, with a CMS in place, your content editors can begin work populating the content and the front-end designers can be working on templates without the developer being a bottleneck in the production process.

I’m not suggesting that this is the case in all agencies, I know of quite a few who have embraced third-party solutions such as WordPress or Umbraco for even the smallest of sites. I also know a similar number of agencies who’s in-house CMSs I’ve either worked with or who’s employees have muttered “We have our own CMS, but we don’t really like to talk about it…”. I wish I could say I’ve seen a good agency-built CMS, but they seem to be in short supply.

SlideRocket

SlideRocket have built a very slick presentation application which incorporates the advantages of being web-based (flickr photo search etc.) with the ability to take a cached copy of a presentation to play in an offline player, meaning that you are not reliant on a web connection in order to present. The collaborative aspects work well allowing presentations to be shared publically or by password. You can also share presentations, images or individual slides with other SlideRocket users creating a large pool of content to choose from.

280 Slides

280 Slides has steered clear of adding too much advanced functionality and focused on ease-of-use. For many people this will be the fastest of these applications to dive in and start using.

Empressr

Empressr is an application which differentiates itself through social network integration tools, in addition to a wealth of sharing options for embedding presentations in Facebook, Myspace and others, they also have the facility to import live tweets from twitter into a presentation. Brave presenters could import live feedback as part of their presentation.

Like Lohan straight out of this week’s rehab, a web app can look rough first thing. Andrew Berkowitz knows this and takes us through five iterations of a single screen of web app Teamsnap, as it blossoms from “ugly and unusable” to “just feels right”.

A nice peek into the design process behind a web application. It’s good to have the details of why changes were made rather than a just a series of images showing the development of the design. The discussions that drive the development process are vital and it’s nice to get an insight into how they affected the decisions that were made.

bcToolkit is for companies who use Basecamp for managing projects but who want easy access to high level reports.

The application began as a solution to a simple problem. My Managing Director had exported a Basecamp time report and was having trouble sorting and filtering the data in Excel. I had been looking at the Basecamp API documentation and decided to build a web page to create a task/time report for any project in our account. This proved so useful that I started to get requests for other reports – such as a report of everybody’s time recorded for each day of a month.

We’ve been using these reports for several months and I thought that there might be other Basecamp users who would appreciate them so I’m tarting up the UI and adding lovely big dollops of AJAX goodness.

We are planning to start a limited closed beta in a few weeks time so anybody interested in trying out my latest creation should head over to the site and sign up.

“Will it impact accessibility?”

We need to determine if our new feature will have a negative impact on the accessibility of the content. This could be due to user interactions e.g. clicking on a link, causing the page to fetch new content from the server and inserting it into the middle of some existing content. Non-visual browsers may not register the fact that this new content exists.

“Do we REALLY need this feature?”

If you can’t justify the interactive element as absolutely essential, then there is little point in wasting time and effort on building something that will actually degrade the value of your content. In many cases you may feel that a feature is not strictly essential but gives your content a competitive edge by making it stand out from the crowd. This is fine; I’ve poured enough effort over the years into doing stuff just because it was ‘cool’ to know that stagnation occurs if you don’t try to push the boundaries from time to time.

“Can we make it accessible easily?”

Are there any existing techniques that will allow us to build the new feature and still retain the required degree of accessibility? Looking for the path of least resistance is always a good exercise. If you find a solution, you may have to compromise your feature’s functionality or the degree of accessibility slightly, but the savings in time and effort may be worth it.

“How accessible does it need to be?”

The target audience may affect how much effort, if any, you need to put into accessibility. From a purist point of view, this is blasphemy, all web content should be accessible. From a business point of view, there may be a good case for not conforming to accessibility guidelines. A friend of mine worked on some web-marketing material for a large car manufacturer. He told me that their position on web content accessibility was “Blind people don’t buy cars”. This seems callous at first glance, but when you think about it, the work required to ensure that all of their web-content is accessible to the blind is probably not worth the return they will get in terms on non-sighted customers. It becomes unviable from a business perspective. However it’s a rather short-sighted view (if you’ll pardon the pun) as accessibility considerations could extend to users accessing the content from mobile devices. Web capable mobile phones and PDAs are commonplace these days but if your content does not display properly on a small screen, you could be shutting out more potential users than just those with a disability.

“Do we need to do it properly?”

If you are concerned only with passing automated accessibility tests then your work won’t be that difficult as the validation software cannot detect whether or not your dynamically generated div with XMLHTTP imported content is vital to using the website. A NOSCRIPT tag in the page will probably see that your page validates, but that’s not really in the spirit of the thing is it?

So who wins in the end?

In an article written for Digital Web magazine, P-P Koch writes:

“The delicate balance between accessibility and usability needs more thought. At the moment I don’t see any answers, only a few questions, one possible rule, and a potential danger. The rule is “Accessibility should not restrict usability”.”

As a possible rule, this is a nice starting point but is a little too neat and tidy considering the mass of complications and assumptions that it represents. The issues of accessibility and usability in web design are, in my opinion, still too immature to strap down with rules of thumb. Until we no longer have to make compromises between our usability enhancements and accessibility guidelines then we should evaluate each piece of content on it’s own merits.

For now at least, I declare a draw.