Wysiwyg and the merits of a webinterface - some considerations
Once in a while the subject of wysiwyg comes up on the list, as it did in the last few days. TO summarize the discussion as I understand it: The main problem is that people want a wysiwyg front end for their Zope database/web environment. On first consideration this seems to be something very desirable especially for end users. The problem of content management in web applications is present in other web application servers as well. Therefore various wysiwyg environments have their own solutions for this problem. Just some examples I happen to be acquainted with: - dreamweaver makes a difference between editable zones and ineditable zones in html; - homesite can be taught to program html-ish extensions (CFML, ASP, dtml should not be to much of a problem) and - Frontpage does this a solution of the infamous mix of client and serverside elements (which results in an inpenetrable and unmaintainable soup) The wysiwyg approach also seems to have the inevitable consequence that all of these editors mangle your html in an inexcusable way - so what you get may not at all be what you want. There may be other examples which do, but I am not aware of them. Zope has some inherent features that make these solutions not adequate, as Michael Bernstein (I believe) pointed out. They have to do with the difference between rendered documents and source code. This is further complicated by the separation of code of and layout as a result of which al templates and logic tend to be in different documents than where actual textual content is managed. I have been contemplating this issue for some time now, because it is crucial in an academic environment in which all sorts of people with all sorts of abilities (not just designers but also 'just' students and teachers and secretaries) are going to be giving input to a website. Considering all I have come to the conclusion that a webinterface will be the way to go, at least for me. My considerations: - many students are using hotmail. They complain, but that is because of slowness and ads. The interface, even if it's nothing special, gives them no problems. - I have been looking closely at some web based learning frameworks lately (because I am building one in Zope). They all promise a complete management system for courses and learning material. Some are shareware or freeware and some are very expensive solutions. They _all_ have web based interfaces, and it seems to be no problem at all for teachers. SOme of them are difficult to use, but that's because of their closed nature and their bad organization (this in contrast to Zope). - browsers offer a familiar environment for almost anyone. They do not have to learn another interface if they are editing through the web - users/content managers only _have_ to edit content and not need to occupy themselves with other issues, which is actually a relief for many of them. Zope has the added advantage that it is very agnostic in the integration of file types (by which pdf, msword and powerpoint can be uploaded just as easily as web pages) The only issue at the moment is that the current management interface (while it is a pleasure to work with for developers) is not at all useful for non-developers. All taken together I do not thing there will be a solution in the direction of wysiwyg editors. Instead I would plea for the development of a toolkit for end user web-based editing environments, as I believe many of us are developing them at the moment. Is anyone interested? Ideas? Comments? Rik Hoekstra
[I removed the ZDP from the email, as most ZDP people are on the zope list.] Rik Hoekstra wrote:
Once in a while the subject of wysiwyg comes up on the list, as it did in the last few days. TO summarize the discussion as I understand it: The main problem is that people want a wysiwyg front end for their Zope
Perhaps there's a farther step backwards. The following people want the following things: 1) Some need to put the simplest possible tool in their casual users' hands, such as Netscape Composer. 2) Content managers need a very productive environment for managing content, including lite DTML scripting. 3) Developers need a productive environment for manipulating the object model, working with relational databases, debugging problems, etc. I posit that wysiwyg is definately the road for the first audience. The second audience is firmly split between those that want wysiwyg (Dreamweaver) and those that want to see the tags. The third audience almost uniformly shuns wysiwyg. Even worse, the second and third audience only cares about one tool: the one that they have already learned. [very good analysis snipped]
The wysiwyg approach also seems to have the inevitable consequence that all of these editors mangle your html in an inexcusable way - so what you get may not at all be what you want.
That's a really, really good point. I'll steal it. :^)
There may be other examples which do, but I am not aware of them.
Zope has some inherent features that make these solutions not adequate, as Michael Bernstein (I believe) pointed out. They have to do with the difference between rendered documents and source code. This is further complicated by the separation of code of and layout as a result of which al templates and logic tend to be in different documents than where actual textual content is managed.
You've identified one extreme of the problem: Zope is wildly object oriented and delivers powerful concepts that are quite unique, thus don't map into traditional tools. The other end of the problem is that nearly all existing tools have basic metaphors -- stupid files or stupid data -- that don't have the semantics of the web object system.
I have been contemplating this issue for some time now, because it is crucial in an academic environment in which all sorts of people with all sorts of abilities (not just designers but also 'just' students and teachers and secretaries) are going to be giving input to a website. Considering all I have come to the conclusion that a webinterface will be the way to go, at least for me.
My considerations: - many students are using hotmail. They complain, but that is because of slowness and ads. The interface, even if it's nothing special, gives them no problems. - I have been looking closely at some web based learning frameworks lately (because I am building one in Zope). They all promise a complete management system for courses and learning material. Some are shareware or freeware and some are very expensive solutions. They _all_ have web based interfaces, and it seems to be no problem at all for teachers. SOme of them are difficult to use, but that's because of their closed nature and their bad organization (this in contrast to Zope). - browsers offer a familiar environment for almost anyone. They do not have to learn another interface if they are editing through the web
This is a crucial point. Once you leave the browser you make the first two classes of audience above think too much about the tool. People understand browsers today.
- users/content managers only _have_ to edit content and not need to occupy themselves with other issues, which is actually a relief for many of them. Zope has the added advantage that it is very agnostic in the integration of file types (by which pdf, msword and powerpoint can be uploaded just as easily as web pages)
The only issue at the moment is that the current management interface (while it is a pleasure to work with for developers) is not at all useful for non-developers.
If the people are just storing documents, our integration with Netscape publishing is good. The problem quickly resurfaces when, for instance, you want them to work with a form that you've created.
All taken together I do not thing there will be a solution in the direction of wysiwyg editors.
There might be, we'll see. We certainly know that people hate the TEXTAREA. In our defense, we have worked _awfully_ hard to support the protocols (FTP, HTTP PUT, WebDAV) that should allow you to use other tools.
Instead I would plea for the development of a toolkit for end user web-based editing environments, as I believe many of us are developing them at the moment. Is anyone interested? Ideas? Comments?
I'd love to see someone come up with a professional statement of the situation -- problems with current, strengths of current, goals of future, and requirements of future. I'll confess that I've spent a lot of time looking at Mozilla over the last two months. I've formed a mental model of how an incremental improvement in the environment could have a significant improvement in productivity. I haven't yet put my thoughts to writing though. :^( --Paul
Rik Hoekstra wrote:
Once in a while the subject of wysiwyg comes up on the list, as it did in the last few days. TO summarize the discussion as I understand it: The main problem is that people want a wysiwyg front end for their Zope database/web environment. On first consideration this seems to be something very desirable especially for end users. The problem of content management in web applications is present in other web application servers as well. Therefore various wysiwyg environments have their own solutions for this problem. Just some examples I happen to be acquainted with: - dreamweaver makes a difference between editable zones and ineditable zones in html;
If you want it to. Otherwise you can leave everything editable. It also supports merging XML data into templates to create pages.
<stuff on homesite and frontpage deleted>
The wysiwyg approach also seems to have the inevitable consequence that all of these editors mangle your html in an inexcusable way - so what you get may not at all be what you want.
Dreamweaver was specifically engineered to avoid this problem. The only thing it does in this regard is fix syntax and nesting errors, and even that can be turned off easily. It most certainly does not mangle your HTML. I still have nightmares about a twelve hour session with Frontpage, trying to get it to not mangle my javascript and move it out of the head and into the body of the page <shudder>.
Zope has some inherent features that make these solutions not adequate, as Michael Bernstein (I believe) pointed out. They have to do with the difference between rendered documents and source code.
Yes. An ideal environment needs to display: A) source of unrendered code (in multiple files) B) source of rendered page (usually obtained by 'view source' now) C) A wysiwyg view of the rendered page. It would be _very helpful_ if changes in B and C were back propagated to A. It would also be helpful if when I highlight a section in any view, the relevant portion was highlighted in the other views as well. Now, let me clear up some confusion about what I want _as a designer_: At no time was I advocating this type of setup or any other WYSIWYG environment as a method for adding or editing content. I was describing what I believe to be an ideal environment for designing and editing _layout code_, which is what designers are most concerned with. And many design mistakes can only be easily corrected from within an unrendered source view. For example a munged layout due to a closing </td></tr> improperly nested within a conditional statement. Content should be added and edited from within the web browser. Period.
This is further complicated by the separation of code of and layout as a result of which al templates and logic tend to be in different documents than where actual textual content is managed.
Exactly. But until XML and XSL are more widely deployed, code and layout cannot be as easily separated from each other as content can be from them both, using current tools. <idle_speculation> Hmm, perhaps the solution lies in creating some type of 'layout-only' object. </idle_speculation>
I have been contemplating this issue for some time now, because it is crucial in an academic environment in which all sorts of people with all sorts of abilities (not just designers but also 'just' students and teachers and secretaries) are going to be giving input to a website. Considering all I have come to the conclusion that a webinterface will be the way to go, at least for me.
I absolutely agree that adding and editing content should be done strictly through a web interface.
<justifications for using a web interface for content add/edits deleted>
The only issue at the moment is that the current management interface (while it is a pleasure to work with for developers) is not at all useful for non-developers.
It would be useful if it were as easy to construct add/edit interfaces outside of the mgmt. interface.
All taken together I do not thing there will be a solution in the direction of wysiwyg editors.
I disagree. Designers need visual tools to be as productive as possible, and they will have them.
Instead I would plea for the development of a toolkit for end user web-based editing environments, as I believe many of us are developing them at the moment. Is anyone interested? Ideas? Comments?
I believe that in the short term, extending Homesite and Dreamweaver to understand DTML and access Zope directly would be the most productive avenue of exploration. Dreamweaver can be extended via a published API that someone posted to the list recently, and there is an interesting article in the October WebTechniques about doing so with Java, so perhaps it's possible to extend Dreamweaver with Python as well. Homesite can also be extended, using VTML (Visual Tools Markup Language), but it has the disadvantage of belonging to Allaire, a company who's main product (ColdFusion) is competing with Zope. Interestingly, the guy who originally wrote Homesite, Nick Bradbury, is currently working on a CSS editor using Mozilla's NGLayout engine for the wysiwyg display. It will integrate and replace Homesites CSS editor when installed if you have Homesite, or work as a stand-alone editor otherwise. It's called TopStyle http://www.bradsoft.com. In the longer term, a completely new class of IDE needs to be created that allows for changes in all three views (unrendered code, rendered code, and WYSIWYG) to be reflected in the others transparently. The first example of such an IDE that I've seen is Netscape Application Builder (NAB) which is unfortunately is not only Java and EJB specific, it's Netscape Application Server specific. which is why no one other than NAS users has ever seen it. WebDAV will help bring this about eventually. But I have seen the future, and it has three views. Michael Bernstein.
participants (3)
-
Michael Bernstein -
Paul Everitt -
Rik Hoekstra