Even though I know this forum is about how to get the most out of dynamic websites I have just seen so many times that people make things more complicated than they have to be.

There is not reason to invest time and money in an advanced content management system if all you need is a 10 page corporate website. Also, if you cannot afford the resourses or time to get a proper system and maintain it, you could be better of with good old fasion static web pages.

I'd like to hear of examples of when/if you've seen websites that should have not been done dynamically and why. I often run into clients where it would be helpfull to serve them a list of reasons and arguments :)

When you don't have a database backend :D

Its an easy call for me. If the client doesn't want to go dynamic, then I tell them to find someone else. :)

But realistically any client who wont spend the time updating their site with content or whatever, then the a dynamic site doesn't pay.

Also, if the client has html guys on staff, then you can avoid the CMS and have them do manual work. But I would send the client elsewhere, unless they really want us to work on their stuff.

Not really helpful, but my company is all about databases.

Not really helpful, but my company is all about databases.

I hear ya man!

I think if the shoe fits, wear it, otherwise leave it alone. I deal in HTML / XHTML but I also have a partner just down the road who is a dynamic genius. Obviously in the SEO field, you need to cover all angles.

I think commonsense does it. If a client said they needed to be able to add this, do that, and so on, then I would serve them a dynamic site. If they just wanted something small, not going to change often, then static. K.I.S.S principle would then apply IMO.

I'm no expert in web design though...I try and avoid it when possible...he he he

This is an excellent point, Mikkel.

I'm reworking a small-ish site right now for which everything has been done in the most complex way possible. Image links in JavaScript that can only be *displayed* in IE (that's right: visit the site in any other browser and there's no menu). Things stuffed into iframes that also don't display. Everywhere you look, things are compiled into the page that don't need to be because they never change. Huge .gif images that should be .jpg and are 1/4 the size when converted.

For those clients who simply need to update simple things on a few pages, I'm looking at just telling them to use Mozilla, which has a decent HTML/WYSIWYG code editor *and* an uploading feature. A little SSI, and assigning classes for fonts to the container (td or div) where the content will go wouldn't hurt either.

This is totally aside from the times when a nice database/CMS is the way to go.

A lot of badly conceived dynamic sites are caused by clients who think that coding HTML should be avoided at all costs.

I've got one client (a best-selling author) who in '00 spent something like $2,000 to have a dynamic-site system built so that whenever he published a new book (about every 2-3 years) he wouldn't have to pay someone to create a new webpage for it! Unfortunately, his design agency at that time didn't have the guts to tell the client that this was a bad idea.

When I took on the client in '01 I pointed out that the way this part of the site had been built that search engines were unlikely to spider it and that it should be changed. Subsequent efforts to use this feature proved so frustrating -- only someone who could code HTML could make the thing work, and even then it was harder to make work than it would be if it were just plain HTML -- that this year his new web designer and I finally convinced the client to abandon the thing.

Yep, that's precisely the problem. There's no way to deal with the Web without learning something.

(about every 2-3 years)

changes 3-4 times a decade = dynamic? :(

well they probably made more money selling a "custom dynamic solution" than they othewise would have...

Yep, that's precisely the problem. There's no way to deal with the Web without learning something.
In this case it really didn't make sense for the client to learn HTML. His time is too valuable. And it didn't make sense to have someone on staff who could do it, because they would be underutilized. The client's principal problem was he hated relying on others to make changes to his website. Primarily it was a control issue, and secondarily a cost issue.

Here's another one for you.

I have a client with about 300 or so webpages they maintain as part of a successful SEO/SEM centric web strategy. The content is text-intensive, with very little variable graphics. Pages get changed and new pages get added to at the rate of, on average, about 10 per month. No information needs to be pulled from a database. The client recently hired a full-time junior webmaster to do this, in anticipation of a planned major overhaul. For the overhaul I recommended using CSS and SSI-driven navigation. The new webmaster is resisting this, as she wants to use a CMS (not a particular CMS -- just any CMS) because she's "more comfortable" with it. The client's IT consultant is strongly backing her up on this.

if they want a content management system for no reason then they should go with one that is extensible, cheap, makes static pages, and has a bunch of people making free extensions for it

MovableType = good

Little bit different slant on the side of caution. I have a client that has a fine dynamic site, but the development company is not as savvy on making SE friendly, organically optimized sites as they are at databases and graphics.

One caution to a client is to make sure the development company they choose is as concerned about search engine friendliness as they are user and developer friendliness.

As Mikkel knows so well, you can design database driven sites to help in the organic optimization of a domain.

That's what I'm talking about; not that clients should learn HTML, but that it helps them to know what the issues are. Unfortunately, that's far easier said than done.

On our end, we spend a good deal of time "hatting" clients so that they understand the issues.

Terry, in my experience, if you give it the time and effort, most developers can actually do what it takes. They just need to understand the reaons and goals better. I often hear a "ahaa" when developers realize that the requirements are not that strange or even hard to implement.

But anyway, thats beside the topic of this thread - so better stick to it :)

To add to bad reasons for usyng CMS: "Management say we have to have such a thing"! Truely, it happends. Maybe management just came back from a illuminating web-seminar, or was told how great that thingy is from a competitor. In any case, they thnk it's cool and want one too.

THAT is a bad reason! :)

Mikkel, I agree with you totally that developers can do it. I've helped several companies to have the "aha" experience. My point was that some don't and don't have that built into their approach. Fortunately, that's changing, in my experience.

As to topic of the thread, I accept your gentle admonition. ;)

So another bad reason to use CMS is that the developer suggests it, but doesn't provide a clear rationale for why it is preferrable.

Being an informed client is necessary, that's where this Forum and others like it can be so helpful for companies. You starting this thread is a case in point.

...another bad reason to use CMS is that the developer suggests it, but doesn't provide a clear rationale for why it is preferrable.

Perhaps because it increases the bill? ;)

Perhaps because it increases the bill? ;)

My experience is more that some development companies that only develop dynamic websites can by default take a client into something not necessarily needed or best for their situation.

Most companies I've experienced are helpful to their potential clients and will suggest what is best, even if it means they have to refer them out to another company.

I am from that type of company. We tend to only build dynamic sites. So if someone really doesn't need a dynamic site, I would refer them out.