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 )