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