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

[Michael Bernstein]

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
> database/web environment. On first consideration this seems to be something
> very desirable especially for end users. The problem of content management
> in web applications is present in other web application servers as well.
> Therefore various wysiwyg environments have their own solutions for this
> problem. Just some examples I happen to be acquainted with:
> - dreamweaver makes a difference between editable zones and ineditable zones
> in html;

If you want it to. Otherwise you can leave everything editable. It also supports
merging XML data into templates to create pages.

> <stuff on homesite and frontpage deleted>
>
>
> 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.

Dreamweaver was specifically engineered to avoid this problem. The only thing it
does in this regard is fix syntax and nesting errors, and even that can be
turned off easily. It most certainly does not mangle your HTML.

I still have nightmares about a twelve hour session with Frontpage, trying to
get it to not mangle my javascript and move it out of the head and into the body
of the page <shudder>.

> 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.

Yes. An ideal environment needs to display:

A) source of unrendered code (in multiple files)
B) source of rendered page (usually obtained by 'view source' now)
C) A wysiwyg view of the rendered page.

It would be _very helpful_ if changes in B and C were back propagated to A. It
would also be helpful if when I highlight a section in any view, the relevant
portion was highlighted in the other views as well.

Now, let me clear up some confusion about what I want _as a designer_:

At no time was I advocating this type of setup or any other WYSIWYG environment
as a method for adding or editing content. I was describing what I believe to be
an ideal environment for designing and editing _layout code_, which is what
designers are most concerned with. And many design mistakes can only be easily
corrected from within an unrendered source view. For example a munged layout due
to a closing </td></tr> improperly nested within a conditional statement.

Content should be added and edited from within the web browser. Period.

> 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.

Exactly. But until XML and XSL are more widely deployed, code and layout cannot
be as easily separated from each other as content can be from them both, using
current tools.

<idle_speculation>
Hmm, perhaps the solution lies in creating some type of 'layout-only' object.
</idle_speculation>

> 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.

I absolutely agree that adding and editing content should be done strictly
through a web interface.

> <justifications for using a web interface for content add/edits deleted>
>
> 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.

It would be useful if it were as easy to construct add/edit interfaces outside
of the mgmt. interface.

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

I disagree. Designers need visual tools to be as productive as possible, and
they will have them.

> 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 believe that in the short term, extending Homesite and Dreamweaver to
understand DTML and access Zope directly would be the most productive avenue of
exploration. Dreamweaver can be extended via a published API that someone posted
to the list recently, and there is an interesting article in the October
WebTechniques about doing so with Java, so perhaps it's possible to extend
Dreamweaver with Python as well. Homesite can also be extended, using VTML
(Visual Tools Markup Language), but it has the disadvantage of belonging to
Allaire, a company who's main product (ColdFusion) is competing with Zope.

Interestingly, the guy who originally wrote Homesite, Nick Bradbury, is
currently working on a CSS editor using Mozilla's NGLayout engine for the
wysiwyg display. It will integrate and replace Homesites CSS editor when
installed if you have Homesite, or work as a stand-alone editor otherwise. It's
called TopStyle http://www.bradsoft.com.

In the longer term, a completely new class of IDE needs to be created that
allows for changes in all three views (unrendered code, rendered code, and
WYSIWYG) to be reflected in the others transparently. The first example of such
an IDE that I've seen is Netscape Application Builder (NAB) which is
unfortunately is not only Java and EJB specific, it's Netscape Application
Server specific. which is why no one other than NAS users has ever seen it.
WebDAV will help bring this about eventually.

But I have seen the future, and it has three views.

Michael Bernstein.