[Zope-dev] Barriers and wysiwyg

[Rik Hoekstra]

-----Original Message-----
From: Rik Hoekstra [mailto:fghoekstra@cit10.wsd.leidenuniv.nl]
Sent: Friday, September 24, 1999 11:55 AM
To: Jay, Dylan
Subject: RE: [Zope-dev] Barriers and wysiwyg


[Martijn Pieters:]

> > Zope was designed for Web Application Developers, not designers. The
> > documentation follows this design. I actually feel that
> > dummies should stay
> > away from Zope. Frontpage is for dummies.
>

[Jay Dylan]
> I disagree. I believe the ideal place Zope could end up is as being
> something that was as simple to use as frontpage and as powerful
> as ... well as it already is. I'm not saying that the "simpler" users
should
> be able to as powerfull things as "programmer" type users can but it
should not be
> unaccessable to them. They should be able to edit and add basic
> documents.

Michael Bernstein added in another post that as a designer he needs to work
visually, which is a good point. And he adds another crucial remark : in web
building we wear many hats at the same time. And most application servers
lump all these roles together, while Zope separates them. Many have remarked
that this is the problem of communication between Zope and editors: they
were made with a different mindset.

Uing Dreamweaver or Frontpage (light) or whatever it is quite possible to
add plain html pages and design them anyway you want. You can even manage
them through the web.* Or to once more cite Jon Udell on byte.com :
"It is completely feasible for a novice to download Zope, install it, and
build a simple site -- even one that leverages the object hierarchy to
factor out repetitive pieces -- without writing any code. And the result is
100% Web-manageable."

The point is of course, that you usually do not want this. You want people
who do pure and simple content management to add content, not to change
layout. Much less to go programming DTML. This is what makes editing a ZOpe
site difficult: once you defined behaviour (dtml methods/products) and
layout, you want content managers to add content. The problem is that people
want to see what they get. I think Paul's Mozilla approach is very promising
in this respect. It may even turn out to be an incredible site management
tool. But this will require a _lot_ of work.

On the other hand I question once more whether the textarea is such a bad
idea. It is especially useful if you want to have content managers also
manage parts of a site, without them controlling the user interface. By
contolling a site I mean adding and editing content and users, and folders
and news and all sorts of other things that are not possible to add from a
wysiwyg editor, which is after all just an editor...
In this case (and I believe it is quite common, if only for all sorts of
intranet like activities) even if you could use a wysiwyg editor, site
management for dummies would still be a fragmented (and bewildering)
experience.

I find it most remarkable that the packages I know of (mostly web learning
environments - but they are good examples: blackboard, webCT, TeleTOP etc,
etc) that are meant for this type of site building and maintenance do
exactly this: they keep everything browser based.
I looked into the documentation of Oracle WebDB today and it is exactly what
they do (including the textarea) and what they bring forward as a strong
point of their product. Just one citation from their brochure:

> Oracle WebDB is HTML-based. All that's needed on the client side to build
and run WebDB applications and web
> sites is a web browser such as Netscape Navigator or Microsoft Internet
Explorer. WebDB users benefit from
> quick installation, distributed deployment, and a familiar interface.[...]
> All WebDB site maintenance tools are included within the site itself.
There's no need to leave the site or
> learn how to use another product. To add content, authorized users simply
navigate to where they want to add
> it, switch to Edit Mode, and use the simple interface provided."

The only thing is, to repeat myself, that currently there is no such
standard tool for Zope.

I'm afraid some of the DC folks took this as a criticism - it was not meant
like that. I do not even like wysiwyg for the most part (except for
designing in which case they are indispensible).

I think the Zope interfaces  (from http to xml-rpc) are excellent and
abundant. They are just not for dummies. What we need is a dummy web
interface builder toolkit.

Rik

* Someone (I forgot who, but if necessary I can retrieve the URL) hacked up
a perl clone of the Frontpage extensions so if  necessary this should be
doable for Zope as well I think. The question is just who would want that -
Frontpage is terrible.