RedDot Best Practices in Template Creation at Summit 2007

Nathan Carver presenting. Talked with this guy many times before. Admits that this is a tough topic as experience with templates is varied.

Prefers div to tables (no surprise there). Dangers of nested containers: more open RedDots and slower publishing (more work to build the page). Let process trump prediction — don’t try to guess ahead of what you think you should build, let the process define it (i.e. you might over-complicate a simple process by trying to be too smart).

Form dot (and form entry) is a double-edged sword. Ideal for power users, but generally detract from SmartEdit. Wiser to avoid.

Consider enabling container outlining to outline containers when you hit the open page red dot. It does introduce extra divs into the template, which may cause conflict with CSS layouts that use the div object and do not specify class or ID.

Red dots on foundation pages aren’t always necessary. Usually, only administrators edit foundation pages. Open red dots work just fine in the containers and provide access appropriately.

In forms, you can make some fields child nodes of the first element (e.g. if given name, phone, and number, make the phone and number fields children of name, and only red dot the name field). Referred to as “mini-forms”.

RedDot is moving away from target containers. Difficut to train end users to use them properly. Publishing doesn’t work as well as with regular containers (different URLs, publication packages). Target containers very useful for photo galleries. Otherwise, stick to foundation pages for nested includes. Page definitions handle the selection much more readily. Use references so users don’t have to.

Start using DirectEdit. Allows users to edit the text without the pop-up interfaces. (Also hides issues with HTML and/or Microsoft tags.) Change the interface to use an ordinary click instead of CTRL+click.

Use square dot (draggable dot) for updating images from Asset Manager.

Show page information in a panel: page ID, keywords, filename, and meta information. Allow editing (if possible) from that panel. We’re close on Rolex, but need some tweaks.

Set authorizations on the start page so the lists are more “personalized” for the level of ability/access desired. (Suggestion: hide administrator pages to content editors.) Also set authorizations on assets (e.g. unable to change logo).

Several others need the ability to do more sub-folders in the Asset Manager, needs to go to n-level. Apparently this will be mentioned in the roadmap.

Putting code in the templates (non-RQL): flyover help (almost working on Rolex), YUI Ajax code for external DBs to not refresh the page (we need to figure this out!). Do not create “fake” red dots. Gets confusing with developers (and RedDot support) because it’s non-standard — use links instead.

Add thumbnails to template descriptions to show a visual view of the templates — easier to choose what’s needed. (Good idea for when content will be building out pages.)