blog

Over the past few years we’ve worked with dozens of different content management systems with varying levels of usability and workability. In a current engagement with a client we find ourselves having to learn yet another. Although this new system is actually very usable from a content editor’s point of view, it suffers from many of the following pitfalls.

5. Invalid XHTML

Writing valid XHTML enhances accessibility and sets your site up for forward compatibility. It is also the only way to ensure that your site will render correctly in all of today’s browsers and non-traditional devices. All code your developers write should be valid XHTML, expect nothing less from your CMS.

4. Missing or incorrect DOCTYPE

The DOCTYPE part of a document informs the browser what type of code is following and, as a result, how to render the page on the screen. It is not uncommon that a CMS automatically places a seemingly innocent copyright notice on the top of every page. What they may not realize is that unless the DOCTYPE is the very first thing on the page it does not take effect. This means that you could write perfectly valid XHTML code but because the DOCTYPE has been killed by your CMS, your site will not appear correctly in all browsers.

3. No RSS/XML support

XML/RSS is a great way to provide content. It allows users and other applications to pull in the data and use your content elsewhere, all the while linking back to your site. Today’s web is made up of streams in the form of news, events, status updates, etc. Your CMS should be able to participate in this form of sharing information.

2. No Support

A CMS is designed to only cover about 60 to 70% of updates necessary for maintaining a quality website, and even then no CMS is perfect. You will need help, whether it is design or development support for the site as a whole or dealing with the imperfections of your CMS.

1. Messy URLs

Your choice www.dynamit.us/index.php?action=content.display&id=7478&category=1212 or www.dynamit.us/services/web-development. There are tons of good reasons to want clean URLs: more user-friendly when linking, keyword-rich and good for SEO, indicative of a user’s place within a site architecture. The technology is there to make it happen, but your CMS has to be able to handle it.

Want to see what we’re talking about for yourself? Shoot us a note at info@dynamit.us to schedule a walk-through of our dCMS 5.0.

Launching a large web site or web application can be tricky. And, to be quite honest we rarely do it right. I always envision it going something like this:

1. We complete the last list of tweaks and changes from the client.

2. The site is tested across various platforms and browsers with different browser and system settings. Any issues that arise there get fixed. We also ensure that all XHTML, CSS, and RSS meet W3C standards.

3. Code is cleaned up, documented and minified if necessary, then frozen. This means for the next two days or so we continue to use/test the site but code is NOT to be touched.

4. If all is clear we push the site to the live server, but hidden under a subdomain. Run through all functions in its live environment. If there are problems, they are fixed and we start over again at the code freeze step.

5. If we no issues are found, a simple DNS change and the new site is live (instantly and without downtime).

Unfortunately, it does not seem to happen that way. As much as we insist that this is the way to go, clients demand otherwise. There is always a rush at the end to get more and more client changes complete and still launch on an arbitrary date that the client chooses.

But, this is bad for everyone. This single most important thing for a web site or web application is that it is error free. And, the more we rush at the end, the more problems we have. New issues quickly arise because a rushed programmer does not consider every consequence of their changes. This means introducing bugs at an increased rate, many of which go undetected until after launch.

Two things that I would like clients to understand:

1) You can control launch date OR state of site at launch, not both.
We’ve had clients insist that we launch on Friday, then deliver a list of revisions Thursday evening at 8:00pm. This doesn’t work. If you insist that we launch on a certain day, then we drive what items get implemented prior to launch.

2) Remember, launch is not the end.
Give us a list of changes you’d like, but trust us to prioritize them. If we’re nearing launch, we’ve probably spent several months understanding your organization and your goals for the website. Let us decide what you really need now and what can wait. Launch is not the end, we look forward to a long term relationship helping you progress your web presence, there is plenty of time to make changes once we get the new site out there.