[Zope-dev] Barriers to Zope popularity: Part 1: wysiwig editi ng

[Paul Everitt]

I think the *approach* of the current Zope management environment has a
lot of things going for it:

  o All functionality is controlled by the server

  o Not just that, but the management is controlled by *individual* 
    applications (e.g. Indigo Networks uses Flash to control Zope)

  o You can sit down anywhere in the world and log into Zope

  o The management screen is "programmed" in a clear-text definition

With that said, I know there are some _severe_ drawbacks:

  o It is an unproductive environment

  o The TEXTAREA is awful for real editing

  o No convenient way to get local data to remote server

There have been some proposals, namely (a) integrating with some
specific tool like FrontPage or Dreamweaver, or (b) creating our own
management environment.  Both of these are bad ideas for one simple
reason: the best tool is _your_ tool, meaning you'll never make a
majority of people happy.

To date our approach has been to support the standards (namely: FTP,
WebDAV, Netscape Publishing, converting to an HTML-like syntax) that
makes integration with _all_ tools more feasible.  I'm increasingly
convinced this will only work at a minimal level: none of them can
expect to capture a sufficient amount of the dynamic capabilities of
Zope.  There's just an impedance mismatch.

Thus, I'm drawn back to keeping the advantages of the current approach
while trying to address some of the productivity losses.

So, here's my suggestion, and I consider it a challenge to the Zope
community at large to do a prototype.  I've tinkered enough over the
last two months to realize it is feasible, I'm just not smart enough to
make much progress.

Imagine a management environment that:

  o Kept everything good about the current Zope "IDE"

  o Was cross-platform

  o Completely controlled by the server, or optionally 
    controlled locally

  o 100% compliance for advanced standards such as:

    - XML, CSS2, XSL, RDF, latest JavaScript, etc.

  o Contained an embeddable, scriptable editing widget 
    with both plaintext and wysiwyg modes

  o Had an XML-based UI language containing platform-native 
    tree widgets, tabbed dialogs, pop-up modal dialogs, 
    object-defined menus, right-click menus, etc.

  o Facility for trusted-scripts to access local filesystem

Given this "platform", a management environment could be 
constructed with some of the following improvements:

  o A real, HTML-oriented editing box, perhaps with some 
    DTML-aware "smarts"

  o A collapsible/expandible view of the object system 
    that _didn't_ go to the server on each click

  o etc.

I'm talking, of course, about Mozilla.  I've been following it very
closely for the last few months, downloading the daily builds probably
three times a week on average.  It's legit, it has a LOT of energy
behind it, and most of all, it's the best shot to keep the strengths of
the current approach while significantly improving the productivity.  In
fact, the same tool, with two different modes/views, can appeal to both
the content manager and the developer.

My challenge: go tinker with some prototypes.  Write some XUL files that
populate a tree widget with an RDF source retrieved from a DTML method.
Create a real tabbed right-frame using the tabbed dialog.  Create
alternatives to manage_menu and manage_main that send back XML and CSS2
to cut the http response size in half and significantly improve the
layout.

For a small glimpse of what you can do with Mozilla:

  http://204.107.76.15/pub/

--Paul