Re: [Zope] Re: reality check - The REAL issue
On Fri, 10 Dec 1999, you wrote:
----- Original Message ----- From: Craig P Avnit <craig@londonplaza.co.uk> To: <zope@zope.org> Sent: Saturday, December 11, 1999 4:44 AM Subject: Re: [Zope] Re: reality check - The REAL issue
On Fri, 10 Dec 1999, you wrote:
Everyone is talking about the difficulty in using Zope and how good Docs would help. I believe, in part, documentation is just masking part of the problem. Zope is way-to-difficult to use. If you're a programmer, you can trudge through and figure out how Zope works. But I'm not a programmer. I have yet to see any non programmer deploy a cold fusion, vignette, or any other application server solution. Zope is not nearly as difficult to implement as a java servlet based solution.
You will always lose functionality when implementing ease of use in a development environment.
Isn't that the definition of a 'bad' development enviroment.
Are you trying to tell me that Cold Fusion, ASP and Websphere are good because they are easy to use. The problem with developers on those platforms and most windows developers, are that they code the most horrificaly bloated application known to man. Cold Fusion doesn't come close to Zope and Python in functionality and rapid development.
I don't know what's going on at the code-level, and frankly, I don't want to have to know. If Zope is to truly adopt a wide user base, it's got to be easy enough that the average user and install and deploy Zope. Right now, it's just to complicated for me use. I've got a business to run, I don't have time to mess around with the particulars.
That is why there are people out there like the fine folks at DC, who can concentrate on supplying you with the functionality you need to allow you
to
concentrate on your business.
I thought the whole idea behind open-source was that there is a critical mass of users that has to be reached for the flow on benefits. Those benefits won't arise if the open-source application isn't competitive, it won't be competitive if it isn't easy to use and it certainly won't get a critical mass if there is an understanding that 'best' practice, performance and use are not the watch words.
I agree, but the point a click mentality doesn't help either. You don't use linux because you are in a desktop environment, if windows is so good show me an ISP that trusts there operations to it, I don't. Unix and linux strengths lie in the server arena at the moment. I run a linux box at home, full printer access and all the Destop applications I need. I don't have 5 % of the problems the average window user has.
One reason I haven't move to linux is that it is still not as easy to use as windows, I just don't want to learn the geekisms. Now to add positively to this to debate, what Zope really needs is a glossary of terms, then a one page overview of all components that has been 'tested' against a panel of average windows users (the industrial standard), if they can understand it anyone that matters can. ;-).
Windows are the industry standard for home PC's and desktop, not mission critical high end apps, and distributed computing. Unix is the standard here. I agree that zope does need to be easier to use, and the docs can be improved, but I cannot agree with wanting to aspire to windows mediocrity, or heaven forbid that windows users are the only ones who matter. Most organisations run in spite of windows not because of it.
Could anyone point me to a one-page description of a product, where it resides, what it can do for me and how it interrelates with the other Zope components.
Just a thought,
Brian
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope No cross posts or HTML encoding! (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) -- Craig P Avnit Director London Plaza Ltd Tel: +44 (0)7000 64-5768 Fax: +44 (0)7000 64-5769 http://www.londonplaza.co.uk
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope No cross posts or HTML encoding! (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Craig P Avnit Director London Plaza Ltd Tel: +44 (0)7000 64-5768 Fax: +44 (0)7000 64-5769 http://www.londonplaza.co.uk
Would it be possible to end this religious fundamentalism on the zope list. Cold Fusion has some areas in which it is much stronger than zope, and some in which it is much weaker. The same goes for other solutions. The same goes for operating systems. Differnet applications/OSes are appropriiate for different tasks, and I make my choices based on cost, ease of use, customer preference, speed, and a host of other parameters. The fact is, when I have a customer who wants me to build a web application that would be maintainable by less sophisticated computer users, it is difficult in every platform. To my mind, zope's issue with regard to documentation/usability is that it is a product that has obviously evolved, rather than been designed from the ground up. As a result, there are many inconsistencies in the way it works. Zope is a tremendously powerful tool, but it is very difficult to learn because depending on what you are trying to do, you need to solve problems in very different ways. Just look at the source code. You can tell that what code is written by different people, as there doesn't even seem to be a whole lot of standardization of programming style. This is fine by me, as it has resulted in a very powerful too that is free, and undergoing rapid development. However, coupling this issue with a lack of documentation of any of the features that truly makes zope powerful does become somewhat of a drag. It is all well and good to have an application server with all of this power, but if it takes me days to figure out how to do something, it would still be faster to write it as an apache module, servlet, ASP application, or whatever. the complexity of zope is reaching a critical mass, as evidenced by the increasing amounts of confused user email on the mailing list. It does little good to have DC adding features that cannot be used due to the steepness of the learning curve. Additionally, zope seems to be at a critical juncture, as it starts to get media attention and market mindshare. However, all the attention consistently focuses on usabililty at some point. I really do think it is time that the __zope community__, lead by DC, do something to provide adequate documentation, and to perhaps clean up some of the usability inconsistencies at the same time. To all of the complainers on this thread, why don't you pick one small area of the current docs that you think are insufficient, and do what you can to improve them. I am sure that DC and the ZDP will do what they can to provide detail that you are lacking, that you can then add to the docs. I see an awful lot of questions about running PCGI and FastCGI on Apache, Roxen, ApacheNT, and IIS. I also see certain people consistently providing the answers to the questions. last time I looked at the ZAG, there was no detail about how to do this. How about those people that have working installs of Zope with another webserver submit configs to me, and I will compile them into a document providing working examples. However, I would like at least a single line description of what your Rewrite rules are doing, especially if they are doing anything out of the ordinary. Particularly those folks with fastcgi experience, this would be very useful. If someone else with some ZClass experience wanted to write up instructions for writing a ZClass stub in python, which is mentioned as possible in the ZDG, but with no instruction on how to go about doing it, I would find that exceedingly useful. I managed to hack some things up from ZDiscussions, but that was by writing a self contained base class that was inherited by the ZClass. I want to know how to write python code that belongs as part of the ZClass, and I have no idea how to go about doing that. If someone wanted to document how to use the _ namespace with some real world examples, so that people without python experience could decipher that page of the dtml guide, that would be tremendously useful and should cut down on a lot of traffic on the list. There is no need to contribute an entire document to the current zope docs. Just put together a more easily understood version of a current page and I am sure that some at DC will get it integrated with the docs. If someone wanted to go through the How To's and get them integrated into the correct places in the docs, that would be terribly useful to. Why are we waiting for DC to do it. Remember that the folks at DC know how to use Zope, so they don't have a huge incentive to provide documentation at the expense of the rest of their business. If you want it fixed, fix it yourself. --sam Craig P Avnit wrote:
On Fri, 10 Dec 1999, you wrote:
----- Original Message ----- From: Craig P Avnit <craig@londonplaza.co.uk> To: <zope@zope.org> Sent: Saturday, December 11, 1999 4:44 AM Subject: Re: [Zope] Re: reality check - The REAL issue
On Fri, 10 Dec 1999, you wrote:
Everyone is talking about the difficulty in using Zope and how good Docs would help. I believe, in part, documentation is just masking part of the problem. Zope is way-to-difficult to use. If you're a programmer, you can trudge through and figure out how Zope works. But I'm not a programmer. I have yet to see any non programmer deploy a cold fusion, vignette, or any other application server solution. Zope is not nearly as difficult to implement as a java servlet based solution.
You will always lose functionality when implementing ease of use in a development environment.
Isn't that the definition of a 'bad' development enviroment.
Are you trying to tell me that Cold Fusion, ASP and Websphere are good because they are easy to use. The problem with developers on those platforms and most windows developers, are that they code the most horrificaly bloated application known to man.
Cold Fusion doesn't come close to Zope and Python in functionality and rapid development.
I don't know what's going on at the code-level, and frankly, I don't want to have to know. If Zope is to truly adopt a wide user base, it's got to be easy enough that the average user and install and deploy Zope. Right now, it's just to complicated for me use. I've got a business to run, I don't have time to mess around with the particulars.
That is why there are people out there like the fine folks at DC, who can concentrate on supplying you with the functionality you need to allow you
to
concentrate on your business.
I thought the whole idea behind open-source was that there is a critical mass of users that has to be reached for the flow on benefits. Those benefits won't arise if the open-source application isn't competitive, it won't be competitive if it isn't easy to use and it certainly won't get a critical mass if there is an understanding that 'best' practice, performance and use are not the watch words.
I agree, but the point a click mentality doesn't help either. You don't use linux because you are in a desktop environment, if windows is so good show me an ISP that trusts there operations to it, I don't. Unix and linux strengths lie in the server arena at the moment. I run a linux box at home, full printer access and all the Destop applications I need. I don't have 5 % of the problems the average window user has.
One reason I haven't move to linux is that it is still not as easy to use as windows, I just don't want to learn the geekisms. Now to add positively to this to debate, what Zope really needs is a glossary of terms, then a one page overview of all components that has been 'tested' against a panel of average windows users (the industrial standard), if they can understand it anyone that matters can. ;-).
Windows are the industry standard for home PC's and desktop, not mission critical high end apps, and distributed computing. Unix is the standard here.
I agree that zope does need to be easier to use, and the docs can be improved, but I cannot agree with wanting to aspire to windows mediocrity, or heaven forbid that windows users are the only ones who matter. Most organisations run in spite of windows not because of it.
Could anyone point me to a one-page description of a product, where it resides, what it can do for me and how it interrelates with the other Zope components.
Just a thought,
Brian
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope No cross posts or HTML encoding! (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) -- Craig P Avnit Director London Plaza Ltd Tel: +44 (0)7000 64-5768 Fax: +44 (0)7000 64-5769 http://www.londonplaza.co.uk
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope No cross posts or HTML encoding! (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Craig P Avnit Director London Plaza Ltd Tel: +44 (0)7000 64-5768 Fax: +44 (0)7000 64-5769 http://www.londonplaza.co.uk
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope No cross posts or HTML encoding! (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
<snip much ranting> I think things like the howtos are leading in the right direction. What the various guides need is the ability to be annotated by Zope members (ala PHP). Right now I don't see that the documentation is benifiting much from open-source stuff. it should be easy to add a comment here and there, for example to the ZQR. -- Ethan "mindlace" Fremen who will write up a biiig "how I learned to love zope" when he gets to the USofA
Sam Gendler wrote:
Additionally, zope seems to be at a critical juncture, as it starts to get media attention and market mindshare. However, all the attention consistently focuses on usabililty at some point. I really do think it is time that the __zope community__, lead by DC, do something to provide adequate documentation, and to perhaps clean up some of the usability inconsistencies at the same time. To all of the complainers on this thread, why don't you pick one small area of the current docs that you think are insufficient, and do what you can to improve them. I am sure that DC and the ZDP will do what they can to provide detail that you are lacking, that you can then add to the docs.
I see an awful lot of questions about running PCGI and FastCGI on Apache, Roxen, ApacheNT, and IIS. I also see certain people consistently providing the answers to the questions. last time I looked at the ZAG, there was no detail about how to do this. How about those people that have working installs of Zope with another webserver submit configs to me, and I will compile them into a document providing
For Roxen, you can see the two howtos, IMO, they document the process quite well, all things considered. :-)
working examples. However, I would like at least a single line description of what your Rewrite rules are doing, especially if they are doing anything out of the ordinary. Particularly those folks with fastcgi experience, this would be very useful.
If someone else with some ZClass experience wanted to write up instructions for writing a ZClass stub in python, which is mentioned as possible in the ZDG, but with no instruction on how to go about doing it, I would find that exceedingly useful. I managed to hack some things up from ZDiscussions, but that was by writing a self contained base class that was inherited by the ZClass. I want to know how to write python code that belongs as part of the ZClass, and I have no idea how to go about doing that.
I'll second that. IMO, much of the complaints about the dtml complexity is due to trying to do it all in dtml. ISTR in the first docs put out on Zope (then Principia), was a statement warning that if you were doing much control structure statements in dtml, you should probably be looking at doing it in Python. I know Python somewhat well, but would relish more documentation on doing zope-python (ZPython ;). It may just clear up some of the dtml issues, IMO.
If someone wanted to document how to use the _ namespace with some real world examples, so that people without python experience could decipher that page of the dtml guide, that would be tremendously useful and should cut down on a lot of traffic on the list.
There is no need to contribute an entire document to the current zope docs. Just put together a more easily understood version of a current page and I am sure that some at DC will get it integrated with the docs.
If someone wanted to go through the How To's and get them integrated into the correct places in the docs, that would be terribly useful to. Why are we waiting for DC to do it.
IMO, it has been due to a lack of understanding of DC's position, which was briefly outlined in thi svery thread. The last I saw, the docs were written using a proprietary tool that many of us aren't willing to buy. That certainly doesn't help. (No, let us not drag up the rest of that thread, please.). Bill -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
participants (4)
-
Bill Anderson -
Craig P Avnit -
Ethan Fremen -
Sam Gendler