Re: reality check - The REAL issue
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 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. Just a thought, Brian
On 12/10/99 12:30 PM, Brian Salisbury at brian@hilarious.com 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 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.
From teaching Zope to people, what I emphasise is the concepts, not the particulars. If people truly understand the idea of object traversal, acquisition, etc., then the rest is pretty wrote. Unfortunately, we've not done a good job of making the concepts as well explained as they should be.
Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Christopher Petrilli wrote:
From teaching Zope to people, what I emphasise is the concepts, not the particulars. If people truly understand the idea of object traversal, acquisition, etc., then the rest is pretty wrote. Unfortunately, we've not done a good job of making the concepts as well explained as they should be.
I would have to disagree. The concepts are explained far better than the particulars. and it is particular information that is needed when we need to get work done. Understanding acquisition, roles, permissions at the conceptual level, doesn't help all that much when you have to write a ZSQL method, link it to a DTML method and call it from a DTML document keeping all the linkages in sync. I was swimming in this yesterday and I have had no problem understanding Zope architectural concepts. Zope concepts are why I am using Zope and am willing even to pickup Python. But the lack of particular information is driving me up the wall. By the way I have developed Java Servlet and EJB applications for large sites. It's "read the code if it's not in the docs" that I have a problem with. Also, the examples in the docs use the simplest cases leaving no hints or pointers to real world situations. e.g. The external method example in ZCMG uses an external method that does not take arguments. What about one that does ? Do we declare these in the method creation form - no that doesn't work. Maybe it's not needed. Let' just try passing it parameters. How do we pass parameter's - let's try <dtml-call ...> no that doesn't work how about <dtml-var func(REQUEST['field1'], REQUEST['field2'])> oh that seems to work! Oh it's because my external method was returning a string value which I wanted to be in the page. Is it that hard to put that in the docs near external methods ? I found it somewhere else. One major suggestion - look at the Java Tutorial and see how they have created "trails" - we need trails. Needed - a database development trail, a security management trail, a dynamic document trail, a product trail ... Each trail should have some *real world* examples and via links point to existing info even if it's in the how-to or tips. More than the detailed docs please create some real tutorials, that would be very helpful. Also a Zope newbies list where even the stupidest questions can be asked, and answered would help in the interim, while docs are being fleshed out. Too many stupid RTFM questions on the zope list and understandably everyone gets irritated. I would read the FM if I knew which one :-) or if there was one! Nitin.
Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
_______________________________________________ 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 )
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.
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.
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
[Brian Salisbury, on Fri, 10 Dec 1999] :: 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. HTML/HTTP is easy to use. Zope is an application server platform. Name one *other* application server platform that is easy to use. Some companies spend upwards of a million bucks getting a working ColdFusion or StoryServer system. But even then, those installations would not, IMHO, qualify as easy to use. Nor do they offer anything near the power and flexibility of Zope. Some companies pay consulting fees to Digital Creations to get a working Zope system running. I'd be amazed if those companies pay anything near what the Vignette customers do. Real power and flexibliity come at a cost. If you could somehow download *any* application server environment for free, push one button to install it, and magically have a cool Web dynamic site, then it just wouldn't *be* cool anymore, would it? :: If you're a programmer, you can trudge through and figure out how :: Zope works. But I'm not a programmer. For that matter, if you're a programmer, you can build your own application server capability from Python. Zope has DTML for those people who don't want to get into programming -- it allows you to do things you couldn't dream of doing with any other system -- in a simple markup language. :: 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. What on earth is an average user? If, as you say, documentation is not "The REAL issue," then you'd seem to be suggesting that Zope is too complex and needs to be dumbed down, presumably by hamstringing it. Let me be the first to vote against that. If you want something with less complexity (and therefore less power) you may want something that isn't Zope, like HTML/CGI, e.g. Sorry, but I think you're wrong. I think that documentation IS "The REAL issue."
On Fri, 10 Dec 1999, Brian Salisbury wrote:
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 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 have been thinking about this lately, and I began to wonder if Zope really is difficult to use. Zope is an application server. An application server is meant to be used to create applications, and in Zope's case web applications. Of course, it can be used as a simple web server, but that is certainly not the extent of its capabilities. What is it that you are trying to do with Zope that you find difficult? Installing it? Making simple, static web sites with it? Making simple, dynamic web sites with it? Making complex, enterprise, e-commerce sites? Each of these requires different proficiencies with Zope, and it's important to identify of which we're speaking. If it is much beyond writing a simple, somewhat dynamic site, then I fear no amount of documentation could help the situation. The fact of the matter is: Well designed, complex web applications require programming. Programming is hard. I am a programmer, and do not consider Zope difficult to use. I simply think the documentation could be better structured (and more plentiful). If I am having difficulty with something, it's generally because the map in my mind is unexplored in that area. If the documentation were there to consistently push me in the right direction on tough topics, I would be in heaven. A bit of theory, followed by detailed, step-by-step examples would be wonderful. I have some more ideas in this regard, and will see what I can do to contribute as my schedule allows. The bottom line is that I require different documentation than others, working at a higher level, might. Perhaps it would be useful to start a dialogue about the different audiences to which documentation should be written? --Jeff
[Jeff K. Hoffman, on Fri, 10 Dec 1999] :: The bottom line is that I require different documentation than others, :: working at a higher level, might. Perhaps it would be useful to start a :: dialogue about the different audiences to which documentation should be :: written? Jeff, you are absolutely right. But there is already a forum for this -- the Zope Documentation mail list. Are you subscribed to it? (Haven't seen you there.) Last I heard, something like 600 people had signed up for membership on the regular Zope Web site, yet all of only 3-4 people are currently committing *part* of their time to the Zope Documentation Project. Where is everyone else? I'd suggest that if *every* Zope user simply subscribed to the zdp@zope.org mail list, then hopefully some fraction of those subscribers would see an occasional opportunity to contribute in some easy way. And ALL of the subscribers would have a clear, no-illusions, idea just how hard it is to develop quality documentation in any Open Source project. To subscribe: http://lists.zope.org/mailman/listinfo/zdp See you there! :)
Patrick Phalen wrote:
Last I heard, something like 600 people had signed up for membership on the regular Zope Web site, yet all of only 3-4 people are currently committing *part* of their time to the Zope Documentation Project. Where is everyone else?
Learning it! :-) -- 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
[Bill Anderson, on Fri, 10 Dec 1999] :: Patrick Phalen wrote: :: :: > Last I heard, something like 600 people had signed up for membership on :: > the regular Zope Web site, yet all of only 3-4 people are currently :: > committing *part* of their time to the Zope Documentation Project. :: > Where is everyone else? :: :: Learning it! :-) Heh ... well, aren't we all? :-) But, as a Zope newbie (aren't we all newbies?) I still hang out on zdp, for several reasons: * Even though I don't know enough yet to write a How-to, I'm one of those people who can spot a typo from 50 paces. So I proofread and offer edits or suggestions where appropriate. When you don't have much, every little bit helps, no? * Being on the list allows you to have a voice in influencing the direction that the docs take. If you don't speak up about the format, the subject matter, the priorities that matter to you -- then you'll just have to take what you get. These are *your* docs, after all. ;-) * It allows me to follow the discussions among the writers as they wrestle mightily with the subject matter; I develop an appreciation for how difficult their task is, which in turn, makes me a little more patient about the current state of the documentation.
+----[ Brian Salisbury ]--------------------------------------------- [Snip] | 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 don't know what's going on at the code-level, and Non-programmers should be not programming. If your business is to develop web applications, you can't expect to develop applications with no programming experience. If you're not developing web applications then Zope is not the tool for you. It is important that you pick the right tool for each job. Your web programmers don't have to know Python, they have to be able to understand simple procedural programming. You can do quite a bit in pure DTML if you're willing to, and DTML is not that complicated. I, however, would not recommend Zope to anyone or any business that did not have any programming staff. Well if you have someone that can create CGI scripts/programs, they should not have a hard time building Zope applications. Seriously folks, if it takes you more than a week to be able to start doing stuff using DTML, you're in the wrong business, or you're using the wrong tool (instead of perhaps DreamWeaver or FP et. al.) ZClasses and Python Products are admittedly more advanced, but, if you have basic programming skills, there are enough examples to get you going. If you are sure you want to use Zope, but, it's all too hard there's always the resources list on the Zope site, where you can get some Zope people. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
participants (8)
-
Andrew Kenneth Milton -
Bill Anderson -
Brian Salisbury -
Christopher Petrilli -
Craig P Avnit -
Jeff K. Hoffman -
Nitin Borwankar -
Patrick Phalen