[Zope3-dev] UI effort at Sprintathon

[Jeffrey P Shell]

On Wednesday, October 23, 2002, at 10:23  AM, Joachim Werner wrote:

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

I agree with the goals of modularity.  The 'replacable' nature of CMF 
skins has plus and minus points, with the minus points going up and up 
and up the more you have to customize (basically - the farther away you 
get from the default CMF layouts).

And I do love Formulator.  I think Formulator shows a lot of good 
design and usability points, aside from the component-esque 
architecture of Fields and Validators - you can have Formulator 
completely render an entire form by itself; or you can go through and 
loop through the fields selecting how to display the field, its title, 
description, and so on; or render each field manually (helpful for 
situations that use more than one Formulator form).  It eases building 
complex UI's without dictating how the final result should actually 
look.

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

Ever used the Mac OS X ports of Mozilla?  Gecko is nice and fast, as is 
evidenced by Chimera, but Mozilla + XUL is still slow and clunky.

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

My setup changes with every project (no two are ever the same), so 
sometimes I spend more time in the ZMI, sometimes it's all file system 
based development.

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

But that's like saying "putting a file on the file system" or "editing 
code in XEmacs" is not too much different from content management.  I'm 
very queasy about the "everything is content" line (and am still 
uncomfortable with the term 'content components' in Zope 3, but it's 
not a term really worth me squabbling over).

Sometimes if it's just HTML, it could all just be design.  We did one 
site recently that was all Page Templates, and all fancy design (it was 
for a small inn), and three or four pages had some ZPT elements in them 
where the customer could edit (on separate admin screens) lunch and 
dinner menu items and room rates.  Nothing fancy, no content 
management, no HTML needing editing by the client, no link or spell 
checking needed.  If we go modular and all of those things are easy to 
disable, then cool.  Because for this simple app (which used Gadfly), 
no large framework was needed.  Just stock Zope.

We're already running into situations where Zope is feeling too 
heavyweight (mostly for serving setups) for small simple apps.  
Security and page templates and ZEO keep us coming back.  Modular 
design is good - but if I end up spending more time turning feature 
after feature after feature off than I spend coding/authoring new stuff 
for a customer, it's a loss to have chosen that technology.  I just 
don't want a stock Zope checkout/setup experience to be like that.

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

Agreed.  WebObjects, and now JSP (with taglibs) and ASP.NET all have 
rich UI components that are fairly easy to distribute and re-use in a 
fashion similar to the custom controls used in tools like Visual Basic 
and Friends.  These custom tag / UI components are a pretty big market.

Zope has similar, but plagued by the same problems that plague Zope 2 
in general that the Component Architecture *should* address - 
packaging, distribution, installation, and configuration.

> 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 that's largely true.  The five different content management 
projects I've done in recent months have all been different - and only 
one has used the CMF.  Part of the difference has been due to different 
scope and feature requirements.  None of the projects have needed 
workflow, only one needed membership and skins (hence the CMF), most 
others either had a fixed set of data to maintain or had very simple 
document editing, categorizing, and linking requirements that didn't 
need the much more expansive feature set of the CMF, Plone, or other 
available tools at the time of authoring.  There is one large CMS that 
we run that is not CMF which is an expansive ski resort site.  And I 
know that the CMF would have been a lousy fit for that customers 
requirements.

Content Management still seems to be a very individualized thing, and I 
think the fabled in-house systems are still largely in charge, and I 
have the feeling that trend will continue for some time.  Now though, 
the in-house systems are in their second or third generation with 
consultants doing the development, but it's still personal.

Ugh.  I wish I could get out to the Sprints.  Maybe I can talk the guy 
I'm contracting for to let me reside in the ski-happy Three Valleys 
region of France during the winter.  :)

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

Agreed.

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

Too much product IS sense.  Product goes beyond the UI.  This is my 
constant conflict with the CMF - it has a lot of features that I miss 
when I'm not using it, but very often when I do use it I'm hacking 
around or disabling many of the features.  It is nice that the CMF is 
designed so that core tools are replacable, and that the UI is 
replacable (but as has been mentioned - it could be better), but it's a 
lot of work to whittle the default feature set DOWN to what I usually 
need to build from.

Soon, I hope to have a complete replacement for CMFDefault for my 
company's consulting projects that gives us more of a basic starting 
point.

It may be my fault for depending too much on CMFDefault at the start of 
CMF based projects.  But do you see my issue?

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

Those are still heavy baroque environments, but I understand where 
you're coming from.  The component models of Bonobo, BeOS, the .NET 
framework, and OpenDoc (OpenDoc is a beautiful architecture that 
intelligently separated out content from editors and dealt with 
nesting, modularity, cross-platform issues, etc) are better to look at 
then the heavy results that are built on top of them.  Gecko is a 
shining example of the Mozilla project, and the small platform specific 
browsers that are built on top of it like Chimera on Mac OS X are 
better things to look at than the end result of the Mozilla browser 
itself.

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

This is what we've always needed.  And what we've always had according 
to every new programming and development paradigm to come along.  But 
the old problems still exist.

The mantra of anything that can really claim the name of component 
architecture is Packaging - Distributing - Installing - 
Configuring/Integrating.  This goes beyond the UI level, and should be 
pervasive in Zope 3 from the core on up.  If it's lived up to, a lot of 
our issues will go away.

But I don't see the era of the custom web application as coming to an 
end.  There are just too many differences out there in data models, 
business processes, and so on.  So yes, things need to be modular, but 
there is still a lot of mileage in the custom app.

For example - <http://www.24tix.com/> is fundamentally a database 
backed e-commerce site.  But it has no shipping, no physical objects 
(ticket numbers are generated and even modified during their lifetime 
as they get transferred), a different concept of inventory than most 
stores have, and different reconciliation models.  No E-Commerce 
framework out there could handle such requirements without us spending 
as much time disabling or hacking around their modular features as we 
spent writing it from scratch.

Now, I do wish there was a way to turn what we did into the basis for 
our OWN e-commerce framework, but that's something I pray Zope 3 will 
help with.  And I guess it's why I should stay involved.  What's become 
of any Object-Relational schema?  I want more data components and less 
SQL methods!

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

Agreed.

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

It shouldn't.  :)