Note - this document is still a work in progress. Please do not make inline
comments in the proposal - use the ManagementInterfaceNGDiscussion to make
Martijn Pieters (firstname.lastname@example.org)
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
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
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
Currently configuration of a Zope server is divided between the
Control_Panel and the startup files.
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:
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.
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
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.