The problem with Dreamweaver as a CMS

I’ll try my best to promise that this won’t become a Dreamweaver hater’s blog. (I already wrote about some discontents earlier.) But as I’ve been learning about CMSes, there are some things that I wish that Adobe would invest in and improve upon with the Dreamweaver/Contribute combo.

Not built for scale

The fundamental problem with Dreamweaver rears its ugly head when you have a website that’s more than 50 pages, give or take.

Dreamweaver Templates (DWTs) power the CMS-like abilities. DWTs have all of the logic and functionality that you need to build the presentation layer of your website. All of this extends beautifully to Adobe Contribute, which is an arguably one of the most friendly CMS tools for business users. The integration really is there.

But it all breaks down when you need to maintain one of these sites based on DWTs. I work for someone whose site is nearing 500 pages. All pages are based on at least one DWT. Some are based on mulitple templates (through the use of nested templates).

Now what happens when I need to make an update to the base template?

• Dreamweaver downloads each page individually.
• Dreamweaver updates all of the pages based on the template change.
• I then need to upload all of these files back to the server.

This process takes up quite a bit of time, and Dreamweaver doesn’t let me use the program for anything else while it’s going through this painful process.

Also, with this out-of-sync nature of dealing with the web pages, it’s hard to avoid having to do a weekly download of the entire website just to avoid mistakes caused by your hard drive not being in sync with the server. Inefficient.

InContext Editing masks the problem

I was excited to see some buzz around a Dreamweaver-friendly service from Adobe called InContext Editing. With this service, users can do Contribute-like tasks from within their web browsers. And the editing tools look pretty damn slick if I must say so myself.

Once you look under the hood a little though, you’ll see that this just extends the problem even further. InContext Editing works by posting even more files to your web server. So the DWT problem is still there, and InContext Editing posts even more files to the server that you need to maintain.

Dreamweaver’s strengths make this problem even more disappointing

I wouldn’t be so sad about this problem if Dreamweaver and Contribute didn’t have so many strengths.

The WYSIWYG editor included in both pieces of software is one of the best out there in terms of standards compliance and user friendliness. Sure, there are browser-based editors out there, but none of them come close to giving you that true in-context WYSIWYG feel that Dreamweaver-based technology does.

I’m also a huge fan of the dead-simple workflow system in Contribute. Users browse to a page, click Edit, make edits, and click Publish or Send for Review. It’s so easy to enable less tech-savvy users with so little training.

Macromedia added additional server-side processing to Dreamweaver and Contribute with their Contribute Publishing Server. You can basically use it to tie the whole system into Active Directory and can write your own server-side APIs to be fired on select publishing actions. But even with those additions, there is plenty left to be desired in terms of managing the actual content.

If Adobe could create a system with server-side templating and a few more features that made the management of content and website structure easier, they’d have a hands-down winner. Until then, we all will either need to invest gonga-dollars in a good server-side solution or put up with unusable crap like Drupal and Joomla or the other substitute teachers of content management out there.