[Zope3-dev] UI effort at Sprintathon

[Joachim Werner]

Hi!

I'll limit the recipients list to the list. It seems to get longer and
longer ;-)

Man, this reply is getting long. Maybe we should start putting stuff into
the Wiki ...

Shane wrote:

> Well, these are good insights, but I really think this is a moot point
> right now.  Lesson #1 to be learned from Zope 2 ZMI is that the UI must
> be modular.  Once the UI is modular, you can plug in page elements that
> use whiz-bang browser features or you can use stodgy HTML.  Once we
> achieve modularity, both UIs will follow.  Look at CMF and Plone: we at
> ZC purposely put no effort into making CMF pretty, because we knew that
> if we made the UI replaceable, someone would come along and do the work
> for us, and that's just what happened. :-)  Now, a modular UI is even
> more inviting for designers than a replaceable UI, so the effect should
> happen faster than it did for CMF.

That's true. Modularity is one of the keys to a better UI. And it is
possible to write both simple HTML2-based and flashy WYSIWYG UIs on top of
the same platform. What we have done for Kontentor is not write a special
"WYSIWYG document", but make WYSIWYG an option for textarea fields in
Formulator. So you don't have to change anything in the back when you switch
from a plain textarea box to the WYSIWYG stuff. This works because
Formulator is modular in design. It would have been much harder with plain
Zope ...

Jeffrey wrote:

> I like the current ZMI.  It's fast, effective, and simple.  Some of the
> screens, like the infamous security grid, are a little unwieldy, but I
> think it's a great core to start from.  But true WYSIWYG, etc, in
> browsers... It's still slow and it's too much to have lying around to
> do Python Scripts and Page Templates through the web.

Well, what I have seen recently was not that slow. Actually quite a lot of
things can be faster with the right client-side technology. If you have a
large list of objects in a Zope folder or a lot of users in an acl_users
folder, being able to move or rename some of them without having to
permanently refresh the screen can save a lot of bandwith and time. Don't
get me wrong. I am not proposing that we should ONLY have flashy WYSIWYG.
But we should have it as an option where appropriate. For editing (simple)
HTML browser-based WYSIWYG is the single most efficient way. You don't need
any client-side applications apart from the browser, and it is much more
intuitive than structured text. For editing complex HTML (tables etc.) there
are of better ways, like ExternalEditor or HomeSite/GoLive via WebDAV or
FTP. But this is a totally different target group. It's the web designers
and site architects who use these tools. The secretary who knows MS Word,
but not much more, can not work efficiently with advanced HTML editors.

> Because unlike PHP and most Microsoft apps, Zope uses the web as one of
> its primary development environments.  You don't edit ASP.NET pages
> over the web - there are tools like Visual Studio.NET and Web Matrix to
> do all of that.

The fact that Zope uses the web browser as a simple IDE doesn't make it
better per se. And my personal Zope development is mainly done in Python.
For that, the current ZMI isn't even an option.

I haven't worked with Web Matrix yet, but it seems to be quite impressive.
And if people are beginning to be more efficient with ASP.net than with
Zope, then why use Zope?

> > The core point is that they often don't use a simple REQUEST-RESPONSE
> > model
> > but open an application that permanently communicates with the server
> > in the
> > back, using XML-RPC and the like. So you can do things like
> > server-based
> > link or spell checking on the fly!
>
> That sounds more important to content management efforts, and not to
> application development efforts.

Well, application development in Zope, when done in the ZMI, is not too much
different from content management. If it's just HTML or text, it is content
you manage; if there is a DTML or ZPT tag in it, it is a script you develop
...

> They may have suffered from lack of scope definition - is Zope a
> development environment or a content management environment?  I say
> it's development.  If content management overtakes development as a
> main feature, I'll have 70% less use for Zope in my work life.

What I am talking about is not making Zope a better CMS. I am talking about
getting the right tools into Zope to make it easier to build applications
with it. And these are content management systems, but also database-backed
apps, groupware, whatever you can imagine. I can't think of a web-based
application that would not benefit from an advanced browser-based UI. In
fact, CMS are the easiest part. Designing workflows over the web or doing
complex database queries could benefit even more than a CMS ...

But now, if we want to get all these tools into Zope to USE Zope to build
UIs, why not use the tools for the Zope UI itself? Zope 2 was built that
way. It just isn't perfect in many respects. But all the nice ZMI screens
are DTML.

> I think Content Management should be second in priority to the ZMI.
> ZMI3 should be lightweight and generally simple like the current ZMI.

O.K.

> Content Management is a specific application (over which no one can
> decide which UI is the best, and I don't think dictating such a UI is a
> good idea.  No CMF site I have developed in the past year has looked
> like CMF, Plone, Silva, or Kontentor.  I'll accept a common CM UI if
> Zope 3's Web Content Management project can yield a separation between
> content preparation and deployment, where the company-face and
> public-face of content are separated by very clear devisions, if not
> servers!).

I don't want Zope to be just a CMS (I'd actually say that Zope 3 core should
NOT be anything near a CMS), and I don't want all Zope-based CMS to look the
same. But we need more high-level tools. All Zope-based CMS probably use
DTML and/or ZPT as their templating languages. No need to develop your own
one. All of them probably use the Zope user management, too. But a lot of
other stuff has to be reinvented all the time because the platform lacks it,
even if we take the CMF as an add-on.

For me, the Zope 3 CMS project means tackling these issues. If something is
useful for all kinds of web development, it should be put into the Zope 3
core distro (or offered as an add-in for it). But the stuff that is
generally useful for CMS should be in the CMS package. Whatever it will be
called.

I have seen quite a few CMS UIs recently. And I must say that they
definitely have a lot in common. We Zope people are laughing at PHP people
who reinvent user management over and over. But at the same time we reinvent
CM over and over ...

> I think one of the risks mentioned on the Zope 3 content management
> proposal page is a danger of too-much-framework versus
> too-much-product.  It's a very high risk, in my opinion.  Too much time
> spent on a standard Zope 3 content management UI could tip the scales
> in favor of too-much-product.

That's absolutely not what I want. We might need a default UI that looks
nice. But it should be as modular as possible, as Shane has pointed out.

But at the same time I am sure that most of the discussion about not too
much product is nonsense. There are a few ways of making a good UI. But
there are not too many. And I am positive that building one of these
near-optimum UIs is the best way of developing all the tools needed to build
other cool UIs.

I am seeing this mainly from a business (or efficiency) point of view.
Custom development is, in most cases, just expensive. Too expensive. We
should take projects like Gnome or KDE as examples. Make things modular and
skinnable, but don't make reinventing wheels the main target.

I'll be even more provocative: I think the end of custom web applications is
nearing. There still is a niche for them, but they had their great time when
VC-backed new economy enterprises had the big money to spend. I remember the
days when I hacked little BASIC programs that did things I'd do with Word
and some macros these days. It was cool to program your own sorting or
searching algorithms, but it wasn't efficient ... -- What we primarily need
now is reusable, highly advanced modules we can put together and customize.
Otherwise we'll just be too expensive ...

>> a lot of very academic ideas and concepts (like the Object Hub).
>> I am  sure that they are cool, but we workers in the field are
>> mainly interested  in getting our job done ...

> On the contrary, I think these academic ideas and concepts are
> important because they could solve some of the grating issues in Zope 2
> - namely object relationships and events.  There are many times when I
> grudgingly have to go to a relational database just for the power of
> JOIN's to extend/combine data in new ways that are difficult in
> Zope+ZODB.  I need those things to get my job done and cut down on
> dependencies on MySQL and friends.

The point is: I don't see people in the community discussing real-life use
cases very often (be they from the world of Content Management or from the
world of web applications). What I see is discussions about things that have
different names than in the outside (SQL + Java/PHP/ASP) world and that
might be reinvented, maybe even in a better way. The object hub was just an
example. I THINK it could solve a lot of my problems. But it is rather
difficult to get into all that Zope 3 speak without seeing the use cases,
the problems that are meant to be solved.

> I imagine
> the Template + Scripts + SQL combination is going to be a common one
> for some time for many applications out there.  Managing code and
> properties is something the ZMI has done fairly well, and I'd hate for
> that to be lost.

Why should all that get lost? ...

Joachim