Why is the Transition from Static Websites to Dynamic so Painful for Beginning Designers?


The times when the Web was static are history. Static HTML sites still have their place on the Web but the majority of sites are database-driven dynamic Web platforms that manage content, e-commerce, customer relations, etc. If a designer wants to stay current, he or she needs to be able to design both static and dynamic sites. However, as I have noticed, some designers I know have really hard times when they have to switch from static HTML sites to dynamic ones (blogs, CMS).

Designing static HTML sites is different from designing dynamic sites for sure but is it really that different and that complicated? And if it is, what can one do to overcome it?

CMS are not a new field for a Web designer anymore and it is a safe bet that they will always have a hefty share on the Web design market. Although there are many similarities in designing a static site and a CMS, there are certainly differences as well. To me, designing a CMS is easier than designing a static site but I do feel that both require a different skill set.

For instance, if you want to come to friendly terms with a CMS, you need to have some knowledge of programming and databases because if you are totally unaware of the language in which the particular CMS is written and the database behind it, you will constantly stumble and fall. Probably this is the biggest difference between designing a static site and a CMS. I know many talented Web designers who have tried designing a CMS and the experience was very frustrating for them.

On the other hand, many CMS and content sites are minimalistic, so they need less design work. Because of this, even if you are not the greatest designer on Earth, with some patience and diligence, you will be able to design great CMS templates. You are not starting from scratch and, just like with static sites, a good CMS template consists of layout and a stylesheet, so even if it is difficult at first, you will soon see that actually designing CMS sites is very easy.

Before You Start

Before you start with the layout and the stylesheet, you need some preparation. Here are two important things you may want to consider:

Image Credits: clarita

  • Get familiar with your CMS. If you are new to CMS design, start familiarizing yourself with CMS in general and with your CMS in particular. Getting some basic idea about CMS is not so time-consuming. However, mastering the intricacies of a given CMS is a never-ending task. Be realistic and at first try to understand what your CMS can do and what it can’t do. Leave the more complex issues for later.
  • Acquire some programming skills. If you have become a designer just because you hated programming, there is some bad news for you. If you want to handle a CMS successfully, you need to have at least some knowledge of the language (PHP, Python, ASP, JSP, etc.) in which it is written. Alternatively, find a programmer to help you. In many cases a complete CMS solution for a client involves not only the graphic work but also writing or modifying some modules, so you will either need to become a developer yourself, or seek the help of one.
  • Study other designers’ templates. The best way to see how things work in practice is to study what other designers have created. There are many great tutorials to read and free templates you can study to get started.

Designing the Layout

Designing the layout is one of the areas, where static sites and CMS differ. Yes, you still have menus, head at the top, variable or fixed width templates, and your own styles, and you can use your HTML layout as the basis, but some of these tasks are done differently with a CMS.

CMS offer many great modules to make design layout flexible but they also have some quite illogical (for a beginner) constraints. Very often the successful approach to dealing with layout problems is by thinking and trying – and reading the postings in the support forums. CMS have their logic and sometimes, when you come from designing static sites, it is difficult at first.

For instance, a couple of years ago when I was new to Joomla, it took me some time to figure out how to have two or three columns of articles on the front page. I tried to do it within the index file to no avail. Then I tried with the stylesheet – no success either. Finally, I read in their support forum how to do it. The solution was very simple – the number of columns in the article area of the front page is set from the Admin panel!

Later, I wanted to have more columns in the module above the content area and I tried to find such a setting but there wasn’t. Still, having multiple columns (or in my case just cells because I was still using tables and it was a single row that had to be split) in a module was easily achievable in the index file. I was already familiar with the index file and splitting a module into three cells was a matter of seconds!

CMS allow to use different layout for different pages, so similarly to a static site, you will need to have layout for the homepage and the internal pages. You may also have a different layout for the different sections of the site (news, resources, forums, etc.). If you want, you can have a different layout for every single page of your site – CMS allow this – but in practice this idea is simply absurd.

In comparison to static sites, CMS have one enormous advantage – you can always change the layout later. You just upload the new template to the Admin panel, select the pages to apply it to – and that’s it. In this aspect, a CMS certainly beats any static technology and now when I occasionally have to go back to static HTML sites, I really hate it that content and presentation are so mixed up.

Designing the Stylesheet

The second component of a CMS template is the stylesheet. As with static sites, the stylesheet defines fonts, colors, margins, alignment, etc. Your knowledge about CSS for static sites applies to CMS as well, so at least this part of the transition to a CMS is easy.

CMS do not limit your freedom. You can have a fixed or a variable width template, with tables or a table-less template (though the same cross-browser issues are valid for CMS as well), you can apply backgrounds (including background images) to whatever you like, etc. At least this part of the transition shouldn’t be painful.

In conclusion, though there are some differences between the two type of sites, this is not a completely new are. In a sense, it is more like the transition from one programming language (i.e. PHP) to another (i.e. Java) – you need time to switch and all the minor differences are very confusing in the beginning. After all, for many Web designers the transition from static to dynamic sites was not a problem at all. It is interesting to know how it was for you. Did you have similar problems or was the transition smooth and barely noticeable?



  1. Brian

    I am just now getting into the transition from static to dynamic websites. I am currently set to graduate with an associates degree in computer science in the spring of next year but I have a few great classes left that will teach me the languages I need. Thanks for pointing out some of the things to pay attention too during the transition. I am currently messing around with a wordpress site to learn more about how it is put together and plan on trying to make my own in the near future.

  2. Luz Garcia

    Great article! I’m a fine artist and just started to study web design…I love it but I feel concerned when I look at other’s web sites, they are so creative!!! I’m not sure about the steps I should follow to get to that point….any advice?

    • Tsveti

      Well, I can’t give an exact recipe for success – maybe the more you browse other people’s work, the more ideas you will get and this will inspire your creativity. Mastering graphic design programs also helps because you might have the greatest ideas but if you can’t implement them in practice because of unfamiliarity with the software, this is also a hurdle.

  3. I just started blogging, so I read your article with great interest. Be sure to take advantage of free textbooks. Thank you for your interesting article

  4. Nora Reed

    ya! totally agree worth you! Now i am Professional designer, it was also to me very difficult job when i joined practically!

  5. Dynamic sites are and should be far more than CMS, in particular, user created content is closer to the core of dynamic web and there is a lot more to come. The programming issue isn’t really a designer problem, in small shop scenarios (where it is) it may be “painful”, especially for ex graphic designers with a few Flash skills etc.. Designing good and flexible templates, without every page looking the same, is harder than aesthetics based on fine tuned layout fixed pages afford ((brochureware).

    However in my view, a bigger issue with dynamic sites is the process and the routines most web production studios employ. Wireframs, site maps etc. simply fail to capture and express the final product in users’ hands. The developments we are about to embrace soon, e.g. transitions, content fluidity (e.g. conditional), dynamic interactions and display filters, will present an even greater problem to the static wireframe technique. Wireframes make development of dynamic content tedious, cumbersome and very unproductive, if not outright overwhelming with the reliance on descriptions of the implied User Experience. A huge waste of time and counter indicated by practically all contemporary design and software development methodologies.

    For one, I’ll be glad to see wireframes fade from grace – my preferred technique is freehand sketches and interactive prototypes. Sketches are expressive, readily communicate the unfinished state inviting refinement and readily accommodate casual/playful low fidelity interaction walk-through critiques. At later stages, high fidelity prototypes (HTML/CSS/JavaScript), facilitate real-world User Experience evaluation and expose the majority of performance problems on the client-side in the given design.

    As we head towards Web3, sketching and prototyping will inevitably push wireframes to the sidelines, perhaps some Information Architects will insist on their application and mainly as a form of documentation rather than a conception tool. This methodology maps very well to the division of roles and skills between the design and the software engineering staff, while affording a very safe environment for cross validation of concepts when moving to the prototype.

    • Tsveti

      Right, when you add the process and other organizational matters to the mix, this brings a whole new level of complexity in addition to the design and programming issues. I am not a huge fan of wireframes but in their defense I could say that they are relatively easy to understand and this is a factor, when you work with newbies for sure. But probably wireframes are really a thing of the past.