By devinhedge on

Disclaimer: This is a cross post from the "New Template
System" issues list. It is intended to encourage discussion, not as an
attack on anyone's current implementation.

All,

I just spent the last THREE YEARS figuring out how to "do" themes
correctly. I couldn't ever get the CMS engine the way I wanted it so I shelved
it. Here are my recomendations and thoughts on the matter:

I wanted to approach "themes" from an entirely UNoriginal perspective:
I went back to my high-school days and dug out all there is to know about Newpaper
and Magazine Design. I even talked to Tim Harrower, author of Newspaper
Designer's Handbook. Tim is largely considered THE guru on Newspaper layout
and design. He recently redesigned the Wall Street Journal amoung other. You
can find out more about it on his website.

After several conversations I came up with the following IMMUTABLE law for
internet publishing that almost EVERYONE ignores (except maybe high-end Zope,
Bricolage, Vignette, etc. sites).

Law #1: There MUST be a seperate workflow for design/layout and content creation/publishing.
The folks that do newspaper and magazine design/layout belong to the "production"
department. The folks that actually generate the photos and articles belong
to the "editorial" department. The product of the editorial department
is handed off to the production department for design and layout.

HOW IT APPLIES TO DRUPAL: There should be a strong set of classes that seperate
layout (template engine with one CSS), colour scheme (with a different CSS),
navigation (global and contextual), and content (presumably XML).

Here's how I did it in my CMS:

First: The layout. I developed, per Tim's teachings, a site wide layout. I
then develop module specific blocks (either wide or narrow) with their layout.

Implementation:

Layer 1: Generic SITE WIDE layout. This template, using a template engine, specifies
three areas: top, middle, and bottom. The contents of each blob are pulled from
the CMS engine.

Layer 2: Specifies the content (either static, generically dynamic, or module-based
dynamic) of the top section and bottom section. Another template, is then nested
in the middle section and sent off to the template engine. The middle section
template specifies the columnar layout: two-col left, two-col right, three-col
w/large center, one-col, etc.

Layer 3: The CMS, returns the content to the template engine for each column
based on the configuration stored in the DBMS.

Layer 4: Each module returns its content to the CMS using context data passed
to it.

On the surface, since I haven't really dug into the code yet, it looks like
Drupal is doing this, only merging layer one and two and merging layer 3 and
4. I don't have to tell you there is a significant memory/processor cost to
doing things this way. That is why I favour being able to cache periodic and
static data in generated pages that are pulled directly from a file based cache
in the same way Bricolage and Vignette do.

Second: The colour scheme and textual styles.

Per Tim's handbook and a couple other Magazine books: Drupal.org (the community)
would be wise to develop a design taxonomy of tags. These tags will be used
consitantly throughout the site. It would then be a no brainer to create an
admin module where you could choose your predefined "look and feel",
or have a tabular form where you can edit the colour, typeface, point size,
border, background image, etc. for each text "style".

Implementation:

Layer 1: The site wide skin is applied as a CSS file.

Layer 4: Each module can have it's own unique styles with a configurable CSS

file.

NET EFFECT:

You can now have a site that is consistant, where the layout is independent
of the look and feel. You now have a website that can be "reconfigured"
at the whim of the production manager/art director. You now have a website where
content authors and the editorial staff don't have to care about the presentation
and can focus on quality content.

I'd like to hear if anyone is interested in this. I would be willing to contribute
the layout/look-and-feel classes I already have. I used the model-view-controller
and factory design patterns for the classes. I never implemented the admin side
because I got bogged down in the CMS engine.

Devin.

Comments

devinhedge’s picture

devinhedge commented

Several folks have asked me to elaborate on the idea of a design taxonomy, so
here it goes:

What I call a design taxonomy is really just taking the page layout terms used everyday in newspapers and periodicals to define custom CSS tags. Let me give you an example:

There are generically four levels of design in your average newspaper:

  1. The entire newspaper
  2. Each logical section
  3. Each page
  4. Each element on the page (e.g. a article, a picture, a advertisement, etc.)

Each level has a set of design elements to it.

  • The entire newspaper has a set of typefaces (fonts), a banner, a header,
    a flag (slang for the Newpaper's logo), a footer, a default layout, and (for
    online newpapers) a colour scheme.
  • Each section might have a corresponding set of typesfaces, a header, a footer,
    a default layout and colour scheme.
  • Each page might have a corresponding set of typesfaces, a header, a footer,
    a default layout and colour scheme.
  • Each element would have a corresponding set of typesfaces, a header, a footer,
    a default layout and colour scheme.

Each design element (CSS tag in this case) would override the previous. The
default layout for a page is called a dummy. It is a template whereby elements
can be added while still maintaining the look and feel that the design team
came up with. For a good implementation of this, go look a a paper version of
The New York Times and compare it to the online
version. They are able to achieve this harmony because everything is designed
using CSS, XML, and XSLT.

In the example of an article you have several XML fields:

  • Headline
  • Author
  • Byline
  • Slugline
  • Reviewer
  • Date Authored
  • Date Published
  • Date Updated
  • Date of Expiration (blank means that something can be archived but remains
    in the system
  • Keywords/Taxonomy
  • Summary
  • Article Text (including placeholders for the images and sidebars)
  • Article Images (list of images and pointers to the actual images)
  • Sidbars (pointers to the actual sidebars which are a variation on an article)

The headline field would have a "headline" CSS tag that is configurable
by the design team, along with other tags like:

  • Byline
  • Deck
  • Logo
  • Jump line
  • Cutline
  • Initial Cap
  • Standing Head
  • Teaser
  • Reverse Type
  • Refer
  • Mug Shot
  • Display Head
  • Liftout Quote
  • Liftout Quote Name
  • Loftout Quote Company
  • Jump Headline
  • Subhead
  • Sig

Well... you get the idea. For an example of the implementation check out the
"What is it called?" pages from Tim's
book.
Each Site, Section (Module?), Page (Module?), and Element (Module?) has a stylebook.
In the style book are a set of styles, much like the stylebook and styles in
OpenOffice, that allow
both the author and the production designer to author and present the information
uniformly across the entire site.

To me, having a template manager and a stylebook manager that can be edited
and printed would be ideal. Then multiple people or a single person can work
on a site whereby everyone publishes the same look and feel of the site.

I'd really like to hear back from everyone about this.

Cheers,

Devin.

adrinux’s picture

adrinux commented

Much of what you're saying already seems to be in place, though some themes come closer than others, you'll need to dig in to the code and see if thats true. The one suggestion I do find interesting is that of the design taxonomy. This sounds to me like styles as used from within decent word processors, and of course css styles. Defining a common set of id/class tags to be used by all themes would allow us to expose that to the admin interface. Right now there is no way to alter these things from the browser (though there may be soon), but there has been a movement towards themes using the same id/class names for the same elements, which would is a start towards what you are suggesting.

adrinux
adrinux@ntlworld.com

Adrian Simmons
adrinux@anaath.at

devinhedge’s picture

devinhedge commented

And Lo, on August 10, 2004 thus spake adrinux:

"Much of what you're saying already seems to be in place, though some themes come closer than others, you'll need to dig in to the code and see if thats true."

And thus devinhedge replied with:

I decided to grit my teeth and dig into the code last night. I'm looking at
v4.4.2 now and will look at the CVS HEAD today.

/Me hoping to have someone clarify this. ==> My first impression is that
there is only one level of abstraction in there. I'll call it the "SITE"
level. The current "themes" system appears to be modularized into
an API whereby calls based on the configuration settings are made to a template
engine. The template is sitewide.

When I was developing my own CMS, I deconstructed my pages based on Tim's suggestions
and Dr. Jakob Nielsen's Usability
Studies and more specifically, Dr. Jakob Nielsen and Marie Tahir's book,
Homepage Usability:

50 Websites Deconstructed, which can be purchased
at Amazon.

What I came up with is dicussed in brief
on this site (1)
(2) and is illustrated
on my site.

And Lo, on August 10, 2004 thus spake adrinux:

"The one suggestion I do find interesting is that of the design
taxonomy. This sounds to me like styles as used from within decent word processors,
and of course css styles."

And thus devinhedge replied with:

Yes this is exactly what I am talking about. If you look at Open
Office. It has a a style book. The style book is broken down by groups of
styles (document, section, page, paragraph, etc.). Then inside each group is
a standardized set of styles that can be applied to the text. Since there are
WYSIWYG
HTML editors, it stands to reason that an editor with intergated Stylebooks
could be added into the content authoring pipeline and thus give complete neophytes
a mechanism for creating content that looks and feels the way the design team
designed the site.

And Lo, on August 10, 2004 thus spake adrinux:

"Defining a common set
of id/class tags to be used by all themes would allow us to expose that to the
admin interface."

And thus devinhedge replied with:

Yes, exactly.. there would need to be a set of admin screens that break down
each region of the site into groups and then CSS tags that are configurable
through the Admin GUI defined. The finished product is a CSS file that is then
written to the website and used throughout. Saving an XML version with descriptive
meta-data would be handy for generating a printable Style Guide for users, content
authors, production designers and the lot.

And Lo, on August 10, 2004 thus spake adrinux:

"Right now there is no
way to alter these things from the browser (though there may be soon), but there
has been a movement towards themes using the same id/class names for the same
elements, which would is a start towards what you are suggesting."

And thus devinhedge replied with:

Well, it would take some work. The layout portion would require breaking apart
the current use of templates into discrete regions and such. After that, design
layout and a CSS stylesheet configuration system would need to be developed/refactored
to replace the current system. I realize that would amount to a large undertaking.

Cheers,

Devin.