[Zope3-dev] Usability of simportant.

[Jim Fulton]

Chris,

You raise a good point. I think Steve has done a good job
of responding.

I think we need to pay attention to usability and learning curve
issues.

Here's my take on this.  To fully understand any system as featureful
and flexible as Zope, there will be a lot you need to know. That
is inevitable.  This is true of comparable systems too.  It's important
that people can be productive in Zoipe without learning everything right
away and that there is a gradual smooth learning curve for those who
need to learn more.

We need to keep this issue in mind as we move forward and it's healthy
to be reminded of it from time to time.

It would be helpful to get some more tutorials written,  For example,
my Python Programmers tutorial helped me work out how I would address
*one* Zope 3 audience. There are a number of different kinds of Zope
users for whome we should prepare similar tutorials to help *us* work
out some usability issues.

I'll respond to your specific points below.


Chris Withers wrote:
> Steve Alexander wrote:
> 
>>
>> An aside: before Zope 3 has a beta release, and hopefully sooner, the 
>> zserver.zcml file will be replaced by the zconfig system that was 
>> recently checked into the Zope 2 cvs HEAD.
> 
> 
> Am I correct in assuming that, in order to use Zope 3, I now need to 
> know the following languages?

Note that I'm going to rearrange your list a little bit:

> -python

There will be a class of users who won't have to learn Python, but
most develers will learn *some* python. I think that most of us agree
that this is a good thing. I don't think that it will be *necessary*
for most people to have deep knowledge of Python.

I think it would be great if people had the *option* of using other
languages, most notably perl, with Zope.  I think it would be great
if people could use Java in some fashion too.  Many people will
complain that then people would need to know all of these languages.
I really don't think that this is the case. I'll say more about this
at the end of this message.

> -ZCML
> -ZConfig

As Steve pointed out, ZConfig is aimed at a specific audience who
may pay attention to little or none of the rest of Zope.  It's also
meant to be very easy to use and I think it succeeds pretty well at
that.

I think a bigger issue is ZCML. ZCML performs a complex task and is,
necessarily, complex.  I'm aware of this issue and have put (and will
continue to put) a lot of effort into simplifying it.. I think that some
alternatives will present themselves, but these will take some time
to work out. Here are some ideas that I have for the future. These
are just ideas.

- If the ZConfig syntax is successful, I think we might support it
   in ZCML. That is, I think we could adopt some of the simplifications
   in ZConfig to make ZCML simpler to read and write. This won't avoid
   the essential complexity in the problem that ZCML solves.

- I'm confident that there will be interactive UI tools for building
   configurations.  The first example of these is the Web based UI
   we're building for TTW configuration.  My hope is that TTW configuration
   will make much ZCML unnecessary initially. I also think this work
   will lead to the asbility to generate ZCML from TTW configurations.
   I also think that other tools will be built, but we'll need to be
   patient.

> -ZPT
> -DTML

Each of these has a significant audience. It's not an option to
forbid DTML. As a bonus, I plan to *add* a TALES-based DTML. :)
I don't think that everybody needs to learn DTML.

Max M wrote:
 >
...
 > The problem is that all of your above aproaches are useless in practice.
 > Shure, if you want to write everything from scratch, then you have the
 > options you mention above. But if Zope fullfills it's promise, you will
 > need to work with other peoples code. And my experience is that people
 > don't do what they should do. They do what they can do.
 >
 > So to use products, you will need to know the technologies that the
 > product uses.
 >
 > Just look at Plone. It uses every imaginable Zope technology, plus a few
 > of their own.
 >
 > Or if I want to use some clever product in a solution for a customer.
 > Odds are that I will need to modify the product to fit my need. So I
 > will need to understand the technologies used in the product. etc.

You don't always need to modify a product to use it.  I use
lots of products without knowing their implementation. Zope 3
seeks to make it easier to use a product without modifying it.
In fact, you should never have to modify a products source code
to use it.

Suppose I get a perl-based product. There's no need for me to understand
the perl code. I only need to understand the product's interfaces.
I can replace or add components with Python-based components. I can add
new UI's without looking at the perl code.

If I get a product that has a DTML-based UI and I want a different UI,
then I can replace the DTML-based UI with a ZPT-based one. I don't have
to know DTML to do this. All I need to know is what the views do so that
I can replace them. The views should be built against well-defined
interfaces, so this should be straightforward.

Of course, some people may *want* the optionof just modifying the original
source. While I don;t recommend that, I can see why some people might want
that. People who want to customize at that level should pick products
written in the languages that they know.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org