Barriers to Zope popularity: Part 1: wysiwig editing
Having been using Zope for the past 8months or so I see two potential reasons as to why more people at my work havn't taken to Zope. One discussed of late is WYSIWYG editing. I HATE wysiwyg editing. It invariably makes a mess. It seems that a lot of people disagree with me and find a system that allows wysiwyg editing to make the creation of good web pages simplier. Possible solution: Frontpage seems to me to be the weapon of choice for these "amateur" web authors. I imagine that frontpage will support webdav in the future but for now I think it would be possible to support a subset of the frontpage web extensions. At least the ones that deal with authoring etc. It all uses HTTP so I imagine it would be as hard to implement as webdav support was. Products could even be created for searching and web discussion extensions but I would think that this would detract from Zope and add support for frontpage more than the reverse. The next problem with this is how to edit partial pages in a wysiwyg editor. Ie how to edit a whole page when every DTML doc has <dtml-var standard_html_header> etc in. What we could do is to have a special render method that produces an html document which has all the html the real rendered page does as well as the DTML cunningly encoded in it. Then a special update method can take this an process the changes to the parts of the document as neccesary. For instance <!--#var standard_html_header--> <h2><!--#var title_or_id--></h2> <p> This is the <!--#var id--> Document. </p> <!--#var standard_html_footer--> could be rendered as <!--%begin-dtml-var standard_html_header--> <html> <head> <body> <!--%end-dtml-var standard_html_header--> <h2><!--%begin-dtml-var title_or_id-->My Documents Title<!--%end-dtml-var title_or_id--></h2> <p> This is the <!--%begin-dtml-var id-->myDoc<!--%end-dtml-var id--> Document. </p> <!--%begin-dtml-var standard_html_header--> </body> <!--%end-dtml-var standard_html_header--> or something similar. As long as ALL the dtml in a document can be encoded in this way and the visual editor leaves the comments alone then this will work. This leads to the question of how the update method will deal with updates to include documents/methods/properties? Not sure. It could either, give an exception (might be possible with WEC), just ignore them, or try and perform the updates on the other objects (potentially messy but possible in limited cases???). Thoughts?
I know this would be a major pain, and it's just a crazy idea, but perhaps the best way to do wysiwyg editing wouldn't be modifying an existing wysiwyg tool to be zope-aware? What good html editors we have the source for? I once advocated Galway; it supports javascript, vrml and a lot of crazy stuff, it's probably feasible to make it zope-aware and I'm sure the author would like it. But, Galway isn't (yet) wysiwyg. Still, adding wysiwyg _previewing_ (like previous versions of some widely used Windows tool with a name I can't remember right now) via a gtkxmhtml widget would be a matter of a few hours. Previewing _with_ Zope awareness is trickier, it would probably have to send the whole source back to Zope to process; perhaps the Right Way to do that would be adding a way of just sending some DTML to Zope and getting the HTML back. Ok, this isn't truly wysiwyg. But a similar reasoning applies to true wysiwyg editors - again, any good one with sources? (I'll slam the first one who says ``amaya'', it's a joke of an editor). Perhaps I'm excited with Galway because I don't like true wysiwyg for the web either :-) <advocacy> Actually, there's no wysiwyg web-editing. The best you can expect is wysiwyug (what you see is what you usually get) considering that each browser will mangle your page in a different way. </advocacy> Then again I have never checked out the new Adobe thingie eveyone's hyping. Have to try someday. But IMHO the _best_ way (and more Zope-feeling) is some sort of browser-based edition, like with Oracle's WebDB Site Manager. I don't think it's hard to do with Zope; if anyone out there has seen Site Manager, please yell. I'll check if I can put my Oracle box on the web; if I can, I'll put a demo site you all can connect to and ``manage'' just to see how it works. Then we can work on something similar. After all, it's part of my job :-) <depth> Basically, translating all intrinsic Oracleisms to Zope, it would consist on building pages with no real content; everything would be read from objects elsewhere, and things like TinyTable (and <dtml-in>) would help here. Then in the ``managing edition'' of the page what we get is a plain rendering, but with ``properties'', ``delete'', ``new'' buttons near all objects (of course ``new'' appears only inside list-like sections). This is how WebDB does it; we'd probably like to add some finer control like allowing edition of the page skeleton. The biggest disadvantage of WebDB is that the page structure is pretty much fixed; you can make it _look_ a lot different, but in the end it's as recognizeable as squishdot (regardless of the theme used, you can see it's squishdot). </depth> []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
For those who want to see what's so great about Oracle WebDB's Site Manager and can't wait, here's the URL at Oracle's technet (requires free subscription; anyone may subscribe, the only con is that Oracle will ``spam'' you from time to time). technet.oracle.com/product/tools/webdb/showcase/quicktour/wb4_1.htm (this is the place inside the ``WebDB quick tour'' that talks about the Site Manager.) []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
On Thu, 23 Sep 1999, Lalo Martins wrote:
I know this would be a major pain, and it's just a crazy idea, but perhaps the best way to do wysiwyg editing wouldn't be modifying an existing wysiwyg tool to be zope-aware? What good html editors we have the source for?
Frontpage 2000 can do webdav to a certain extent already, that's what the Web Folders are. Also if you search the Ms website for somthing called 'kissfp', it will give you a nice warm glow ;¬). It allows Frontpage 2000 to use FTP in an intelligent way to conect to Zope. HTH Phil phil@philh.org -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Jay, Dylan Sent: Thursday, September 23, 1999 8:01 AM To: 'zope@zope.org'; 'zope-dev@zope.org' Subject: [Zope] Barriers to Zope popularity: Part 1: wysiwig editing Having been using Zope for the past 8months or so I see two potential reasons as to why more people at my work havn't taken to Zope. One discussed of late is WYSIWYG editing. I HATE wysiwyg editing. It invariably makes a mess. It seems that a lot of people disagree with me and find a system that allows wysiwyg editing to make the creation of good web pages simplier. Possible solution: Frontpage seems to me to be the weapon of choice for these "amateur" web authors. I imagine that frontpage will support webdav in the future but for now I think it would be possible to support a subset of the frontpage web extensions. At least the ones that deal with authoring etc. It all uses HTTP so I imagine it would be as hard to implement as webdav support was. Products could even be created for searching and web discussion extensions but I would think that this would detract from Zope and add support for frontpage more than the reverse. The next problem with this is how to edit partial pages in a wysiwyg editor. Ie how to edit a whole page when every DTML doc has <dtml-var standard_html_header> etc in. What we could do is to have a special render method that produces an html document which has all the html the real rendered page does as well as the DTML cunningly encoded in it. Then a special update method can take this an process the changes to the parts of the document as neccesary. For instance <!--#var standard_html_header--> <h2><!--#var title_or_id--></h2> <p> This is the <!--#var id--> Document. </p> <!--#var standard_html_footer--> could be rendered as <!--%begin-dtml-var standard_html_header--> <html> <head> <body> <!--%end-dtml-var standard_html_header--> <h2><!--%begin-dtml-var title_or_id-->My Documents Title<!--%end-dtml-var title_or_id--></h2> <p> This is the <!--%begin-dtml-var id-->myDoc<!--%end-dtml-var id--> Document. </p> <!--%begin-dtml-var standard_html_header--> </body> <!--%end-dtml-var standard_html_header--> or something similar. As long as ALL the dtml in a document can be encoded in this way and the visual editor leaves the comments alone then this will work. This leads to the question of how the update method will deal with updates to include documents/methods/properties? Not sure. It could either, give an exception (might be possible with WEC), just ignore them, or try and perform the updates on the other objects (potentially messy but possible in limited cases???). Thoughts? _______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope (To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
I think "DOCUMENTATION" is more than anything else, the greatest barrier to people using Zope. Probably Zope is too powerful for its own good. You've got this tons of features that you can exploit, so much of good thing, but there is currently no document that actually guides a beginner gently and hides the more advance features from them. For example, about storing data. In Cold Fusion/ASP/Perl, there aren't many ways to store a data, flat file or a database. That's easy to explain to a beginner..Do it this way, only. Limited but simple. With Zope, you got Persistent database, SQL database, and tons of cool tricks to do with them. I see one beginner example (can't remember the article) where it guides the user to create a WebBoard using Python/Persistent. A beginner would simply lost. A ZSQL method would be a lot simpler, as SQL is easier to understand. Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies. Dody Phil Harris wrote:
Frontpage 2000 can do webdav to a certain extent already, that's what the Web Folders are.
Also if you search the Ms website for somthing called 'kissfp', it will give you a nice warm glow ;¬).
It allows Frontpage 2000 to use FTP in an intelligent way to conect to Zope.
HTH
Phil phil@philh.org
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Jay, Dylan Sent: Thursday, September 23, 1999 8:01 AM To: 'zope@zope.org'; 'zope-dev@zope.org' Subject: [Zope] Barriers to Zope popularity: Part 1: wysiwig editing
Having been using Zope for the past 8months or so I see two potential reasons as to why more people at my work havn't taken to Zope.
One discussed of late is WYSIWYG editing. I HATE wysiwyg editing. It invariably makes a mess. It seems that a lot of people disagree with me and find a system that allows wysiwyg editing to make the creation of good web pages simplier.
Possible solution:
Frontpage seems to me to be the weapon of choice for these "amateur" web authors. I imagine that frontpage will support webdav in the future but for now I think it would be possible to support a subset of the frontpage web extensions. At least the ones that deal with authoring etc. It all uses HTTP so I imagine it would be as hard to implement as webdav support was. Products could even be created for searching and web discussion extensions but I would think that this would detract from Zope and add support for frontpage more than the reverse. The next problem with this is how to edit partial pages in a wysiwyg editor. Ie how to edit a whole page when every DTML doc has <dtml-var standard_html_header> etc in. What we could do is to have a special render method that produces an html document which has all the html the real rendered page does as well as the DTML cunningly encoded in it. Then a special update method can take this an process the changes to the parts of the document as neccesary. For instance
<!--#var standard_html_header--> <h2><!--#var title_or_id--></h2> <p> This is the <!--#var id--> Document. </p> <!--#var standard_html_footer-->
could be rendered as
<!--%begin-dtml-var standard_html_header--> <html> <head> <body> <!--%end-dtml-var standard_html_header--> <h2><!--%begin-dtml-var title_or_id-->My Documents Title<!--%end-dtml-var title_or_id--></h2> <p> This is the <!--%begin-dtml-var id-->myDoc<!--%end-dtml-var id--> Document. </p> <!--%begin-dtml-var standard_html_header--> </body> <!--%end-dtml-var standard_html_header-->
or something similar.
As long as ALL the dtml in a document can be encoded in this way and the visual editor leaves the comments alone then this will work.
This leads to the question of how the update method will deal with updates to include documents/methods/properties? Not sure. It could either, give an exception (might be possible with WEC), just ignore them, or try and perform the updates on the other objects (potentially messy but possible in limited cases???).
Thoughts?
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
At 03:50 23/09/99 , Dody Gunawinata wrote:
I think "DOCUMENTATION" is more than anything else, the greatest barrier to people using Zope. Probably Zope is too powerful for its own good. You've got this tons of features that you can exploit, so much of good thing, but there is currently no document that actually guides a beginner gently and hides the more advance features from them.
For example, about storing data. In Cold Fusion/ASP/Perl, there aren't many ways to store a data, flat file or a database. That's easy to explain to a beginner..Do it this way, only. Limited but simple. With Zope, you got Persistent database, SQL database, and tons of cool tricks to do with them. I see one beginner example (can't remember the article) where it guides the user to create a WebBoard using Python/Persistent. A beginner would simply lost. A ZSQL method would be a lot simpler, as SQL is easier to understand.
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
Dody
What many people forget here is that Zope is a Web Application Platform. It is, first and foremost, designed as a framework for applications. All the DTML Methods and Folder objects and whatnot, are standard objects to help you design an interface, they are part of and build upon the Zope framework. Together with the ZODB, security, the web interface, the marshalling of variable types and RDBMS integration, Zope makes one heck of a Web Application Platform. Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay away from Zope. Frontpage is for dummies. As far as DTML editing goes: DTML was designed to put a face on the application, not so much as to be used on its own. DTML is very powerful for this, but its features also make it unsuitable for WISYWIG editing. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
It is true. A really wicked and powerful web application server. No doubt about that. Zope for dummies (a book or something similar, not Zope lite version :0)..for beginner (not always for beginner developer)..especially for Windows based developers (A lot of them here, too many to be ignored if we are talking about market share)-ASP,CF etc..And an awful lots of company uses ASP (free and Microsoft) for Intranet..And if you've known just VBScript, you'd think Zope is only for rocket scientist. And students as well very important, because many would use just the awful Perl for CGI processing..(Perl is almost a standard in many unis). 'Dummies' are the majorities, and I think its Zope's best interest to lure them. This is we want more people to use Zope. The best product doesn't always equate to market share. The one that people can use and understand will (doesn't apply to Microsoft:O).. My point still is the good ol' documentations for beginners the way to go, if we are talking about increasing market share. Let's do something about it. Dody Martijn Pieters wrote:
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
Dody
What many people forget here is that Zope is a Web Application Platform. It is, first and foremost, designed as a framework for applications.
All the DTML Methods and Folder objects and whatnot, are standard objects to help you design an interface, they are part of and build upon the Zope framework. Together with the ZODB, security, the web interface, the marshalling of variable types and RDBMS integration, Zope makes one heck of a Web Application Platform.
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay away from Zope. Frontpage is for dummies.
As far as DTML editing goes: DTML was designed to put a face on the application, not so much as to be used on its own. DTML is very powerful for this, but its features also make it unsuitable for WISYWIG editing.
-- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
i concur 100% with martijn. zope is an application server and not a design tool for web pages. everyone who has seen the code produced by these design "tools" (first and foremost frontpage, the true tool for dummies) can see that it's an insult to even the most superficial of html-writers. i am constantly amazed at how the "convenience" of WYSIWIG in frontpage and other editors can blow up a little text without formatting into something 10 times the size choc full of application- and platform-specific "html", if one can still call it that. this is something zope should not strive for. jens Jens Vagelpohl Systems Administrator Washtenaw Development Council
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Martijn Pieters Sent: Thursday, September 23, 1999 08:09 To: Dody Gunawinata; Phil Harris Cc: Jay, Dylan; zope@zope.org; zope-dev@zope.org Subject: [Zope] Re: [Zope-dev] RE: [Zope] Barriers to Zope popularity: Part 1:wysiwig editing wysiwig editing
<snippers>
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay away from Zope. Frontpage is for dummies. </snippers>
Martijn Pieters writes:
At 03:50 23/09/99 , Dody Gunawinata wrote:
I think "DOCUMENTATION" is more than anything else, the greatest barrier to people using Zope. Probably Zope is too powerful for its own good. You've got this tons of features that you can exploit, so much of good thing, but there is currently no document that actually guides a beginner gently and hides the more advance features from them.
As a new zope user I agree with you. [snip]
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
I've thought a lot about that. I'd rather have something a little less "dumbed down" than that, but something lower level would be nice.
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay away from Zope. Frontpage is for dummies.
This reminds me of the annoying attitude of many Linux users: "It should be difficult to use--let's not make it easy for beginners." As long as the power of the tool is not reduced, making things easy is always good. In this case, Dody was speaking of documentation. The documentation assumes an awful lot and is poorly organized. Suppose someone were to write a book on Zope and DTML--say a good users manual, complete to introduction to the syntax and a decent explanation of inheritance and probably a short intro to python, too. How would this detract from your experience? It would just make Zope easier for developers to get started. Is this bad? You can't have a successful product and only let experienced users play. Every experienced user starts out inexperienced. Zope is such an unusual paradigm that very few designers are going to come in with a strong intuitive understanding of it.
As far as DTML editing goes: DTML was designed to put a face on the application, not so much as to be used on its own. DTML is very powerful for this, but its features also make it unsuitable for WISYWIG editing.
I agree with you wholeheartedly, but I fail to see any relevance to the question at hand. Documentation and WYSIWYG editing are orthogonal. One can have either without the other. -- --Michael
On Thu, 23 Sep 1999, Martijn Pieters wrote:
At 03:50 23/09/99 , Dody Gunawinata wrote:
I think "DOCUMENTATION" is more than anything else, the greatest barrier to people using Zope. << paragraphs deleted >> Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
What many people forget here is that Zope is a Web Application Platform. It is, first and foremost, designed as a framework for applications.
That doesn't negate the need for Documentation.
marshalling of variable types and RDBMS integration, Zope makes one heck of a Web Application Platform.
True. To use a Web Application Platform, one has to know the tools. The easy way to find out what those tools are, and how to use them, is by going through the documentation.
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay
If one is an experienced Web Application Developer, the documentation _might_ be, but probably isn't acceptable. If one is supposed to manage the content on a website, and not an experienced Web Application developer, the documentation is at best, inadequate.
away from Zope. Frontpage is for dummies.
What has Frontpage to do with Zope? They are completely different applications. One other point: Documentation can never contain too many examples. xan jonathon
Let's us not forget that Zope is an open source product now. Having DC doing most of the development of Zope sometimes can make us forget that Open Source means a community collaboration. That would include the documentation. It is clear that the documentation currently lacks especially for beginners. But that's not the fault of DC itself, because creating documentation, especially for beginners can be a lot harder (and time consuming because we have to assume that they know nothing), and DC should spend time better on documenting and explaining the latest/coolest features instead. So it's up to us, the community, to create the 'book'. We do need a 'book' with decent chapters. Lots of how-to is nice if you are already know what you are doing, but the information is fragmented, and it's no use for beginners. So, it's another project proposal..let's write a book on Zope. Individual(s) can work on chapters after having agreed of the general structures. We'll cover the basic from DTML, with working projects/products example in the end, to Python programming, and up to the higher end. It's not an easy task as the transition from one chapter to another needs to be carefully defined, as if it is not, they would be difficult for new comer to use. An open source book. For the quality, the 'book' should be good enough to be sold commercially in bounded/printed form. A definitive guide to Zope. As this is electronic, there is no limitation on how 'thick' the book can be. We can use tons and tons of example in the 'book'. Another requirement, they should use less the word 'namespaces' :0)..I hate the word because I've seen loads of them in the current document (and in Python tutorial as well) So ? Dody jonathon wrote:
On Thu, 23 Sep 1999, Martijn Pieters wrote:
At 03:50 23/09/99 , Dody Gunawinata wrote:
I think "DOCUMENTATION" is more than anything else, the greatest barrier to people using Zope. << paragraphs deleted >> Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
What many people forget here is that Zope is a Web Application Platform. It is, first and foremost, designed as a framework for applications.
That doesn't negate the need for Documentation.
marshalling of variable types and RDBMS integration, Zope makes one heck of a Web Application Platform.
True. To use a Web Application Platform, one has to know the tools. The easy way to find out what those tools are, and how to use them, is by going through the documentation.
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay
If one is an experienced Web Application Developer, the documentation _might_ be, but probably isn't acceptable.
If one is supposed to manage the content on a website, and not an experienced Web Application developer, the documentation is at best, inadequate.
away from Zope. Frontpage is for dummies.
What has Frontpage to do with Zope? They are completely different applications.
One other point: Documentation can never contain too many examples.
xan
jonathon
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
At 05:48 24/09/99 , Dody Gunawinata wrote:
Let's us not forget that Zope is an open source product now. Having DC doing most of the development of Zope sometimes can make us forget that Open Source means a community collaboration. That would include the documentation. It is clear that the documentation currently lacks especially for beginners. But that's not the fault of DC itself, because creating documentation, especially for beginners can be a lot harder (and time consuming because we have to assume that they know nothing), and DC should spend time better on documenting and explaining the latest/coolest features instead.
So it's up to us, the community, to create the 'book'. We do need a 'book' with decent chapters. Lots of how-to is nice if you are already know what you are doing, but the information is fragmented, and it's no use for beginners.
So, it's another project proposal..let's write a book on Zope. Individual(s) can work on chapters after having agreed of the general structures. We'll cover the basic from DTML, with working projects/products example in the end, to Python programming, and up to the higher end. It's not an easy task as the transition from one chapter to another needs to be carefully defined, as if it is not, they would be difficult for new comer to use. An open source book. For the quality, the 'book' should be good enough to be sold commercially in bounded/printed form. A definitive guide to Zope. As this is electronic, there is no limitation on how 'thick' the book can be. We can use tons and tons of example in the 'book'.
Another requirement, they should use less the word 'namespaces' :0)..I hate the word because I've seen loads of them in the current document (and in Python tutorial as well)
Please join the ZDP! The Zope Documentation Project has been founded just for this purpose, see the site at: http://zdp.zope.org/ -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
Somehow I forget the Zbook project, oh well. And I did subscribe to the ZDP mailing list, with averages 2 messages in the digest mode :(. There should be more people supporting this. Martin, how can people get involved ? Is there any 'designed' chapter topics already that people can plug in ? Dody Martijn Pieters wrote:
At 05:48 24/09/99 , Dody Gunawinata wrote:
Please join the ZDP! The Zope Documentation Project has been founded just for this purpose, see the site at:
-- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
At 07:44 24/09/99 , Dody Gunawinata wrote:
Somehow I forget the Zbook project, oh well. And I did subscribe to the ZDP mailing list, with averages 2 messages in the digest mode :(. There should be more people supporting this. Martin, how can people get involved ? Is there any 'designed' chapter topics already that people can plug in ?
Dody
Unfortunately, three very active ZDP people all seem to be on vacation right now. But Stephan Richter maintains a ZDP information page at: http://www.zope.org/Members/srichter Check it out for some information on the current status. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
Visited the place, and there is nothing obvious about the status of the project. No obvious way what needs to be done, and how people can join. This should be marketed better. dody Martijn Pieters wrote:
At 07:44 24/09/99 , Dody Gunawinata wrote:
Somehow I forget the Zbook project, oh well. And I did subscribe to the ZDP mailing list, with averages 2 messages in the digest mode :(. There should be more people supporting this. Martin, how can people get involved ? Is there any 'designed' chapter topics already that people can plug in ?
Dody
Unfortunately, three very active ZDP people all seem to be on vacation right now. But Stephan Richter maintains a ZDP information page at:
http://www.zope.org/Members/srichter
Check it out for some information on the current status.
-- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
Dody Gunawinata wrote:
Visited the place, and there is nothing obvious about the status of the project. No obvious way what needs to be done, and how people can join. This should be marketed better.
Okay, you've been appointed Official ZDP Marketing Coordinator as of now. :) (I'm back from my week's vacation). Current important ZDP projects include: FAQ Tool - I think we're currently in the design phase; Stephan Richter knows most about this ZBook - coordinate with Tom Deprez Upgrade of ZDP site to Zope 2 - Brian Brown's working on this I could give you a login to the current ZDP site if you like (mail me for one), and you can make some pages for easy entry into the ZDP. That certainly would help a lot. Let's move this discussion to the ZDP List (which I haven't read yet so I may be behind things already :). Regards, Martijn
I almost choke when Martijn pointed out this 'thing' http://zdp.zope.org/guide is supposed to be a rough table of content for Z developer's guide. I think we should laid that entry to rest, remove it from the official ZDP page and extends ZBooks instead (waiting to hear from Tom if he got something). That *thing* gives ZDP a bad name :) This is from Kamon. This looks good to me for being part of ZBook. I'll put up my detailed proposal for the other part for the book. I hope Tom would be responding to message.
Setting up a Zope server System requirements Installation steps Zope installation directory structure Important config files Zope with another Web server (Apache, IIS, ...): PCGI Virtual servers with Zope
Zope security Authentication with Zope SSL with Zope
Zope system administration Activity logging Backup and restoration Versioning Performance tuning
Dody
Dody Gunawinata wrote:
I almost choke when Martijn pointed out this 'thing' http://zdp.zope.org/guide is supposed to be a rough table of content for Z developer's guide.
Well, it's been around for a while. ZBook may supercede it, I'm not sure. Anyway, I didn't mean to make you choke on it, certainly. It's a good source for some ideas on what to include in a ZBook.
I think we should laid that entry to rest, remove it from the official ZDP page and extends ZBooks instead (waiting to hear from Tom if he got something).
Feel free to produce a new table of contents. :)
That *thing* gives ZDP a bad name :)
Whoops! I thought it was at least *something*. Of course it's completely unfilled right now..
This is from Kamon. This looks good to me for being part of ZBook. I'll put up my detailed proposal for the other part for the book. I hope Tom would be responding to message. [Kamos' outline]
Yes, Kamon's stuff looks good. I'm not sure what's up with Tom these days. Tom? Regards, Martijn
Dody Gunawinata wrote:
Let's us not forget that Zope is an open source product now. Having DC doing most of the development of Zope sometimes can make us forget that Open Source means a community collaboration. That would include the documentation. It is clear that the documentation currently lacks especially for beginners. But that's not the fault of DC itself, because creating documentation, especially for beginners can be a lot harder (and time consuming because we have to assume that they know nothing), and DC should spend time better on documenting and explaining the latest/coolest features instead.
So it's up to us, the community, to create the 'book'. We do need a 'book' with decent chapters. Lots of how-to is nice if you are already know what you are doing, but the information is fragmented, and it's no use for beginners.
Take a look at the Zope Documentation Project! http://zdp.zope.org and join the zdp mailing list. Regards, Martijn
Martijn Pieters wrote:
At 03:50 23/09/99 , Dody Gunawinata wrote:
<stuff deleted>
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
<stuff deleted>
All the DTML Methods and Folder objects and whatnot, are standard objects to help you design an interface, they are part of and build upon the Zope framework. Together with the ZODB, security, the web interface, the marshalling of variable types and RDBMS integration, Zope makes one heck of a Web Application Platform.
In particular, the deep integration of an OO philosophy is what gives Zope an edge, but also creates some problems with existing tools that grew out of a different mindset.
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay away from Zope. Frontpage is for dummies.
Whoa, there. You're awfully close to saying that designers are dummies. I'm a designer (among other things), and I use whatever tool is appropriate. A good WYSIWYG editor (such as Dreamweaver) lets you experiment with the layout of your page, and does not hide or mangle the underlying code. I mean, who really wants to manually rearrange a three column four row table structure with a rowspan in the middle into a four column three row table with a colspan and ensure that every last dang cell has a non-breaking space in it? And Frontpage isn't for dummies, it's for people who don't know better, or who's bosses don't know better. A couple of years ago, I was working at a web hosting startup (now defunct) that decided to standardize on FP because it was cheap. I changed their mind eventually by demonstrating how FP mangled perfectly reasonable javascript. And many corporate users are in the same boat I was in. Now, it's true that most WYSIWYG editors aren't very good at understanding dynamic page generation (except Homesite), but that doesn't change the fact that interface designers need to work visually.
As far as DTML editing goes: DTML was designed to put a face on the application, not so much as to be used on its own. DTML is very powerful for this, but its features also make it unsuitable for WISYWIG editing.
I respectfully disagree. Homesite (as an example) does very well as a code based editor that understands dynamic page generation, and although it's primarily geared towards using ColdFusion's CFML code, people have taught it to edit ASP and Perl as well. There is no reason that it couldn't understand DTML and Python. As a WYSIWYG editor Homesite does have it's shortcomings, but it integrates beautifully with Dreamweaver (an excellent WYSIWYG editor), such that code can be passed from one to the other seamlessly, without any mangling. Macromedia calls this 'round-trip HTML', Dreamweaver does this same trick with BBEdit on Macs. Dreamweaver has a number of other endearing features, such as dynamic highlighting: when you select an element in the WYSIWYG view and switch to the HTML view, the element in question is highlighted, making it very easy to find. In short, there are many appropriate uses of WYSIWYG editors (note that I do not think that adding or editing content are among these uses), and I don't think it would be good to ignore the needs of interface designers. Also, keep in mind that _graphic_ designers are a different breed from interface designers, and have needs that I do not think Zope is appropriate for. Although it would be nice if Fireworks was WebDAV enabled.... For myself, I think that Zope is the first tool to take a serious stab at the needs of Information Architects for organizing content in dynamic and meaningful ways, but I'm also a designer, and I'm also a coder of sorts. In the web world, we all wear many hats, and have diverse needs. Finally, I believe that one of the things that Zope has going for it is its promiscuity WRT protocols and standards. In other words, even if better support for a WYSIWYG environment were added somehow, it would not diminish your ability to work with Zope in your preferred way, be it it through the management interface, FTP, Emacs, or whatever. Respectfully, Michael Bernstein.
There was a discussion on slashdot a while ago about this wysiwyg html editors issue. One posting, in particular, was particularily insightfull. The poster had collected all the homepage urls from the signatures of people involved in the discussion. He then organised them roughly according to the position that person held in the wysiwig vs html debate. Admittedly its a relatively subjective evaluation, but this guy found that the posters advocating straight html editors generally had far uglier home pages than the people advocating wysiwig editors. What it comes down to is this, and its really simple: The less you have to think about _how_ youre doing something, the more time you have to think about _what_ youre doing, and so you will tend to improve your "what youre doing" skills more than your "how youre doing it" skills. In my mind, being 'good' at html is a huge waste of human material, especially if it comes at the expense of creativity. Only a few people are expected to be 'good' at postscript, the rest is all automated. It is a sad reflection on the backward nature of the web that being 'good' at html is seen as desireable. ----- Original Message ----- From: Michael Bernstein <mbernstein@profitscape.net> To: Martijn Pieters <mj@antraciet.nl> Cc: Dody Gunawinata <dody_g@eles.com>; Phil Harris <phil@philh.org>; Jay, Dylan <djay@lucent.com>; <zope@zope.org>; <zope-dev@zope.org> Sent: Thursday, September 23, 1999 4:47 PM Subject: [Zope-dev] Re: [Zope] Re: [Zope-dev] RE: [Zope] Barriers to Zope popularity: Part1:wysiwig editingwysiwig editing1:wysiwig editingwysiwig editing
Martijn Pieters wrote:
At 03:50 23/09/99 , Dody Gunawinata wrote:
<stuff deleted>
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
<stuff deleted>
All the DTML Methods and Folder objects and whatnot, are standard objects to help you design an interface, they are part of and build upon the Zope framework. Together with the ZODB, security, the web interface, the marshalling of variable types and RDBMS integration, Zope makes one heck of a Web Application Platform.
In particular, the deep integration of an OO philosophy is what gives Zope an edge, but also creates some problems with existing tools that grew out of a different mindset.
Zope was designed for Web Application Developers, not designers. The documentation follows this design. I actually feel that dummies should stay away from Zope. Frontpage is for dummies.
Whoa, there. You're awfully close to saying that designers are dummies.
I'm a designer (among other things), and I use whatever tool is appropriate. A good WYSIWYG editor (such as Dreamweaver) lets you experiment with the layout of your page, and does not hide or mangle the underlying code.
I mean, who really wants to manually rearrange a three column four row table structure with a rowspan in the middle into a four column three row table with a colspan and ensure that every last dang cell has a non-breaking space in it?
And Frontpage isn't for dummies, it's for people who don't know better, or who's bosses don't know better. A couple of years ago, I was working at a web hosting startup (now defunct) that decided to standardize on FP because it was cheap. I changed their mind eventually by demonstrating how FP mangled perfectly reasonable javascript. And many corporate users are in the same boat I was in.
Now, it's true that most WYSIWYG editors aren't very good at understanding dynamic page generation (except Homesite), but that doesn't change the fact that interface designers need to work visually.
As far as DTML editing goes: DTML was designed to put a face on the application, not so much as to be used on its own. DTML is very powerful for this, but its features also make it unsuitable for WISYWIG editing.
I respectfully disagree. Homesite (as an example) does very well as a code based editor that understands dynamic page generation, and although it's primarily geared towards using ColdFusion's CFML code, people have taught it to edit ASP and Perl as well. There is no reason that it couldn't understand DTML and Python.
As a WYSIWYG editor Homesite does have it's shortcomings, but it integrates beautifully with Dreamweaver (an excellent WYSIWYG editor), such that code can be passed from one to the other seamlessly, without any mangling. Macromedia calls this 'round-trip HTML', Dreamweaver does this same trick with BBEdit on Macs.
Dreamweaver has a number of other endearing features, such as dynamic highlighting: when you select an element in the WYSIWYG view and switch to the HTML view, the element in question is highlighted, making it very easy to find.
In short, there are many appropriate uses of WYSIWYG editors (note that I do not think that adding or editing content are among these uses), and I don't think it would be good to ignore the needs of interface designers.
Also, keep in mind that _graphic_ designers are a different breed from interface designers, and have needs that I do not think Zope is appropriate for. Although it would be nice if Fireworks was WebDAV enabled....
For myself, I think that Zope is the first tool to take a serious stab at the needs of Information Architects for organizing content in dynamic and meaningful ways, but I'm also a designer, and I'm also a coder of sorts. In the web world, we all wear many hats, and have diverse needs.
Finally, I believe that one of the things that Zope has going for it is its promiscuity WRT protocols and standards. In other words, even if better support for a WYSIWYG environment were added somehow, it would not diminish your ability to work with Zope in your preferred way, be it it through the management interface, FTP, Emacs, or whatever.
Respectfully,
Michael Bernstein.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
participants (12)
-
Dody Gunawinata -
Jay, Dylan -
Jens Vagelpohl -
jonathon -
Lalo Martins -
Martijn Faassen -
Martijn Pieters -
Michael Bernstein -
Michael Hirsch -
morton＠dennisinter.com -
Patrick Phalen -
Phil Harris