[Zope3-dev] Usability is important?

[Chris Withers]

Jim Fulton wrote:
>> -python
> 
> There will be a class of users who won't have to learn Python,

Sorry, but unless that class only includes users of systems built with Zope, I 
don't believe you ;-)

> 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 we should be open and upfront: you will need to know python.
I've seen stuff even in ZPT that requires quite a deep level of python 
knowledge. I'm not saying that's a good thing, but the fact that it's possible 
means that it will be a requirement.

> I think it would be great if people had the *option* of using other
> languages, most notably perl, with Zope.

Indeed. But this is the same problem, as soon as the option is there, you _need_ 
it if you want to take advantage of anything that makes use of that option. And, 
as Plone has already showed, popular projects will make use of _all_ the 
options, not necessarily in ways the designers of those options had intended...

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

Indeed, but having two config languages for one framework, where ideally you'd 
have no config _languages_ at all, worries me...

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

If we could get to the point where only ZConfig syntax is needed, that would rock...

> - I'm confident that there will be interactive UI tools for building
>   configurations.

Does that mean there's a funded project to develop such tools?

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

This is what I'm hoping. Mindyou, if I'm honest, I'm hoping that I'll be able to 
manipulate and generate the objects that are created from ZCML and find a way to 
avoid using ZCML at all...

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

I find the notion of having two templating languages in one framework crazy. 
What examples are there of other successful frameworks that suffer from this?

> You don't always need to modify a product to use it.  

Indeed. I think the points Max raises about Plone are why I have such an 
allergic reaction to it. BUT, it does demostrate the point that very popular 
products will be written that won't do things in the best possible way...

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

This does sound cool, especially the bit about perl, is any of it reality yet?

cheers,

Chris