How To Turn Your Design Into A CMS Website

If you're at the start of a new web project and the PSD's have been signed off and delivered, it can be tricky to decide how to tackle the CMS integration. I've worked with clients and agencies throughout the UK and there is generally two approaches, create an HTML version and then integrate it, or design it directly within the CMS itself. Before I go into too much detail, both approaches have their pro's and con's. One approach makes designers' lives easier, the other approach makes developers' lives easier.

Static HTML Website

This is the approach most people tend to follow and when I work with Episerver, or Sitecore, it's the approach I recommend you follow. With a static website approach, the designers take the PSD's, they create a completely separate website to build the files in. This website will be purely HTML, CSS, and Javascript. These files won't be in.NET and in this phase the CMS system won't even be considered. Using this approach means designers can use a simple text editor like Sublime etc.. to build the site. The static HTML site has some really good benefits, including:

  • It's quick and easy to get up and running
  • Designers don't need to use Visual Studio and consequently
  • Designers don't need to have an MSDN subscription, which can save thousands
  • A static site can be designed on a MAC if that's the designer's preference
  • You can get designers in without any.NET knowledge
  • Easy prototyping

Intergrated Approach

In this approach, designers work directly with the CMS. They will need to use Visual Studio, they will need some understanding of how pages are split into templates and blocks for example. This approach, in theory, appears to save time. The downside of the static approach is that developers need to integrate the CSS afterward. Speaking from experience, this process of moving the static HTML to.NET move can be tiresome and I've been stood in many morning stand-ups with developers moaning about it. The reason for most of this complaint is the amount of re-copying that's required. Let me step you through the process. Say you do a rough draft of your static site and you have a manager that gets a bit keen over timescales and wants you to integrate the HTML before it's been fully tested. You dutifully copy the HTML And CSS into the CMS. A few days go by and the testing team test your page. The test is in Chrome, Firefox, on an iPad and a phone and they spot a few differences. At this stage, where do you make the changes? If you do them directly in the CMS the static website will become out-of-date and useless. If you have a phase two and the static website is out of date, what do you do? It makes more sense then, to do these changes in the HTML site. As part of that process, if a designer has to change a class name, a developer will then need to copy if back into the CMS. This is why it will make your life a lot easier if you don't think about integrating your website into the CMS until it's been fully tested, then all you do is waste a lot of time and frustrate the developers, as they'll keep on doing the same thing over and over. This admittedly is one of the biggest issues with the static site. With that in mind, doing the work directly in the CMS is usually floated around as a good idea, but, unfortunately, this approach also has flaws. Making a designer work in Visual Studio will take them longer. If you work with a CMS like Episerver, your website will be split into pages and blocks. Having a designer trying to work on multiple files your templates into blocks makes life hard. On a normal project, you might have two designers and each will work on a specific page. Prototyping is also not possible when you don't have a static site. The benefit of a static HTML site is it's quick to knock up. As it's quick to knock-up it means you can design things quickly, try them out see how they look. If you have to do this experimentation within the CMS it will take longer. For example, what's the point of creating all the page types and blocks within the CMS just to work on some prototype ideas? With the static site you have more upfront work for developers, but with a CMS integration, you'll have more post development work.

Takeaway

As I mentioned at the beginning, both approaches have pros and cons. Usually, the con's of the CMS integrations approach outweigh the con's of the static approach, If you find yourself in this situation, I would recommend going static HTML. Static HTML sites can be dumped at the end of a project if you want. If you have a CMS integration and then you want a static site afterward, you're stuffed!  If you're a developer reading this and you're thinking, yeah but the CMS integration sounds easier, the reality is you'll probably waste just as much time afterwards. Also, before we finish up, I should warn you... don't try and do a mix and match approach. Don't try and do a static site in MVC for example, just do one or the other, otherwise, you get the cons of everything!

submit to reddit

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

Back to top