[Zope3-dev] UI effort at Sprintathon

[Joachim Werner]

Hi!

> You note in your wiki post (thanks for writing that up!) that:
>
> """
>   ZopeUI will focus on UIsx that are built for modern web browsers
> (mainly MS IE 6.x and Mozilla/Netscape).
> """

> Alas, I don't think there is agreement on this point in the world of
> Zope 3.  (Note I'm not giving my personal opinion, just gauging the
> collective opinion).  In fact, there isn't even agreement to require
> CSS.

I have been one of the "no Javascript, no CSS" guys for years, too. I still
think that writing tools that only require basic HTML in the GUI is a good
idea and a nice challenge. But to compete on the market (and that's what it
is about for us in the field), we need a better UI than anything that can be
built using pure HTML only. And while the old Javascript or Java Applet
stuff really was a pain to write and to use, more modern approaches are
really beautiful. Plone already makes use of some of this new elegance
(which doesn't necessarily mean that I visually like all of Plone, but
that's not the point).

We don't have to do the bells & whistles first. We can accomplish a lot with
good old Netscape 4.x-compatible HTML. And probably we should keep some
compatible UI for the next couple of years (i.e. until when the last
Netscape 4.x dinosaurs become extinct). But it would be a catastrophe for
Zope 3 if that was all we have in the long run, and even worse if the whole
thing was so much focussed on the good old REQUEST-RESPONSE model that we
can not make use of the cool stuff.

So, even if it is hard for the developers, they (we) should try to at least
look at the new possibilities (and kepp them in mind) and make sure that
there is no code that depends on passing back an HTML page (like the current
copy&paste or delete stuff).

> I personally don't think that the collective can yield an exceptional
> UI for Zope 3.  An adequate UI, perhaps.

Well, yes ...

> Rather, I think someone with vision and determination will have to step
> in, to create something that is likely to be rejected by the hard-core
> geeks, but wildly embraced by the actual audience.  In fact, resistance
> from the hard-core geeks might actually be proof that it is going in
> the right direction. :^)

The problem is that this is not only about a UI, it is also about a view of
how the web (and web applications) work that might be a bit old-fashioned.
If I can just drag&drop-build my new web application form with Microsoft
ASP.NET, why should I go back to hard-wired HTML forms just because that
Zope thing doesn't have anything better for me?

Zope is loved by the masses (o.k., not masses, but it's a crowd already)
because it makes web development faster and easier. But for a lot of things
(like building complex UIs) this just isn't true any more ...

> I'm also convinced that we need a small step first.  I think we must
> ignore Big Ideas (which is difficult for me, because I agree a lot with
> what you wrote) during this first step.  We badly need to get some kind
> of face on Zope 3, in order to start attracting more manpower.

I couldn't agree more that we should start with small steps. but let's keep
the fire of innovation burning at the same time ...

> Accomplishing what you wrote takes talent that isn't currently in Zope
> 3.  We need to get those kinds of people involved.  I'm not sure that
> it is possible right now for those people to participate in Zope 3.

Well, there are some initiatives, not in the Zope 3 core community, but in
loosely related OS projects. The two WYSIWYG examples (Bitflux Editor and
XOpus) I've mentioned will probably both be integrated into Zope-based
solutions. We won't have to do all the low-level stuff on our own. The GUI
will not have to be written by Zope 3 core developers. It will just need the
right hooks in the core to work ...

Another point I'd like to make: Most of the Zope-based CMS have a WYSIWYG
editor. So there are some people around who at least know how to get that
stuff into Zope.

> Porting the ZMI, in a way that promotes tinkering by designers, is one
> possible way to get these people involved.  But the moment they have to
> learn about components, factories, contexts, configuration directives,
> etc. is the moment that developers will have to resume the UI effort.

Yep.

Joachim