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?
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 ------------------------------------------
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>
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. :>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. i think it also is targeted at content managers? if so, then you not only have designers using zope, but also all kinds of content providers, editors & the like. and, to be honest: there ARE friendlier ways to edit content than the <textarea> (i want a <textarea-using-emacs>;)) btw. macromedias dreamweaver states some xml support, havent checked it out though. peter. :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 :------------------------------------------ : :_______________________________________________ :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 ) : -- _________________________________________________ peter sabaini, mailto: sabaini@niil.at -------------------------------------------------
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
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 )
Damian Morton wrote:
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.
Was there any ranking regarding size and download speed? For a long time I would use a wsiwyg for layout, and then fix it by hand. The result was a faster loading page, due to a smaller size. One example that sticks out was a particular page I took over for someone. They had used FP98 to build it, doing nohting more than replacing it with correct html, we chopped off 11K of useless garbage. Obviously the page l;oaded much faster. This has been _my_ primary issue with wysiwyg Of course, one must remember that wysiwyg means just that, what _you_ get. That does not mean it wil be what others get.
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.
If bad html results in page being twice or more the size of the same page with good html, I'll take good any day. My 2 bits.... -- "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." -- Carl Sagan
Bill Anderson wrote:
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.
If bad html results in page being twice or more the size of the same page with good html, I'll take good any day.
But the designer who is 'good' at design (and 'not good' at html) usually has also a good connection and good computer, so he never notices the slowness. It's only the sucker at the end of modem line (or other end of world) who sees the slowness. ------- Hannu
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
Dody
i second the motion. docs that are available now *does* help with the learning curve. but having more simple and enlightening docs (like the howtos - wish there were more) would realy help.
On Fri, Sep 24, 1999 at 09:58:35PM +0800, kedai wrote:
Much of the documentation is designed with *advance* developers in mind. It's time for Zope for Dummies.
i second the motion. docs that are available now *does* help with the learning curve. but having more simple and enlightening docs (like the howtos - wish there were more) would realy help.
Even moreso: is there a roadmap, to tell me what to read first? Cheers, -- jr 'hard wrap at 72 characters...' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
participants (14)
-
Bill Anderson -
Dody Gunawinata -
Hannu Krosing -
Jay R. Ashworth -
Jay, Dylan -
Jens Vagelpohl -
jonathon -
kedai -
Martijn Pieters -
Michael Bernstein -
Michael Hirsch -
morton＠dennisinter.com -
Peter Sabaini -
Phil Harris