[Zope] Looking for Zope vs. Others at-a-glance comparison

[Jason Cunliffe]

> Completely calm and friendly opinions follow...

yes thanks..

> I don't think it's any more difficult to create an attractive
> (graphics-wise) site in Zope than it is with PHP or ASP or plain old
> Apache-served HTML files.  Quite honestly, I'm not qualified to do it with
> any tool. :-)  I get the feeling that a lot of people expect Zope to
design
> sites for them.  Maybe they're expecting too much.  Or maybe I'm expecting
> too little???  Or maybe it's that most of the people using Zope today
(like
> me) are not pretty-site designers, but people that want a powerful tool to
> manage the most important part of a site...content.

I agree absolutely that Zope is on level with PHP, ASP apacheHTML in terms
of ease.
My point is that Zope allows one to create powerful highlevel functionality
at many levels, wrapping, hiding, abstracting, reusing, modularizing things
which potentially could allow graphic designers to jump in and do great
work. But out of the box it does not and for perhaps cultural reasons will
not..Zope is largely based on reusable templates, and chunks of 'smart-html'
better known as DTML.

What Manila has done is to provide some reasonable default templates for
getting useful site development work done 'out of the box' - they have
provided a structure template, and well defined access to changing the
obvious things people want to change.

Perhaps the only product which does for Zope is Squishdot.. and I think that
largely explains why most Zope sites are Squishdot or modified squishdot
sites. I do not believe it is content vs. style.. I really think it is a
matter of Zope programmers working with graphics and web site interface
designers to create some much more accessible site templates. I fear that
without these Zope will be missing a great opportunity to extend itself into
RealWorld web applications. It _has_ the capability but lacks the real
benefits in the zope community 2-way dialogue between content managers and
content presenters. The point of view is wonderful, but rather one sided.

> Zope is not to blame for what people have done with it on the visual side.
> Content is far more important than visual appeal.  I see too many
companies
> (many of my clients) ignoring this and focusing way too much on layout,
> placement of images, colors, cute JavaScript menus and other fancy stuff.
> I'm not saying these things are not at all important.  Browsing an
> unattractive, sloppily layed out site with lots of useful information is
> annoying and distracting.  But it's *far* better than browsing a fancy,
> "attractive" site that has nothing to offer other than sparse information,
> pretty images and slow viewing time.

Yes and Yes.
But be careful not to ignore the implications that the medium is [part of]
the message.
Style _is_  part of the content. Depends on who and what your audience is.
In so far as websites are [virtual] places, the look and feel of the
environment does matter.
Where people get carried away to either extreme they will surely fall off
those edges.

The invisible server-side aspects of sites will only be visible as
experienced functionality by end users.
But  the visible client-side is all they will ever touch. yin and yang.
How they fit together is where the magic lies.

It takes a diversity of talents and perspectives to make this work.
Content not style is a great mantra - but it leads to content without style
[and vice versa] and who wants that?

I did not say it had to be complex or excessive.. Less is more and much
harder to design often.
The problem is that to achieve good minimal design requires a lot of
iterations. People are looking for new interface paradigms and also better
tools to allow them to find them, and subsequently explore them when they
do.

This means tools with the flexibility of zope but not in it its present
state of awareness.

> It's the site designers.  Zope isn't designed for assistance in creating
> attractive sites.  It's designed for creating manageable sites.  It's
> completely up to the designers to make it attractive, using tools designed
> to do so.  Zope (in my experience) does nothing to limit the ability to
make
> a site attractive, but it does do buckets for increasing manageability.

Yes. I quite agree..But why are there no attractive Zope sites?

My argument is that zope does nothing to HELP one's ability to make a site
attractive.
Actually it does limit one's ability. for example look at even the syntax
for making an image object borderless? it aunt obvious.. and it could/should
be part of the image object properties

--or how about a rollover button.. Yes that is a JavaScript problem perhaps,
but what about including that as a BASIC feature of modern websites. But
imagine if that alone was made easier by zope.
Navigation bar objects would be another big plus.
Or how about a web page 'Table object' which made allowed one rapidly to
group and include other zope object in a useful and productive way.

This is not gratuitous graphics this is stuff which is common to most
websites. All the HTML tools do this.
In zope a designer [= end user content manager] needs to be able to work
with higher level tools which function with acquisition just like
standard_html_header etc.

for example [ad hoc]:

1) Create a folder, some a sub folders and 'dummy' dtml documents.
2) Add a navigation bar creating basic links to the above. This would auto
create a set of matching named methods
3) Add a style_object  which would allow one to apply css or similar across
the above. Again auto-create matching named methods in each folder to allow
low level tuning to happen later
4) create a standard_table_object with named areas to allow population adn
linking of HTML/DTML etc
5) Create standard_site_overview document which would link to the above,
including standard_report_methods which would spit out the stats/properties
on each part so you could see each section in a browser but also print out.

As I understand it all the above is daily business in zope, using all manner
of dtml-in and -with, sequence-item iterations etc. But just bundling and
linking these would allow a lot more people to jump and get on with making
great Zope sites.

This is not reinventing Dreamweaver3.
This is accepting that real world work on web sites post-1995 needs the
above to be productive for designers to work well in these environments.

> I'm comfortable that the zope.org developers will agree that their site is
> not the greatest thing on earth, esp. when it comes to prettiness.  It is,
> however, consistent, easy to use, informative, and provides some nice real
> world examples of Zope's power.  Using any of the already available
> calendar-like products for Zope, DC could easily create a calendar to
browse
> through stuff.  Again, it's not a limitation of Zope, the developers just
> didn't do it.

Yes and I am continuously curious why they did not?
Again we can learn from Manila.
When you create a Manila page it comes with instantly usable templates.
Zope only does this for its own management screens which are invisible to
end users.

When you create a Folder in Zope it offers you

 -Create public interface
 -Create user folder

And if you select yes you will get 'index_html' and 'acl_users' included..
THIS is the entry point I am talking about
The 'Add a Folder' page needs to offer more so that it can default to the
immediate bones of a useful site, methods and links. The irony to me is that
such a feature would really show off Zope strengths and save a mountain of
time. It would allow many other skilled people to jump in and do some great
work .. Hell it would help create new work for zope programmers.

People would pay for useful modules like this because they would save
valuable time adn still leave the source open.
best of both worlds.. could be loaded could as .zexp and off you go..

But because of the steep learning curve of ZopeDTML and resistance of Zope
programmers to 'visual design' discussion.. they are short changing and
ducking the real gain issue = 'project workflow' which is the backbone of
content management.

> Perhaps your use of External Methods is because you should not have been
> trying it in DTML in the first place.  I have seen so many times DTML used
> for things it just wasn't designed to do.  After all, it's not a
programming
> language.  External Methods, Python Methods, ZSQL Methods and all the
other
> methods are there for a reason.  To each its own purpose.

Yes this is true.

> > So may question is was not:
> > - "What comparisons should I have made 12-18 months ago?",
> > but rather:
> > - "What is presently the state of play in Zope vs. Other Alternatives ?"

.. and the chart Nils pointed me to at http://www.camworld.com/cms/ is very
good start
It has some holes, but is in the right direction.
I would love to see an interactive version on line at www.zope.org so people
could add their opinions and expertise.
I would love to hear from DC & Zopistas on this.

> I rant about the powers of Zope while admittedly not knowing much about
the
> alternatives for comparison.  I do know, however, that Zope is powerful
and
> has been loads of fun to work with.

yes SAME HERE :-)

cheers
- Jason