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

[Joachim Werner]

Hi!

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

Perfect.

I have added some stuff last night:

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeUI

Just my personal view of things. BTW: My last mail didn't manage to be
published by the zope3 list. If this one doesn't show up on the list, too,
could you please relay it for me?

> > 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 also agree that we can't do that at the sprint. My only point is that we
have to KNOW about all that stuff when we design the core framework so that
the framework does not make things harder later.

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

Look at how Plone (and Kontentor, but that one still is not publicly
released) integrate the WYSIWYG editor. I did it with a slightly beefed-up
formulator widget. The actual editor is third-pary (I am using the vsbabu
one), and the integration is rather trivial (just replace the textarea by a
couple of lines of Javascript/DHTML).

That's how many of these advanced features could be plugged in. So what we'd
have to do at the sprint is NOT a Javascript session. It would be enough to
say "We want a Super Duper Editor Widget here!" and have a textarea field in
the mockup as a start.

OT: Croos-browser is still science fiction ...

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

Point taken.

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

Yep

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

My theory is that custom jobs usually don't have to be custom at the core
HTML level, only on the CSS and graphics design level.

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

;-)

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

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

Indeed, if you have high-level methods like the rendering support Formulator
provides, the actual code will probably not be too different from a
specialized meta language ...

My experience ist that the actual data that is handed over to the back-end
is usually just plain lists, strings, and dictionaries. So a meta language
approach for the UI can be added as a new layer later.

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

Well, I guess we'll have some results soon then ;-)

Joachim