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

[Martijn Faassen]

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

This philosophical session should be done and over with *before* the
sprint starts. That is, of course we'll have more philosophy at the sprint;
it's inevitable. We don't have to worry about that. I like philosophy. But 
it's far from inevitable that we're actually going to do concrete stuff, which
is what I'm trying to accomplish. :)

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

Thanks for your assistance!

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

Understood.

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

I agree that this should be done. However, I fear we don't have the expertise
at the sprint to do much about it implementation-wise. This may change if
people do homework in advance. Perhaps there's some nice javascript
library we can use for some of this. Anyway, I agree that this should be
done, eventually.

I'm just worried we'll waste a lot of time learning about
what's possible and not with javascript (cross browser) and that this doesn't
push the project forward a lot. If someone wants to take the time and effort to 
learn this this before the sprint, all the better. But if this is going to
be a 5 day javascript workshop I don't think that's too helpful.

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

Yes, if people want to write down some of this, that's fine, but I think
we should also have something actually implementable-at-the-sprint, so
we at least get the implementation effort moving again. Anyway, we have
a start with the ToDo list Stephan pointed out.

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

Yes, the main GUI effort in my opinion should focus on getting a GUI at all 
working in HTML. It should be a nice GUI. It should use modern HTML and
CSS. It can be supplemented by Javascript. I think we have the expertise
to accomplish this. Going further into 'fancy javascript', I hope so, but
I don't see we have a team yet that's able to do this. I hope this team
will develop eventually.

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

Sounds fine to me. :) We already have a forms system in which they can
be plugged in. The forms system can be extended based on input by the
GUI team. It also needs guidelines and tutorials.

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

All right, though I expect many content management oriented UIs may be
custom jobs. But I agree with this goal, it should however not bog the
effort down.

> 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 wrote Formulator; while it is limited in many ways I think I understand what
you mean. ;) I agree that this idea should be extended.

> >   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 great thing about the sprint is that many of those will actually be
present at the sprint. I'm sure they'll agree to be interviewed. Perhaps
they can also do advance work with us, so we already have a lot of ideas when
we show up. I also think they will be helped by the UI effort, as it
forces them to think what a user wants to accomplish.

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

This is an ambitious goal and I think not feasible on the short term, unless
someone spends a lot of time designing this. I think the sprint is not
the right place to design this, as I think we won't get anywhere fast.
I agree that this topic is very interesting, though, and let's discuss
it some more online. :) As an aside, I think actually dirt-simple HTML with 
extensive use of stylesheets starts to look a lot like such a meta language,
though definitely it not complete as it doesn't have a server-side 
piece, which in case of forms is definitely necessary.

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

Yes, and as you say above (and I too), start supplying developers with widgets
based on those ideas.

Regards,

Martijn