[Zope3-dev] Zope 3 UI

Joachim Werner joe@iuveno-net.de
Thu, 14 Nov 2002 15:41:31 +0100


Hi!

The zope3 list doesn't seem to work right now, does it?


I've thought about the whole UI thing a bit. Here are some points to discuss
(I'll put it into the Wiki later today):



What different main (and to some degree independent) tasks do we have? (This
builds on Martijns earlier post)


a) Analysis of Zope 2 and other Zope UIs (collect best practices and "don't
dos"); optional (but very useful): Also collect non-Zope input. This could
be a homework. Every member of the task force should (shortly) present a UI
he likes (focussing on what is DIFFERENT rather than on what is common)


b) Use cases, leading to story books (or call them workflows):

- What do the different actors do with the UI?
- What screens are involved? (screens in terms of data requested or
displayed, no look&feel yet)

Prerequisites:
- a list of stuff that has to be managed via the UI
- good basic use cases (e.g. content management, configuring a Zope 3
instance, adding custom content types)
- a basic idea how Zope 3 will work (e.g. if the current tree structure
changes due to the services namespaces, how will that influence the UI
implementation)

Deliverables:
- story books (screen by screen descriptions) of how things will work (at
least for some well-known workflows)
- if possible, basic APIs for that.


c) Basic support

Things like sessioning, i18n support and the like (see Stephan's and my list
in the Wiki)


d) Core widgets and page elements

Trees and the like; see the Wiki for a list


e) Graphics design

- icon sets
- a basic screen mockup
- look & feel for well-known widgets and page elements
- style guide

For Kontentor we just borrowed from Gnome's icons. Having a set of icons and
chrome from a popular KDE or Gnome theme handy could be a good start. The
results would not be very unique, but "nice".

The graphics design team could make use of the output generated by a) and b)



Immediate tasks (to be finished before the sprint):

- Finish the analysis of existing UIs

- Complete the list of useful widgets and rank them

- Rank the list of basic support tasks. E.g. we could run a demo without
i18n, but probably not without a tree widget ...

- Get a list of things that will have to be managed via the Web UI from Jim
or anybody else who can provide it (I don't have a clue what requirements
the Component Architecture imposes. How will components be arranged? I guess
there will be more than just editing zcml files?


Important open questions:

- Do we need sessions throughout the management interface? If not, how will
copy&paste etc. be handled?

- Will we only have request-response type screens (e.g. Click on ADD, fill
in a form, return to main view)? If yes, we don't need an advanced flow
control. If no, we need some concept of "wizards" or mini workflows (e.g.
Click on ADD, choose a or b implementation, get the form specific for your
choice , choose "ADD another one" or return).


Some basic remarks:

- I don't want to have forms code that is hand-coded into management
screens. All forms should be auto-rendered (see Formulator, or for a bad but
working implementation the current Properties sheets).

- Customization must be possible from the Web UI and should survive updates
(see the CMF Skins approach for a basic idea)

- There should be a "no cookies" mode (using URL-based sessions or so).

This is far from complete. But I hope to collect as much input as possible.

Joachim