[Zope3-dev] UI effort at Sprintathon

[Jeffrey P Shell]

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

> Hi!
>
>> I agree with this point.  Based on lessons learned from the UI
>> mini-sprint in Brazil, I think it's important beforehand to set
>> specific and realistic targets for what should be done at the sprint.
>> It's very easy to expand the scope, especially when someone like me is
>> around. :^)
>
> Here I have collected my first thoughts about the UI topic:
>
> http://www.zope.org//Wikis/DevSite/Projects/ComponentArchitecture/ 
> ZopeUI
>
> I am pretty sure that the scope I have chosen has to be narrowed down  
> for
> the Sprintathon. But I don't want to START with narrowing down. My  
> intention
> was to collect as many ideas as possible, and more are to come.
>
> Last week I went to SYSTEMS, the Munich IT fair, for a day. Nothing  
> new in
> general. BTW: Zope was represented by two companies, Struktur AG and
> Lightwerk, not bad ...
>
> But what really impressed me is what people from the PHP (e.g. Flying  
> Dog,
> see http://www.flyingdog.biz) or Microsoft camps are currently doing  
> with
> the browser as a client application. With IE 6, and to some extent  
> also with
> Mozilla, you can really have great UIs with true WYSIWYG, copy &  
> paste, drag
> & drop, etc.

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.

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.

Granted, most of the time I am using a tool like GoLive, BBEdit, or  
XEmacs to do remote editing, but having the simple but usable ZMI to  
back me up with other tasks is very useful.

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

> I can remember the first XUL efforts for Mozilla-Zope. Those were quite
> similar in scope, but they were never finished ...

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.

>> The first question, which you've hinted at: should this UI sprint  
>> focus
>> on a ZMI for Zope 3, or focus on building ZMIs for Zope 3?
>
> I'd say let's think about a UI for a Zope-based Content Management  
> System.
> So the two efforts on the Sprintathon get somehow related. This should
> include all the UI issues that we need in a "plain" Zope3. We could  
> take the
> existing approaches (Zope, CMF, Plone, Silva, Kontentor, ...) and  
> collect
> something like a "best-of" (or best practice). IF possible within the
> limited time frame, the result should be a non-functional mockup with
> interlinked static pages (or let it be PowerPoint slides, I don't  
> care) that
> can actually be used as if it worked.

I think Content Management should be second in priority to the ZMI.   
ZMI3 should be lightweight and generally simple like the current ZMI.   
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 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.

> The "building ZMIs FOR Zope 3" part will be the second step. When we  
> know
> what we need we can decide what tools to implement to get it. This is  
> an
> approach that I think would be quite good for all of Zope 3. Currently  
> I see
> 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.

Half or less of my jobs are content management.  Most are plain ZMI  
developed apps full of Page Templates, Python Scripts, and SQL Methods.  
  I'd LOVE to see GOOD object-relational mapping (PyDO keeps pulling me  
towards SkunkWeb, but STML pushes me back to the safe haven of Page  
Templates) so I could actually turn development back to classes, and  
develop Zope 3 views for a lot of this stuff, but even then 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.

> It will be very hard for me to decide whether I focus on the UI or the  
> CMS
> part of the Sprintathon ...

I wish I could make it out there.  Maybe all you folks could come out  
to Alta / Snowbird ski resorts instead? :)