Fog Creek Software
Discussion Board

Knowledge Base
Terry's Tips
Darren's Tips

The Middle Earth of Template Authorship in CD

This is a moderate diatribe on what I consider to be significant constraints in Template Authoring in CD. If you care to read my comments below, please bear in mind the following:

1) I LOVE CD for what it is, but I need it to do more. I applaud simplicity and feature focus, but sometimes, less is, well, just less than needed;

2) I am a former C++ class library developer who embraces the relative simplicity of HTML and CSS;

3) I am sick of wrestling with tables and CSS to get the consistent presentation results I need, especially when all I want is a reasonably simple—and consistent--layout of headers, footers, image captions and div/column/row margins and nav links;

4) OK, Some of this has already been voiced in this Forum before, perhaps better, but this is my chance to blow of a little steam and try to solicit useful feedback.

One of the nice things about CD is that it leverages a database to store elements in the design phase and publishing phases. Being this is the case, then, why can't Template Authoring in CD be more flexible?

Just to be clear, I am familiar with WYSIWIG editors (ala FP and DW), Stylesheets (CSS1/2) and all the religious views of keeping content and presentation separate. I have read most, if not all, of the threads at this forum and elsewhere about keeping CD simple and focused on CM.. All noble and based on experience and reason.

Yet, all that not withstanding, I still need some expanded presentation and field options in the next release of CD.

I have come to the conclusion that doing basic things during template authoring should not require leaving the consistency and comfort of CD.

From my perspective, if all I want is to do is choose fonts and simple page positioning of elements--and get predictable and desirable results--do I really need to depend on bloated and complex WYSIWIG package or the syntax and nuances of CSS?  Yes, Notepad can be bliss, and the mountains of tags and “flexible” syntaxes can be enticing to experiment with and use. And yes, I have also tried cutting and pasting from Excel, DW, Topstyle, etc. But these "integration solutions" too often leave me more frustrated with their quirks, workaround hangovers, and less-than-desirable display results than I want.

Consequently, I pine about the following, it the hope that I can add to the possible chorus of others who might like to see such issues addressed in a future release of CD:

a) Wouldn’t it be relatively easy but very useful to allow users to have more control over defining custom fields for their content templates?  Having to play with just "Extra1" and "Extra2" seems increasingly constraining. I mean, there is a database under here, right?  (I can imagine that allowing for customization of database fields can break the CD scripting and logic engines as currently architected, but that doesn’t negate the considerable value of such abilities and the need to re-architect to accommodate them.)

b) Why not allow users to store pairs of custom fields and their display attributes? IMHO, Structured Content should optionally include some basic display attributes. Imagine the option of basic text and image formatting controls next to each field during template authoring. Religious arguments to the contrary, sometimes presentation *is* part of the content. As a content author, must I resort to tweaking tags to get my point across?
For example, I want to define four distinct authoring fields called "Topic", "Sub-Topic", "Source" and "Rating". I also want to each with its own distinct font, size, style and alignment on all articles using this template without having to use HTML font tags.

c) Why can template authoring include a simple page layout tool that offers the following three very common and basic presentation options? (Imagine a display page in CD to be a *simple grid* with an optional header and footer, and the ability to add *non-nesting* and *non-splittable* “table” rows and columns):

1. Header: Font Attributes (Family, Size, Color, Alignment) Background Attributes (Color, Image), Margins (Top, Bottom Left, Right), Navigation( Link List, Style, Alignment)

2. Body Rows and Columns: (Family, Size, Color, Alignment) Background Attributes (Color, Image), Margins (Top, Bottom Left, Right), Navigation( Link List, Style, Alignment)

3. Footer: Font Attributes (Family, Size, Color, Alignment) Background Attributes (Color, Image), Margins (Top, Bottom Left, Right), Navigation( Link List, Style, Alignment)

Furthermore, I could put CD scripts and variables in any of these elements. No, this wouldn’t satisfy every need, but I would argue to hold the line here for now. Yet the new line would be a huge improvement in templating.

So, in summary:

I don't think that a simple Content Management System should restrict itself to managing pieces of text, image files, and pre-set fields--especially if it is built on an inherently flexible database.

I don't think that reliance on other packages for common template authoring such as the editing of character, paragraph and table formats works well for Joe or Jane Average.

I do think that between those people that get the results they want using the most basic features of CD, and those that are nimble with adding their own tags and code or tweaking third-party generated presentation markup, there is a large pool of people--like me--that want CD to drop the purist CM view and start adding presentation features and field customization to template authoring that we can depend on.

Ben Meiry
Wednesday, December 10, 2003

An ammendement to my suggestion to add an ability to template authoring for simple layout of page headers, footers and body rows and columns:

Essentially I am advocating optionally using a "Body" divided in to an optional header, optional footer and optional number of rows and columns. The body would be a table with the following sets of options:

2.a) Body Table : Rows and Columns (Number of each, e.g. 3 rows and 3 colums), Default Font (Family, Size, Color, Alignment) Default Background Attributes (Color, Image), Default Margins (Top, Bottom Left, Right);

2.b) Table Cells: Name of each cell ("Rn,Cn" by default), Cell Content (free-form text and/or images, HTML, CD scripts and variables...), Font (Family, Size, Color, Alignment) Cell Background Attributes (Color, Image), Cell Margins (Top, Bottom Left, Right);

The UI for this can be text based and fit in a window with two tabs for Table and Cell Definitions:

The Table Definition Tab has simple selection and input control for the attributes listed above for 2.a

The Cell Definition Tab auto-generates a list/matrix of Columns and Row elements when swithching from the Cell Definition Tab. Each cell element listed allows for editing of cell attributes as listed in 2.b above.

Font [Arial, 12pt, Blue]
Margins [Top:10, Bottom: 5, Right:8]

CellLabel:[Publication Date]
Font [8pt, Blue]
Margins [Bottom: 10, Right:8]


Additionally, Cell content overflow can be automatically handled by optionally allowing for cell merging and respecting specified (or default table) alignment.

Anyway, this seems to make sense to me. Perhaps it might to you as well. At the least, I hope it generates some additional useful discussions at this forum.

Ben Meiry
Wednesday, December 10, 2003

OK, at the risk of turning this topic into my personal blog, let me add also that by "cell lables" listed in my examples I mean as to appear in the content authoring screening, not on the template output:

Article1MagazineName [  ]  - this could be defined in the template as R1,C1

Article1Author [  ]  - R2,C1

Article2PubDate [ ]  - R3,C1

Article1Title R4,C1-C2 - A range of columns to indicate cell merging to an html or css processor?

Article1Text [ ] R5,C1-C2 

Sidebar [ ] R4-5,C3

Ben Meiry
Wednesday, December 10, 2003

Perhaps also viewing a CD "Page" as a grid allows to combine easy layout options with addition of custom field options: Cells=CustomFields; CellNames=CustomFieldName

Example, if I specificied a BodyMatrix of 3 Rows and 3 Columns, then if Cell R1C1 is called "MagazineTitle" with some associated font, aligment and margin attributes, then $.MagazineTitle.$ = "CondiNasty" would work and display as attributed.

Now I have surely made the content and presentation seperatists sick..

Ben Meiry
Wednesday, December 10, 2003

If all these requests weren't enough, I would love to see CD auto-generate all the HTML,CSS and Access entries from the "BodyMatrix" definitions configured on my suggested "Tabs"

Ben Meiry
Wednesday, December 10, 2003

It sounds to me that you can get a lot of what you need from FrontPage.

The way I work is a lot different from the way you would want to work.  That is probably true for each of us.  Maybe having some way to hook CD editing for articles into the user's choice of editors would go a long way toward giving each person the choice s(he) wants?

joel goldstick
Wednesday, December 10, 2003

I've read your posts twice, and I still can't understand what you want.

It's pretty easy to create a template in CityDesk. It's just HTML, with CityScript variables showing where you want various fields from your article to go. You can then use CSS to control the formatting of the various table cells.

The thing is, you only really create a template for your site once. You might occasionally tweak things, and once in a blue moon you might totally redo your template. But most of your time is spent in the article editor.

For those people who don't know HTML and/or CSS, or those who don't want the hassle of creating their own templates, there are quite a few sample templates that users have written and made available for others to download.

Darren Collins
Wednesday, December 10, 2003


I bought one there for $9.99 nice.


john cesta
Wednesday, December 10, 2003

If CityDesk aims at small businesses, as I understand it does, then the html option for creating templates clearly falls short, as small businesses probably don't have sufficient knowledge in this area in house.

On the other hand, hooking the Frontpages, DW's and Golives of this world into CityDesk offers no solution, as small businesses lack the necessary expertise for using these advanced tools as well.

Small businesses usually solve these internal shortcomings by cooperating with other small businesses - forming network company's is how we compete with larger businesses. So they could outsource the more creative design aspects of their site to a specialised company. But CityDesk still has to overcome some barriers with respect to remote management of templates, and untill this is the case, outsourcing is not as effcient as we would like.

So, yes, IMO there is room for something in between, Middle Earth, as Ben suggests. In fact, isn't this precisely what the germans are offering at Their table based approach not only solves the instrumental problem for small businesses - how to make a html template, how to use Dreamweaver for templates and then integrate the CityDesk logic - but also the creative problem - how to make a good looking and effective site.

My prediction for v 3.0 is that we will see a move in the direction of Middle Earth, or upgraded remote management facilities. Or maybe both. Well, in twenty days we will know more.

Ruud van Soest
Thursday, December 11, 2003

I think the way CityDesk will evolve will be that more commercial templates will become available. So your small business can buy a template they like for $50 or so, and then use CityDesk to personalise it and add their content.

You (generally) only design your site once. Most small businesses would be happier buying a professional-looking template than trying to cobble together their own design, no matter how easy to use the design tool is.

Darren Collins
Thursday, December 11, 2003

Darren wrote:

"You (generally) only design your site once."

Three points:

1) My experience with non-profit, small-business and other "small-scale" websites is that they are generally not designed once, but require interatation. In many cases, I find that the smaller the organization is, the less standardized the content is, and more iteration is inherent.

2) There seems to be a misconception that one template can do it all for even a small website. Nonsense. Even if a small business manages to find and acquires a template that fits there needs sufficiently, they are dependent on futher services from  the template developer or third-party consultant to customize the template as needed. If all a company wants to do is change the font face and aligment of article titles, let alone add a new row or column to a table, they either have to have in-house expertise in HTML/CSS or outsource it. This seems to me to be less than an optimal way of working with templates.  And what about if I want to use two different content-type templates on a site. To take a not-uncommon example, let's say I found a template from one firm that does a basic article browsing layout nicely, but then I need to use other templates to incorporate newsletter enrollement and forum discussions. It would be nice to have all these templates look similar and work similarly. This integration will take time and expertise. It is not a one-shot deal.

3) There seems to be another misconception that people would prefer templates to doing it themselves. Actually, I think people often have very simple needs for designing consistent tabular page layout, and they would love to be able to do a simple tabular layout themselves, if it could be done. This is not different than having basic report layout features in MS Access.  Forcing them to buy templates for getting this because CD doesn't support is
unfortunate and frustrating. I would argue that the more basic CM design features are dependent on third-parties, the more complex, not less complex, the effort becomes to develop and maintain sites become. Just one common example: if a table doesn't look right after I publish from CD using a template, who do I contact for help? FogCreek? The template maker? Also, when working with non-integrated approach to layout and content, there is less clear UI support between plugging-in content entities (titles, articles, etc., to the templates layout pieces.

The difficulty in all of this, IMO, is that layout is not centralized in the CM package but delegated to third-party tempates or free-form HTML/CSS editing.

Again, I am advocating that CD include a simple ability to define a tabular layout grid to a page template, to be able to assign names to each grid element, and then assign content and formatting to each named element. If we had this, then template makers can focus not on offering basic canned layouts, but on easier ways to add database and scripting logic to layout components.

Ben Meiry
Friday, December 12, 2003

Maybe what I am asking CD for to create content-to-table layout feature is really just a generalization of the "Calendar" table tools already being offered by several CD users and discussed elsewhere in this forum. Such tools have a simple text-based GUI, and generate a useful content-to-table layout. They don't offer too much yet in they way of layout and format tweaks, but then each cell in a calendar should be consistent, not different. On the other hand, if someone took the calendar tool and added the ability to specify the basic size and format option of individual table cells, and then assign content placeholders (such as CD variables and keywords) to each, that would be very, very useful and go a long way towards what I am advocating. Does this seem a reasonable and doable project? I am willing to work with someone to do it.

Ben Meiry
Friday, December 12, 2003

Ben Meiry :re Three points etc.

Just wanted to add my voice in strongly agreeing with your 3 points and what you're advocating in general. And thank you for articulating your ideas in such clear terms.

David Mozer
Friday, December 12, 2003

Ben, thanks for taking the time to write all that out. I don't really disagree the with basic point: I wish there was a way to turn design dunderheads like me into design wizards. Of course I want CityDesk to help me out. It's been a frequent request from day one.

But with even elegant tools I can tweak a good design template into a horror in minutes and never really understand where my design sense went wrong. All this is in the struggle to produce unique designs.

FogCreek must realize that it's way behind in the race for design software. Instead I think they are headed toward a scripting programmability that will allow a company like telepark or even FogCreek to provide tweakable templates if folks want them. We'll see.

Friday, December 12, 2003

Tk wrote:

"All this is in the struggle to produce unique designs."

I, for one, am emphatically not looking to produce unique page designs! I just want to get my content out with very readable pages that displays consistently as I intended, with clean margins and ungarbled content!  I am not looking to win a design award! To me, the less design the better, but often we need headers, footer, rows and columns to use browser real-estate efficiently and make navigation and comprehension easy.  It seem to me that people and tools make this too complicated to achieve!

Almost every page I have ever created has three simple components: a header, body and footer. Within the body, I often want to put different parts of the content into different rows and columns. I decide to include formatted text, URL’s and images in any of these, as needed.

This means that the body is easily understood to be compromised of a simple matrix:
Header, Content and Footer Cells.  Obviously, I want basic control over the size and format of the cell content. This is basic stuff! Is this not 80% of what template (if not all web page) developers are doing?

So, all I am asking for is the ability within CD to specify for a template a simple grid within which I can format individual cells and assign $.content.$ and {scripts} to them.

This does not require a fancy WYSWIG capability! This does require CD to provide a simple UI to assign header and footer content, and simple controls to define number of rows and columns, with options to format and assign content to individual cells within it.

I wish I had the time to take what Ken did with CalendarCty.exe and on my own create a more generalized version called LayoutCty.exe. Then maybe what I am trying to ask for would be clearer and more justifiable to others.

Ben Meiry
Friday, December 12, 2003

Fog Creek provided a hugh service by stepping-back and distilling the basic requirements of publishing articles on the web, and then implementing their insights into the simple UI we now see in CD. What I am advocating above is that Fog do the same for basic page layout, which, as I have tried to show, can be distilled down to the basic header, body table, and footers. As Fog knows, simplicity can be very powerful. If they take the responsibility of enabling and ensuring the reliable, consistent and clean rendering of basic layout element--in the form of headers, body cells and footers--they could pontentially leave many fancier design tools in the dust for everyday design of universal content publishing.

Ben Meiry
Friday, December 12, 2003

Ben, I think I finally understand what you're talking about. It could sit comfortably alongside CityDesk's current template tool - you could either define your own template using HTML, or use the Template Wizard to create or modify a simple layout that has a header, 1-3 columns of body, and a footer.

You'd specify what fonts and sizes to use for each cell of the template, what text and background colours to make each cell, whether the cells have borders or not, maybe set a background picture, and stick variables, article fields and/or scripts into the cells.

It'd be nice, even though I doubt I'd use it much myself. But I can see how it would get a lot of small businesses up and running very quickly.

Darren Collins
Tuesday, December 16, 2003

Bingo. You got it. Now if I only had it. I wish I knew how to progam it myself. 

(I should would also want to integrate to hook-it in as a "plug-in" to CD so that so that 1) each generated table cell could be named and either assigned a value through a more dynamic tabbed article interface or alternatively assigned to and referrenced by a $.variables$.)

Ben Meiry
Friday, December 19, 2003

*  Recent Topics

*  Fog Creek Home