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

Grégoire Weber gregoire.weber@switzerland.org
Thu, 05 Jul 2001 15:50:16 +0200


I just forgot to cc to the cmf-list. As every time :-(.

Hi all and especially Jon and the rest participating this thread!

> Warning : What follows is very long, cos I've tried to explain how we do=
 it
> now, and how I think it should be done (or how I intend to rewrite it)
Phuuu!

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)

Your text contains a lot of good thoughts. See my comments on
some of them.

> [...] trying to produce a spec for a "portal_CMS" tool? [...]
Hm, good idea! Here on the mailing list?

> -----------------------------------------------------------------------
> Layout choice -
> [...]
> [...] but with the ability to tweak them if necessary.
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.

Have a look at http://cancernet.nci.nih.gov/usability/#look_and_feel
There is a comment to this covered at the point "Be consistent".

My opinion: As manager of a portal you have to ensure usability and
that usability can not be destroyed or lowered by members.

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


> -----------------------------------------------------------------------
> Stylesheet -
> 
> [...] different sections of your site can have different layouts and
> colour-schemes, but you can still inherit things like headers or news-box
> from higher up, giving some consistent elemnts across all your
> "sub-portals".
This seems to me to be an important idea. We should note this as 
a requirement for "the spec" we write (possibly)!

> -----------------------------------------------------------------------
> [...] composite docs
> created anywhere on the site would be included in the picklist (perhaps=
 with
> some filtering according to what section you are in, and what permissions
> the page editor has?).
... and the role this composite doc plays in that section 
(better word: context?).

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.

example: A member of the PR department of an organisation writes a 
press report. He wants his report and additional texts and linklistes
to be mentioned in the news section of the org. My "vision": He writes 
his press report, collects his links and additionaly writes a short
summary with a title for the news item. The whole thing is one peace 
of content (=composite content) showing up in the news section with 
the summary, the summaries title and a link to the same item in the
press room. There you see the report with additional links to the 
news item, the link list and the additional documents. In the link 
list section (ok this is silly) of the org these links are listed but
with hints (in the form of links) to the other parts of the composite
document (aka content).

> -----------------------------------------------------------------------
> Gregoire, I think this solves the problem you mentioned for "portals=
 within
> portals", where you want some content to be "syndicated" within the site,
> [...]
Implementation detail: For the moment "real world" topics ar represented
by cmf-topics and organisations/suborganisations represented by cmf-members.
It's a kind of matrix.

Pros: I can use the CMF out of the box after making some minor tweakings
      on skin layers
Cons: The organsisations can not have theyr own members.

> -----------------------------------------------------------------------
> Introduction -
> [...]
> To improve the structure of it all, I wonder if we need an extra object -
> something like "Content-object-style"? Describes how a content-object=
 should
> be displayed in a particular context, just as a CSS-style describes how a
> chunk of text should be displayed in a particular context. You'd use=
 these,
> somehow, to define how content-objects should be displayed in composite
> docs/layouts. Another half-baked idea! :-)
See above at "[...] composite docs", I think we talk about the same! We 
have to bake a little more here!

> -----------------------------------------------------------------------
> <Example>
I've tried your example and it's nice. The Java-Script-Editor is cool! 
I restored the previous values.

> -----------------------------------------------------------------------
> In terms of the "portals within portals" issue, the one thing I haven't=
 done
> is the ability to restrict searches to sub-portals only, rather than the
> whole site (this would also apply to the news_box). There was a recent
> thread on this, but I haven't tried any of the suggestions yet. So if=
 anyone
> has tried them and found one that works nicely, I'd be glad to hear!
Implementation detail: Because the subportals are represented by members 
in my implementation it's easy for me to restrict searches to subportals only.

I'll give a hint (link and access) on the mailing list when I have 
something to show.

Greg

P.S.: Perhaps we should change to a better e-mail subject!

_____________________________________
Grégoire Weber
Rigistr. 31
CH-8006 Zürich
Switzerland
phone:  +41-(0)1-361 66 11
mobile: +41-(0)79-44 11 457
mailto:gregoire.weber@switzerland.org