[Zope3-dev] Re: Zope 3 UI

[Martijn Faassen]

Joachim Werner wrote:
> 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):

Randomly commenting where I have something useful to say.

> 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)

Right, perhaps we should put up a wiki page about this analysis so that
people can report things there.

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

[snip]

> 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.

I think this could also be delivered as actual end-user documentation.
Perhaps before the sprint we can decide which particular cases we want
to work on at the sprint. They get together with documenters and interview
the actual implementors of the subsystem to come up with some UI screen
mockups and documentation. I imagine this goes in several iterations with
the implementors. Implementors may be inspired enough to actually 
build the implementation.

I think perhaps 2 pairs could work on it, each pair on a different part of
the UI. They interact a lot with the people at the sprint actually
developing the subsystem.

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

This could be a pair of programmers cranking through the issues.
If they're big jobs, more pairs.

> d) Core widgets and page elements

> Trees and the like; see the Wiki for a list

We need to discuss which ones to focus on for the sprint. For implementation
one pair of programmers. Depending on the size of the basic support issues
in c (sessioning seems another project altogether, and so is i18n) this
could be the same team.

> 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)

It'd be nice if we could actually work towards putting some of their
recommendations into code form at the sprint. Adjusting current views
and forms widgets to be conformant, and adding infrastructure to make
it easier to write conformant views. So I'd split this into one
pair of style people and a pair of programmers (possibly later on
in the week when there's something ready).

> Immediate tasks (to be finished before the sprint):
> 
> - 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?

There's *lots* of interesting UI stuff to be worked out yet in this department,
I think. I think the UI effort is a success if we can turn some of those
component concepts into understandable UIs useful by site managers and
site developers. The UI project could also have a lot of feedback back
influencing the way the component architecture is exposed to these
people, I think.

An important immediate task is to get actual people assigned to these
tasks so they're know who they're working with at the sprint. I'd like to
get the teaming up and pairing up done before the sprint starts.

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

Sessions would be nice to have and depend on, but we can probably not
depend on using them at the sprint. Perhaps this is a good sprint project
quite apart from UI; make sessions work with Zope 3.

[snip]
> 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).

There's a lot of work done by Stephan, me, and lately especially Jim on 
this. This is quite far along but I think could be built on more and more.

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

And should also be possible from the filesystem, at least of python code.
Work has been done about checking in python code from the filesystem
into the ZODB. Managing this Python code TTW is another option (or
perhaps the ability to generate Python classes through the web..).. 
I think a bit too ambitious for this sprint, though.
We can philosophize about this kind of stuff in the evenings. :)

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

This could be debated, but I won't. Anyway, let's not worry about that
implementation issue.

Hope my input was useful. Would be really nice if you could make a nice
wiki page out of it. :)

Regards,

Martijn