Summary

Zope needs to take immediate steps to reduce complexity and encourage simplicity. The current UI experience has been mentioned repeatedly as a prime culprit to understanding Zope. This proposal looks at ways to improve the UI without a major architectural overhaul, and without deflecting from the ZopeStudio effort.

Background

Classic.

XMLWidgets etc.

ZopeStudio.

PTK.

Goals

Zope is managed primarily through a web interface. This approach is one of the great strenghts of Zope, but also an area of difficulty, and HTML GUIs are less expressive.

A proposed upgrade to the current Zope Management Environment (ZME) would have the following primary design goals:

• Designed and documented. The current ZME didn't go through a process that defined its target audience and documented its use. Does anybody really know what the left frame and right frame are called?
• Self-revealing. The ZME should "explain itself" and need little formal documentation. For instance, balloon help can provide cues.
• Attractive. It's easy to overlook the importance of this, but people's first reactions go a long way towards forming opinions and setting expectations. The ZME should have a light but talented web design touch.
• Focused on right audience. This is difficult, as Zope itself has a number of audiences. The ZME should reveal the appropriate level of complexity for each of the target audiences.
• Productive. While the current ZME allows the job to get done, it doesn't go the extra mile to help the job get done efficiently. For instance, Windows apps keep track of the last five things you've opened and make them visible in the File menu.
• Consistent. The current ZME has a very scattered approach to its style guide. Some screens have a lot of help text in an introductory paragraph, some have none. Some use italics for optional parameters, some don't. Some have a paragraph that just ends with a button. Folderish things have Undo but DTML Documents don't.
• Standards-based. The current ZME is aimed at HTML 3.2 with perhaps a very small amount of JavaScript. Are the pages that come out actually valid HTML 3.2? Probably not all of them. Not only does this goal aim to be standards-compliant, but it also embraces more recent standards (HTML4, XML, CSS2, DOM1, PNG, etc.) available in newer-generation browsers.
• Error recovery. Things go wrong. The ZME should make it easier and more obvious about how to recover from problems. Are our tracebacks informative enough? Can we take people directly to the source of the error? Is Undo prominent enough?
• Better writing environment. Zope isn't a fun place to author content. Much of the blame has gone to the TEXTAREA, but there are numerous ways to imprive the experience for authoring.

Additional, secondary goals:

• Customizable. By suppliers, webmasters, and users (think skins). Also means extensible.
• Efficient. Network, etc.
• Internationalized.
• Targetted productivity. Some things, like working with SQL, are hard and frequent. The ZME should pick a few of these areas and nail them.
• Configuration. The ZME should become the focus for initial configuration of an install and a site. Too much is spread between the Control Panel and the startup files.
• Administration. The current ZME isn't focused at all at making ongoing administration and monitoring of Zope sites very friendly and productive.
• Adaptive. Many interfaces, including Windows 2k and now KDE2, pare down the menus to show you fewer things, but remember the things you've done frequently. They also remember how you've sized things and other preferences, such as letting you hide parts of the interface and bring them back later.

Non-Goals

In addition to listing goals, it is useful to list things that won't be done or things that are out of bounds.

• Violate privacy and security. Many people are rightfully worried about privacy issues, and do things such as turn off cookies and JavaScript.
• Rich IDE. The ZME environment is focused on the range of users from the newbie, through the casual content manager, and into the low end of developers.

Proposal

Here are some scattershot steps.

• Overhaul to better separate and package the presentation. If the ZME was packaged up like the chrome in Mozilla (very clear places for the skins, locale, etc.), then it would be much easier for people to tinker with new ideas.
• Get rid of FRAME. The use of FRAMEs makes for a clumsy environment. Move to IFRAMEs.
• Change to PTK metaphors.
  • No separation between browsing and managing.
• Make document_src visible and editable, to bring in WebDAV.