DHTML Editors [was DHTML browsers which was a typo, which had been Accessibility]

I think the post was made only off-list by mistake.  My response is at the bottom.

On Mon, 13 Sep 2004 16:22:27 -0500, Joseph McBride wrote
> This is a scary conversation for me.  We are getting ready to move 
> ahead with documentum.  From the sounds of it, the browser based 
> WYSWIG, if it is inline with the rest of the market is going to be 
> sub-standard.
> 
> Does anyone know of some good sites that offer advice/tutorials for 
> tackling the creation of good templates for CMS? Specifically, ones 
> focused on reaching for a happy compromise between the desire to 
> create XHTML/standards based templates and the mucky WYSWIGS that 
> marry them?
> 
> Thanks!
> Joseph McBride
> University of Texan at San Antonio


> This is a scary conversation for me.

Good, you are starting off with some of the major CMS challenges (at least you
are seeing them in advance of implementation!).

> Does anyone know of some good sites that offer advice/tutorials for 
> tackling the creation of good templates for CMS? 

It gets even more complicated when you want to grant certain users access to
certain fields within a single record, but not others.

I don't know of any resources specific to desiging templates - I would check
your vendor's support site for best practices documentation.  From my
experience it really helps to think of templates as generating content objects
that can be used in any number of renderings, rather than generating pages,
include files, etc.  In fact I think the legacy CMS offerings that focus on
static/page generation should be put to bed - I know I don't think highly of
the technology behind a site implementing .html file extensions.  But you also
don't want to "over-normalize".  I'm not sure if it helps to think of the
templates as database tables, but they do both store records which frequently
have relationships.

That being said, I think it's best to both break up the template and restrict
the WYSIWYG (both buttons and tags allowed in the output) to whatever extent
is possible and reasonable (you will probably have to experiment in your
solution/organization to find out).  Depending on how complex this gets, you
will probably want tabs or pagination in the templating UI so that everything
doesn't appear in one clutterred or long screen.  You also want to set user
expectations - the CMS is intended to enforce both internal and external
standards and avoid the mess of an unmanaged site which is likely what brought
the organization to CMS in the first place.

Spend time defining specific template requirements and developing prototypes
for review by the business users.  General requirements led to the CMS
selection, and if due diligence was done, implementation of detailed
requirements on that platform should be trivial.