[Zope3-dev] Zope 3 Source organization

[Martijn Faassen]

Shane Hathaway wrote:
> Martijn Faassen wrote:
> >A response we could have is to make things easier for programmers, at
> >the potential risk of making things harder for UI designers in the future.
> >Another response would be to try to drag some UI designers into this
> >discussion. The risk there is that it seems to be a very hard thing to
> >do. I'm not sure what that means.
> 
> Speaking from experience: we designed CMF with the intent that UI 
> designers would come in and clean up the unfinished UI.  That eventually 
> happened, but not the way we expected.  We expected gradual refinements 
> to the UI beginning soon after the first release, but we had a hard time 
> attracting UI designers.  Instead, there was a long period (over a year) 
> of hardly any improvements, followed by the sudden creation of Plone.

I'm also speaking from experience by the way; Silva has a separate
view hierarchy. I made sure that such a facility was there from
the beginning, so that Kit, who is not a python programmer,
could complement me in Silva development. This has worked pretty
well. He (and others now, of course) still tweaks the user interface and the 
Python product that is Silva is basically territory he stays out of.

The Silva views have seen lots and lots of incremental improvements,
and in the last half year much of the ZPT code was drastically restructured
for the Silva 0.9.2 release. A recent project that also involves incremental
improvement of the UI code is a 118n-ed user interface, and I do think
having all the view code in one place contributes.

> There might be a psychological explanation for this: it's boring to make 
> slow improvements but exciting to rush in and make something new.  The 
> lesson Zope 3 might take from this is that it should show the UI 
> designer how to make a Zope 3 skin with a minimum of effort.  It should 
> do this primarily by example rather than documentation.

One of the problems that we noticed during the Rotterdam sprint is
that the view people (we had quite a few) tended to get lost in a lot
of Python code. They basically had to go through the Python code
hierarchy before they could enter the views/ directories. We should keep
in mind that it should be instantly obvious without inspection of code
what has to do with the view and what not. In theory at least
view coders should only have to inspect the interfaces and example
views in order to get started.

Of course this (having separate interfaces) contradicts the points I
have been making for quick & dirty development. Interfaces fulfill
another requirement here, that of a stable API and documentation.
What I would like is being able to write code that does not
support this right away, but can be evolved towards it without too
much hassle whenever this is deemed necessary.

Regards,

Martijn