|
What do you think? Share your opinions about the ongoing debate on WYSIWYG vs. "old-fashioned" Web development tools. Share your opinions about anything you've read in this issue, or anything you'd like to tell the world about your Web/internet experiences as a user, developer, evaluator or trainer. Pieces ranging from haiku to 500 words are welcome. Submit opinion pieces to Tony Masalonis at masalonis@cua.edu or anthony.j.masalonis@bellatlantic.com |
Responding to Cases for and against WYSIWYG editors, by Pawan Vora and Michael Miller, Internetworking 1.1.
Due to the volume of submissions, some pieces have been edited.
"I certainly have not looked at all the WYSIWYG tools that are available, but the ones that I have looked do not typically produce pages that are accessible to people using adaptive and accommodative computer technology like screen readers. If you have to go in and alter the code produced by the WYSIWYG tools to make the sites accessible, you have to learn both HTML AND the tool (and know the tool very well to know where and how to change the code). For any application that may be used in a work setting or accessed by the public for a service, making the web site accessible may be legally required. But, in any event, its simply good business."
... Lila Laux, Ph.D.
"I wrote a small essay on the subject to help my superiors choose how to train the professors at the college (where) I work, to make web pages. [Quotes from the essay follow - Ed.]"Staff and faculty want to make web pages. Let's decide on what software package (our institution) should teach and the Help Desk will support. There's three kinds of software that make web pages: pure code-based where you work with tags; pure WYSIWYG where you never see the code; compound editors where you can switch from code to WYSIWYG and edit either. So, which kind should we use? Let's talk pedagogy first, shall we? Profs don't wanna learn code. Period.
"In the college I think (WYSIWYG) has technical advantages because even if professors did write code, what's to say they won't accidentally make some bad code; they aren't perfect. And if they do hit a problem in their code that would take them an hour to solve with their nose in an HTML book, what will this do to their desire to use the web in their teaching?
"And what's the problem with some superfluous code? A single video clip would be WAY bigger than the few bytes devoted to setting the font for each cell in a typical 30 cell table!
"Have I convinced you that a compound WYSIWYG editor is the way to go yet? Professors are busy and want to focus on their discipline. Not code."
...Andrew Reil
(an essay version of this letter can be found at http://www2.mtroyal.ab.ca/~areil/wysiwyg.htm)
"We have been engaged in a debate at the educational facility where I work concerning web authoring environments. The I.S. department (is) arguing that (WYSIWYG editors) produce gross, bloated HTML... The people involved with educating users and supporting academics to create web-based materials are arguing strongly for at least a WYSIWYG editor and at most a full blown courseware-development environment (cut and paste text in application, the program does the rest)... I plan to offer a few stage plan. First off we will adopt the 'best' WYSIWYG editor we can agree on, one that produces the least amount of extraneous code, does the minimum amount of automated 'corrections' and yet is still easy to use (we'll let you know if/when we find one ;-). Along with this, I will use some of the validation tools I have and build some other custom ones to check the site and try to keep it from going too badly askew. This step will probably get us a year's time, during which I hope some less contentious WYSIWYG page development environments emerge."
Yours in elegant WYSIWYG anticipation,
...Scott Leslie
"I just read the article at http://www.sandia.gov/itg/newsletter/june98/opinions.html. I was really offended. I've been programming for 24 years and doing full time web development for over 2 years. I do database integration with web pages. You HAVE to program this stuff. It just doesn't magically appear and work with a little HTML. And yes, I DO actual programming, not just HTML. My skills are becoming MORE valuable, not less....I agree that artists and programmers have different abilities and should be responsible for different parts of the entire web site. However, the assertion that I can 'kludge together a web page' is ridiculous."WYSIWYG editors /aren't/. That's because HTML is not a "layout" language -- it's a document markup language."I suggest you screen your article submission more thoroughly for offensive tone of voice."
...Tom Nunamaker
Note from the editor:
[Tom, thanks for your detailed response. The original piece was meant to be a bit "tongue in cheek", especially the more incendiary language involving Yoo-Hoo-drinking fanatics. The authors of the opposing positions purposely adopted extreme stances in order to generate reactions; the intent was not to denigrate the expertise of programmers, or graphic artists, or any other professionals. On behalf of the Internetworking staff, I apologize if you really took offense. - Ed.]
"WYSIWYG editors /aren't/. That's because even with clean code, different browsers render pages differently. And there are more than two browser companies.
"WYSIWYG editors /aren't/. That's because Windows, Macs and UNIX machines all render type sizes differently. This is a platform independent medium - remember? Want font control and placement precision? Either print the document or PDF it.
"WYSIWYG editors /aren't/. That's because they often try to literally replicate the 'appearance' of a Word document, for example (think Office 97), and not only does the finished product /not/ look like its original, it's not even optimally rendered for online reading. Personal trial and error speaking here.
"WYSIWYG editors /aren't/. That's because some don't understand the difference in physical and logical tags -- which are device and browser dependent. My team member experimented with a WYSIWYG editor -- Visual Page 1.0 for Windows. Here are a few of its sins:
- It double-spaced some text elements -- debugging nightmare number one.
- It decided to make other text elements into "run-on sentences" ... that is, it removed line breaks and created one l-o-n-g line of text/code. Another debugging nightmare.
- It inserted <P>'s willy-nilly -- even AFTER a <NOBR> tag that preceded two images. (How's that for invoking schizophrenia in a browser?)
- It changed all relative font sizes to absolute font sizes. Not only is this a usability design no-no -- the fact that it changed code at all means that it should be deep-sixed in the nearest body of water.
"Just as every writer is not a 'graphic designer' (that is, the writer gives the text to someone else to add graphics, color, font tricks et al for the finished product), every person who wants content on the web is not a 'web designer.' The issue of usability, understanding the limits of the medium, and an appreciation for conformance with such requirements as the Americans with Disabilities Act suggest that large sites be 'designed' by those subject matter experts -- preferably a team of experts. With the sophistication of today's database-to-web applications, the person who merely wants their content 'up on the web' could then go to a 'web front end' database entry form ... input their content into a database ... and have their information 'magically' appear on the web site. In a template. With decent code. And all without their having to worry their handsome (or pretty) heads with 'that awful HTML stuff.' Just as Pagemaker made it easier for designers to design, it also made it easier for neophytes to make truly unreadable brochures. The tool doesn't the expert make. Even when it's a good tool."
...Kathy E. Gill
"I am a web page developer and use both Dreamweaver and Homesite. I use Homesite to create web pages from scratch. And then I use Dreamweaver if I have to do fast editing like correcting copy, changing the fonts of a whole document or changing code of links. It is just so much easier to correct things in Dreamweaver because you are spared at looking the HTML. But I still prefer the semi-WYSIWYG environment of Homesite when I create HTML pages because it just gives me complete control of the code. There is not one product out in the market that gives me the type of control I get when I use both Dreamweaver and Homesite. So I guess you can say that I'm straddling the line between 'being against' and 'being for' WYSIWYG editors.""'WYSIWYG is good for some things, but I have a problem with the ultimate reliance upon them. Just like Windows C++ code generation utility 'wizards' , I feel that soon HTML will be a lost art. When people get too dependent upon tools that do everything for them, they lose the sense of what they are truly doing. Example: A UNIX systems programmer as opposed to a Windows VC++ programmer. The UNIX programmer is much more intimate with the code, understands what he/she is doing, has a RELATIONSHIP to the code, and maintains it. If they ever leave the project they have also carefully documented each area and what changes were made and why. The MS Windows programmer has all sorts of tools to generate code for them; 'Wizards', they are called. He cannot document the code because there is no relationship between him/her and their code, except in what ties pieces together. They have forgotten the relationship they had with this code....Andre Quintos
"The same holds true for HTML, and I profess to be no HTML Genius, and have used WYSIWYG editors. I still have to go in and change the formatting generated by those editors from time to time. And I usually do this using the 'lame-ass, text-only UNIX editing tool', vi. It doesn't take a genius to learn vi, and it is a very, very powerful tool. Anyone who would criticize its use has not taken 15 minutes to learn 5 simple commands that make vi easy to use. All in all, I speak for both sides, my point is that we need not to lose the internals. The COBOL programmers did years ago, and now we face a shortage in the coming 'Y2K' problem. Lets be careful that websites and the CGI's behind them do not become the same way."
...Pat Lynch
© Internet Technical Group
Last update: September 8, 1998
URL: http://www.sandia.gov/itg/newsletter/sep98/voices.html
hosted by Sandia National Labs
Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.