[Zope3-dev] DISCUSS: Consolidation of Zope 3 UI wiki pages

[Joachim Werner]

Hi!

Sorry for being "late" with entering this thread. But my "reading time" is
somewhat limited ...

> I have the exact same worry as you do, Paul; as it looks now there'll
> be some UI guys getting together rehashing how much of DHTML/stylesheets/
> mozilla/etc to use for Zope 3. This could easily become a 5 day
> philosophical session. That is not good.

I think we need a "philosophical" session to some extent. We need a
discussion on WHAT Zope 3's vision WRT UIs will be. But I agree that talking
about the technical details (like using Mozilla XUL stuff or not) is not
really what brings us forward.

Still, if you want to build a cathedral, you'll need to start with the
foundation, even if you want to do it in the Bazaar-style ;-)
Look at the Leaning Tower of Pisa to see what happens if you don't take care
with the foundations ...

> I introduced the UI group because I think a good UI for Zope 3 is
> important. While Zope's ZMI has many limitations, it does provide for an
> easy entry into Zope and I think is responsible for a large part of it
> doing well with non-programmers.

Zope's UI was the No. 1 reason for me to become addicted. At the same time,
if I had known then how much more efficient file-system-based development in
Python (compared to ZClasses/DTML) can be, I would probably have spent more
time in the file system ...

> I had hoped someone would step up to lead this effort, but nobody did.
> Perhaps we should cancel it and move the people into some other project?

I can take over that topic if I have to (i.e. if nobody who can do it better
steps in).

But I also want to keep in touch with what is going on in the CMS part of
the Sprintathon.  If this turns out to be a problem I'd rather do the CMS
part only.

Just to make my motivation clear: Most of what I have been doing with Zope
so far has had a main focus on rich HTML-based UIs, e.g. content management
and groupware. I personally think that this is a good start. Some of the
reactions to my Wiki efforts suggested that the Zope UI was a different
story from a UI for a Zope-based app, which I doubt.

My direction would be to find out what type of UI "components" (which might
or might not translate into Zope3 components) we need to build ANY UI with
Zope and try to get those components built.

I have argumented a lot in favour of more DHTML etc., but don't get me
wrong: This is not about the "fancyness" of the UI. This is about
efficiency. If ASP.net provides developers with a UI to drag&drop-build
validating web forms, Zope has to have something similar. Which does not
necessarily mean that we also need a drag&drop thingie, but we need a tool
(or an approach) that is similarly efficient.

>   * fancy stuff later. We'll assume none of us has enough knowledge of
>     fancy DHTML and Mozilla integration to actually make much progress
>     on it during the sprint, so we won't do it. Infrae's experience with
>     fancy client side stuff like Bitflux or Xopus is this is simply
>     not yet ready for production, anyway (at least not in any cross
>     browser way).

Fully agreed. However, "fancy stuff later" does not mean "no fancy stuff at
all". And it should also mean that we write down the vision for the fancy
stuff even if we implement the simple one first. BTW: fancy and simple don't
need to be different faces of the coin ...

>     We can always add in fancy DHTML stuff later (we want to), but now we
need
>     concrete action. So we'll focus on plain old HTML + CSS keeping
>     javascript supplementing in mind. People who want to discuss mozilla
XUL
>     anyway can go sit in another room. :)

I am not in favour of XUL either. It seems that plain DOM-based interfaces
that work in both IE and Mozilla are possible, at least with the next
generation of Mozilla, while XUL is always a Mozilla-only story. This can be
a very nice plug-in option like a wxPython-based fat client (or call it an
IDE). But definitely not the main focus for the core UI efforts ... (except
for keeping the API straight for plug-ins).

>   * We should focus on developing the core of a 'ZopeTop' or ZMI and for
>     the target audiences as described in the ZopeTop wiki page, with the
>     focus on SiteDevelopers and SiteManagers (and an 'underwater view'
>     for advanced content managers, perhaps).

This is not quite my view of the things, but I won't argue about that. I'd
prefer having two rather different scenarios (e.g. end-user CMS UI vs.
developer "WebIDE") as a starting point and boil them down to the primitives
(widgets, whatever) needed for both.

The UI that will then be actually BUILT first will probably be the Zope
developers UI, but the tools should be there from the beginning to build UIs
for other audiences, too.

If you don't understand what I mean: My theory is that a good UI toolkit can
be useful for all kinds of UIs. Take the MS stuff as an example: The same
components are used to build Word or Excel (which is end-user software) and
Visual Studio (which is an IDE). There might be certain high-level widgets
like a class browser that are not needed for Word, but only for Visual
Studio, but those are rare (and mostly based on other, more general
widgets).

>   I think we can have two groups at the sprint:
>
>     * Design and document the next generation ZMI. This is a documentation
>       effort (quite a bit of which may be science fiction) with a UI
>       focus. What do the various roles want to do? Pick the minds of
>       Jim and Steve and work out what the UI should look like, on
>       paper and HTML mockups. Work together with the documentation group.
>       There's a ton of services, ways to hook up components, etc,
>       and they need good UIs. UI requirements will most certainly
>       inform the design of these services as well, I am convinced.

The most difficult part with this is that only a few people actually know
Zope3 well enough to define the basic use cases needed for designing the
corresponding UIs ...

>     * The style guide group. Ideally I as a programmer want to be able to
>       write dirt-simple HTML and have it look pretty in Zope 3, because of
>       the magic of CSS and the like. Possibly there will also be something
>       on a componentized GUI (what Shane has been talking about -- has
>       Shane written something detailed about this philosophy yet? we
should
>       look it up if so).

I'm beginning to wonder whether programmers should write much HTML. Some
meta language (or at least a set of high-level methods to be used in ZPT
might be the way to go ...

>       The style guide people will:
>
>           * create HTML mockups and CSS stylesheets
>
>           * Write down how we should be using various UI widgets;
>             a user interface guide like exists for Mac etc.
>
>           * Start modifying Zope 3 so it follows the style guide.
>             This includes the existing page templates as well as the
>             current forms implementation.

It definitely won't hurt to have a good general design (more like a CI guide
than like a functional UI description). I think of that part as something
like building a KDE or Gnome Chrome. You don't need to know much about the
actual programs you are skinning, just draw nice eye-candy and the like ...

Joachim