Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app1

Proposals Table of Contents Last edited on Jan 20, 2001 5:37 pm

ManagementInterfaceNG Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the ManagementInterfaceNGDiscussion to make comments.


Martijn Pieters (mj@digicool.com)


Zope is managed primarily through a web interface, the Zope Management Interface (ZMI). This approach is one of the great strengths of Zope, but also an area of difficulty, and HTML GUIsx are less expressive. The current UI experience has been mentioned repeatedly as a prime culprit to understanding Zope.

There are several distinguishable problems with the current interface:

  • The current ZMI didn't go through a process that defined its target audience and documented its use. As a result there is no real focus and there is no set terminology to describe the different elements of the interface.

  • The current ZMI is not very user friendly or attractive, especially compared to competing products.

  • The current interface is very rigid, many people would like extra or different functionality, but the current ZMI doesn't provide for easy extensibility or experimentation.

  • No consistency. The current ZMI 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.

  • The current interface is a bottleneck in the scalability of certain objects, like Folders.

  • Confusing error messages. Apart from the traceback, the exception messages are downright undecipherable for non-python users. Many messages can be made much clearer.

  • The HTML used to build the interface (currently HTML 3.2 with some JavaScript), may not, or is not, fully standards compliant.

  • Currently configuration of a Zope server is divided between the Control_Panel and the startup files.

Proposed Solution

This document proposes to build a new generation of the ZMI, one that at first will run next to to current interface.

  • The interface should be split into several new distinct interfaces, each with its own target audience:

    • Site development

    • Debugging

    • Server management and administration

  • These new interfaces should be 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 new ZMI should have a light but talented web design touch.

  • There should be a style guide for the interfaces, making sure that everything is consistent and stays this way. Components (widgets) can help here as well.

  • Widgets will help make it easy to build a interface. With the widget design scalability should be taken into account.


    The idea of widgets could turn into a tarpit, as it is another level of abstraction. We should instead create an extensible UI facility and let a number of people experiment and deploy various UI ideas.


    We are already doing this; the manage_tabs method is basically a widget. I want this to be more formalized, one should be able to replace the tab widget for example (if it is still in use).

  • Configuration and administration should move to the ZMI, with the startup files merely for bootstrapping. This will also pave the way for binding to multiple ports and ip addresses.

  • More user-friendly and productive:

    • Productive. While the current ZMI 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.

    • Error recovery. Things go wrong. The ZMI 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?

    • 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. Also, users should be able to tweak this by hand.

    • Self-revealing. The ZMI should `explain itself' and need little formal documentation. For instance, balloon help can provide cues.

    • Wizards and other helpful little tricks.

    • Targeted tools, like more useful SQL tools.

  • The new interface will build upon a layer of interface registration, which will provide internationalisation and skinnability. This will allow suppliers, webmasters and users to customize an interface.

  • Standards based, using new standards that enable more effiecient and more customizable interfaces. This could mean HTML 4, XML, CSS2, DOM level 1, PNG, and ECMA-script. Target browsers will be Mozilla (NN6), Internet Explorer 5.5 (5.0 for the Mac) and Opera 4. We may have to scale back a little for IE :).

  • Privacy should be honoured, user settings will be tied to the Basic Authentication credentials, stored in the ZODB. Unfortunately, it will probably not be possible to avoid using ECMA-script.

Risk Factors

  • Older products will have a hard time to follow yet another major change. The skinability, style guide and widget sets should make the conversion easier though.


    Some other risks:

    • Impact on documentation efforts such as the Zope Book, training, etc.

    • We might just ask insiders about usability issues, thus not really discovering usability issues.

    • The tension between different audiences could mean winners and losers. For instance, a productive interface is often at odds with a self-revealing and explanatory interface.


The final version of the deliverables should be available 3 months after the start of the project. Thus, this project should not introduce huge ideas or great turmoil.

This project is not ment to replace Zope Studio. It will be targeted at the range of users from the newbie, through the casual content manager, and into the low end of developers.


  • Three management interfaces, devided along the three target tasks: Development, Debugging and Management and Administration.


    First, I don't think "Debugging" is an interface. I think of the interfaces in terms of the audiences: Business User (i.e. Content Manager), Site Designer, Site Developer, System Administrator, and Information Architect.

    I think the deliverables under this project should focus on a facility for many interfaces, with a new and improved interface geared towards the following:

    • Improve the Business User experience 50 percent

    • Improve the Site Designer experience 30 percent

    • Improve the Site Developer experience 75 percent

    The high end of Site Developer is still reserved for Zope Studio, but Site Developer is the focus of improvement in the UI that will be shipped under this project.


    These interfaces were more based on competing products than on deeper thought. I still do think that there is a place for seperate interfaces, or at least a clear pointer from the entry page where different audiences will have to go for their tasks.

  • A skin and locale registration component, used to determine what interface definition and what locale resource should be used for rendering the interface.

  • A set of widget components.


    Again, I'm leery of this.


    See earlier comments.

  • A style guide for the interfaces.

  • Documentation, in three flavours: End user, Product development and Customisation and Localisation.

View source ManagementInterfaceNG
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org