[Zope] Re: [ZDP] Wysiwyg and the merits of a webinterface - some considerations

[Paul Everitt]

[I removed the ZDP from the email, as most ZDP people are on the zope
list.]

Rik Hoekstra wrote:
> Once in a while the subject of wysiwyg comes up on the list, as it did in
> the last few days. TO summarize the discussion as I understand it:
> The main problem is that people want a wysiwyg front end for their Zope

Perhaps there's a farther step backwards.  The following people want the
following things:

1) Some need to put the simplest possible tool in their casual users'
hands, such as Netscape Composer.

2) Content managers need a very productive environment for managing
content, including lite DTML scripting.

3) Developers need a productive environment for manipulating the object
model, working with relational databases, debugging problems, etc.

I posit that wysiwyg is definately the road for the first audience.  The
second audience is firmly split between those that want wysiwyg
(Dreamweaver) and those that want to see the tags.  The third audience
almost uniformly shuns wysiwyg.

Even worse, the second and third audience only cares about one tool: the
one that they have already learned.

[very good analysis snipped]

> The wysiwyg approach also seems to have the inevitable consequence that all
> of these editors mangle your html in an inexcusable way - so what you get
> may not at all be what you want.

That's a really, really good point.  I'll steal it. :^)

> There may be other examples which do, but I am not aware of them.
> 
> Zope has some inherent features that make these solutions not adequate, as
> Michael Bernstein (I believe) pointed out. They have to do with the
> difference between rendered documents and source code. This is further
> complicated by the separation of code of and layout as a result of which al
> templates and logic tend to be in different documents than where actual
> textual content is managed.

You've identified one extreme of the problem: Zope is wildly object
oriented and delivers powerful concepts that are quite unique, thus
don't map into traditional tools.  The other end of the problem is that
nearly all existing tools have basic metaphors -- stupid files or stupid
data -- that don't have the semantics of the web object system.

> I have been contemplating this issue for some time now, because it is
> crucial in an academic environment in which all sorts of people with all
> sorts of abilities (not just designers but also 'just' students and teachers
> and secretaries) are going to be giving input to a website. Considering all
> I have come to the conclusion that a webinterface will be the way to go, at
> least for me.
> 
> My considerations:
> - many students are using hotmail. They complain, but that is because of
> slowness and ads. The interface, even if it's nothing special, gives them no
> problems.
> - I have been looking closely at some web based learning frameworks lately
> (because I am building one in Zope). They all promise a complete management
> system for courses and learning material. Some are shareware or freeware and
> some are very expensive solutions. They _all_ have web based interfaces, and
> it seems to be no problem at all for teachers. SOme of them are difficult to
> use, but that's because of their closed nature and their bad organization
> (this in contrast to Zope).
> - browsers offer a familiar environment for almost anyone. They do not have
> to learn another interface if they are editing through the web

This is a crucial point.  Once you leave the browser you make the first
two classes of audience above think too much about the tool.  People
understand browsers today.

> - users/content managers only _have_ to edit content and not need to occupy
> themselves with other issues, which is actually a relief for many of them.
> Zope has the added advantage that it is very agnostic in the integration of
> file types (by which pdf, msword and powerpoint can be uploaded just as
> easily as web pages)
> 
> The only issue at the moment is that the current management interface (while
> it is a pleasure to work with for developers) is not at all useful for
> non-developers.

If the people are just storing documents, our integration with Netscape
publishing is good.  The problem quickly resurfaces when, for instance,
you want them to work with a form that you've created.

> All taken together I do not thing there will be a solution in the direction
> of wysiwyg editors.

There might be, we'll see.

We certainly know that people hate the TEXTAREA.  In our defense, we
have worked _awfully_ hard to support the protocols (FTP, HTTP PUT,
WebDAV) that should allow you to use other tools.

> Instead I would plea for the development of a toolkit for end user web-based
> editing environments, as I believe many of us are developing them at the
> moment. Is anyone interested? Ideas? Comments?

I'd love to see someone come up with a professional statement of the
situation -- problems with current, strengths of current, goals of
future, and requirements of future.

I'll confess that I've spent a lot of time looking at Mozilla over the
last two months.  I've formed a mental model of how an incremental
improvement in the environment could have a significant improvement in
productivity.  I haven't yet put my thoughts to writing though. :^(

--Paul