[Zope-CMF] CMF --> CMS (was Re: Our CMF-CMS Demo (LONG!))

[Jon Edwards]

Hi Gregoire,

> I'm feeling now like (sorry, phrase/saying in german with
> translation followed) "Ich sehe den Wald vor lauter Baeumen
> nicht mehr" (+/- translation: there are such a lot of trees
> I even can't see the forrest anymore, meaning: such a lot of
> details and ideas not yet arranged in my own brain
> systematically covering the big picture)

We have the same saying in English - "I can't see the forest for the
trees!" - and I know the feeling. I think that's why my post was so long and
rambling. I need a chainsaw... or a helicopter, to get an aerial view! :-)

> Hm, good idea! Here on the mailing list?

Dunno about anyone else, but I find mailinglists much easier to use than
web-discussion pages or wikis. If something pops into my inbox I pay
attention, if I have to remember to go and look at a webpage I'll often
forget! :-)

I think we're trying to define a set of standards for how different
CMS-tools interact with the CMF? Are we, perhaps, also trying to define a
default_CMS? In the same way there is a default_workflow which can be
replaced with other workflows?

> I'am not a fan of letting 'normal' users tweak their layout.
> Most of them never use it and the rest of them missuse it
> (akward colours, etc.) to show to others the could 'program'
> a new colour. :-( This kind of persons usualy destroy the
> consistence of a site.

Absolutely agree! Two points -

1. You would use permissions to restrict who can "tweak", so that only
trusted editors can do it, or to turn "tweakability" off completely (have I
just invented a new word? sounds kinda kinky! :-)

2. If you have a "Site Styleguide" (see the wysiwyg thread), you can define
an acceptable range of colours, fonts, etc.

> My a little philosophical approach for information portals is:
> Let people define their character by their content not by their layout.

Right, but if you have portals-within-portals, the editors of the
sub-portals will often want their bit to look slightly/completely different
from the "mothership".

< seb wrote >
> There's a reason
> for the client paying someone else to do their design / usability:
> it's not their area of expertise.  Fewer choices, chosen carefully,
> enforces a consistent look and feel and makes the clients'
> content-managing lives simpler and hopefully more intuitive.

In our market, not many people want/can afford professional designers.
RadioUserland and (I think) Blogger have the concept of a library of
readymade layouts/templates which you can pick from and then "tweak" to suit
your site.

<seb wrote>
> How does the skins philosophy fit into this?  As gregoire and ken have
> pointed out...
>
>> IMHO it is important to have different concepts of content storage and
>> content retrieving structures. If I've understood klm's proposal
>> (http://cmf.zope.org/rqmts/proposals/OrganizationObjects)
>> right it's that what he's saying also.
>
>...the folder containment metaphor / structure is very limited.  IMO,
> it's probably a good thing to get away from this paradigm, though
> aquisition / inheritance needs to be addressed in any other
> implementation, if possible.

Fair enough. I considered the possibility that content should perhaps live
in some kind of separate "content repository", but then my brain exploded,
and I decided to keep it simple for now! :-)

I do think though, that the folder/containment metaphor has a lot of value
for the content-retrieval/presentation structure (as opposed to the
content-storage structure).

For people constructing a site, it makes a lot of sense IMHO - most
webdesigners draw hierarchical tree diagrams when first conceiving a site,
most Zope users are familiar with the concept, everyone else is familiar
with family-trees and org charts! I'd like to see it remain as a metaphor
for the "front-end" - the screens that editors/designers use to construct
the site. :-)

> Content-object-style -

> See above at "[...] composite docs", I think we talk about the same! We
> have to bake a little more here!
>

OK, I'm only a novice chef, but here goes :-)

Seems to me that OrganisationObjects define relationships between
content-objects - their "context" in the great CMF scheme? They don't define
the different ways the info is presented within a page?

What I'm proposing is something like the "Presentation Components" in the
Component Model Shane posted -
http://dev.zope.org/Wikis/DevSite/Proposals/ApplyComponentModelToCMF - but
for internal use by the page-editors when constructing their pages, rather
than as views for the end-user.

Using your example - after the PR person has composed his composite
document, there are at least three different ways it could be viewed within
the site.

1. In the news_box - showing the title of the document, which acts as a link
to the full view, perhaps with the last_updated date underneath.

2. In the "What's New in PR" summaries list - showing the title, the
summary-text, the Creator, the date, and a "read more..." hyperlink to the
full view.

3. The full-view - showing the title, the full text, the
"links-to-related-stories", and all the other stuff that you find via the
OrganisationObjects.

I want to be able to define these different views (which don't include the
header/footer stuff that the current view methods do, as I want to slot them
into my page-layout), without touching any dtml, with only a basic knowledge
of html/CSS.

So, if I'm the Site-Editor for the organisation the PR person works for, it
might work something like this (I've described it in GUI terms, cos I'm too
lazy to work out how it could be done TTW at the moment!) -

I open up my CMS software, and the first screen I get is a hierarchical view
of my site (like an org chart, similar to what Frontpage uses?). I've
already created the hompage/root, and branches for Sales, Accounts,
Production, and Personnel. I click the "Add New Branch" button and type in
the basic details for the PR Department branch and click OK.

Now I double-click on the new "PR Department" branch. I see the page-layout
screen for my new branch. The layout/template has been inherited from the
layout of the Home Page (I could change this if I wanted). The header,
footer, lefthand-menu and righthand news_box have also been inherited from
the homepage (again, I could change these if I want), but the central "body"
of the page is blank.

I want the PR page to look the same as the others in my site, so I'm happy,
but I have decided that each Department will have a different
header-background colour, so that it's easier for visitors to work out where
they are.

I rightclick on the header section, and choose "Properties". I click the
dropdown box for "Background Colour" and select a different colour. Because
I had previously defined a list of allowed colours in my Site StyleGuide,
I'm only presented with that list of colours in the dropdown box. I click
OK, and there's my new page/section, ready for some content!

I rightclick on the blank central "body" section, and choose "Define
Content". There's a dropdown that allows me to select what I want to be
shown. I pick the "List latest 10 objects in reverse date-order" method. Now
I have to tell it what to list. I click "Selection Criteria", and I get a
dialog with dropdowns which help me define the underlying Catalog-query. I
select "type" as 'Documents', and "subject" as 'PR' (I could have refined it
with other criteria, but this is a simple one!)

But, after I click OK, the "body" section just shows a list of document-IDs!
The system knows what I want to display, but not how I want them displayed.
This is where I need to define my "Content-object-styles".

I could select each listed document ID, and give it a style. But I want them
all the same, so I select them all and click "Define Content-style" (must be
a better word for this!). My system came with a few readymade styles, and I
can add my own if I need to. A dropdown shows the available styles for the
document-type. I select "Summary" and press OK.

Voila! I now have my "What's new in PR" page, which will be automatically
updated whenever a new document is added!

But, I'm not totally happy with the look, and the "Creator" property isn't
in there, which I wanted. So, I click "Define Content-Style" again, and
click the "Customise" button. I get a dialog similar to the WYSIWYG editor,
with my first object displayed as an example. I can toggle between "Preview"
and "View Source" modes. When I click "View Source", I see something like
this -

-------------------------------------------------------------------
<h3><document_title></h3>

<p><document_summary></p>

<p><a href="<document_url>">read more...</a></p>

<p><small><document_date></small></p>
-------------------------------------------------------------------

I change the <h3> tags to <h2>, then I place the cursor just after
<document_date>, insert a space, then click the "Insert Property" button. I
get a list of properties that the document-type exposes. I click "Creator".
My source now looks like -

-------------------------------------------------------------------
<h2><document_title></h2>

<p><document_summary></p>

<p><a href="<document_url>">read more...</a></p>

<p><small><document_date> <document_creator></small></p>
-------------------------------------------------------------------

I click Preview just to check, then click OK. Without knowing a word of
DTML, and only the basics of HTML/CSS, I've now created exactly the page I
wanted! I make a mental note to send a large cheque to the CMS creators, and
head for the pub! :-)

Hope that makes things clearer/slightly more baked?

Cheers, Jon