[Zope3-dev] UI effort at Sprintathon

[Shane Hathaway]

Martijn Faassen wrote:
> I'd like to suggest we split off a team to discuss and implement
> a Zope 3 UI at the sprintathon; the UI issue seems to have stalled
> and we will have some good people with ideas about the UI at the 
> Sprintathon (for instance Alexander Limi). This is not so much about
> a cool looking design but about UI functionality for the various target
> audiences for Zope 3 (ranging from programmers to content managers).

I'd like those planning the UI to think about the following, then.

I believe the key consideration in the future Zope UI should be 
modularity.  Build something modular and allow easy tweaking.  I'm 
fairly certain this is the only way we're going to make a UI that's 
useful for the future Zope users.  (Since Zope will expand 10X, 9 out of 
10 of the future Zope users aren't around yet. :-) )

A counterexample is Zope 2's manage_main, which not only contains all 
the HTML and logic for displaying the items, adding new items, and 
manipulating the items, but also explictly specifies that tabs must be 
at the top of the page and that there must not be anything else on the 
page.  In the future, the folder contents page should be split up as 
follows:

- A ZMI "style", external to the main page, should provide all the 
"O-wrap" (everything on the top, left, right, and bottom of the page) 
and should even have the option of manipulating the HTML in the middle 
of the page.  I've been contemplating a "style service" where people 
would go to design the O-wrap for their apps.  I think this is similar 
to the direction Max M proposed.

- The HTML for displaying the table of items, for adding new items, and 
for manipulating items (the buttons) should be in different templates, 
or at least different template macros.  There must be a way to rearrange 
the page or replace parts with enhanced versions.  I've been thinking of 
Page Designs fulfilling this purpose, but now I see we can simplify 
that: there should be a "page manifest" that does nothing but specify 
what templates to use on different parts of a page.  The page manifest 
should contain no code or HTML, only references to templates or views.

- The style service should also use page manifests.  The main template 
should do nothing but provide a layout--no text or images, not even the 
Zope logo.  The page manifest is where text and images come in.

Consider the UI split between CMF and ZMI.  That split happened because 
the ZMI is not reusable.  Now consider the (slightly weaker) split 
between Plone and CMF.  That happened because CMF didn't quite learn the 
lesson of modularity!

I hope I'm being clear.  Do others agree with this?

> I'm *not* one of the people going to be on the UI team, by the way; I'm a 
> programmer who thinks UI is important, but I'm not a UI designer. I hope 
> someone will step up and be the UI team project leader. Note that this also
> means project leader before and after the sprintathon, not just during,
> unless you can find someone to take over from you.

I wish you guys the best of luck. :-)

Shane