Business case for editor preference?
Friday March 2, 2007
SSF commented:
I still have not read a true business case regarding WYSIWYG vs Hand Code....And I can't think of one either.
Can you? Is there a serious business reason beyond personal preference for using a WYSIWYG editor versus a text editor for writing HTML code? Note: I'm not talking about the extra features that many advanced editors provide, like FTP and validation - just the WSYIWYG part of the code?
Actually, now that I type I can think of one business reason to use a WYSIWYG editor - content contributors. If the content contributors to a Web page don't know how to write HTML, that shouldn't block them from adding content. WYSIWYG editors like Contribute provide them with access to the content without any need to learn HTML.
What do you think?
Comments
From a business point of view WYSIWYG editors allow staff with less training and IT skills to add content to their web pages. This obviously saves money on training and allows existing staff, often the content owners, to perform this task.
However, when building and developing a site WYSIWYG editors do not always have the flexibility to create a cutting edge product that meets the needs of a modern business. This can seriously hamper the sites performance, in the long term, and might mean a loss in revenue.
It may be that both are needed but on a different scale. A few html editor based tools are needed to develop the site in the hands of experienced web developers or designers. While WYSIWYG tools can be used to add content with a lot more content owners having access and sharing in the day to day work load and maintenance of content.
A WYSIWYG Editor can be confusing if you’re not familiar with Stylesheets and HTML code. Why ? Some people may use a “Header 1″ (which is in html) and the result of what they placed on the WYSIWYG editor is different in the internet browser. There’s a lot of people that I’ve seen complaining about that. And sometimes those Editors create really ugly code. For example, as far as I have seen, some can create unexistent spaces between paragraphs (just to name an example) …and if you dont handle html you can’t take it off the right way. There are several confusing situations. My business point of view is : If you want to have a Web Content Manager, hire someone with html code knowledge, if you want a simple blog post, hire anyone witty enough to write the articles…it’s just the responsabilities that matters, whoever does the publishing should know html.
Leon: I’m curious to know which WYSIWYG editor you’re referring to. Specifically, the editor that has “the result of what they placed on the WYSIWYG editor is different in the internet browser”. After all WYSIWYG stands for what-you-see-is-what-you-get, and I would argue that an editor that acts as you describe isn’t WYSIWYG…
The ugly code question is a common theme for people who prefer text editors, but really isn’t a business case for using them. Specifically, how does a company lose money by ugly HTML (or get more by clean code)?
Maintainability! Well formed code w good documentation is easier & faster to maintain & extend.
Jennifer,
The first thought that came to my mind was peer review — does your organization do peer reviews? If so, then I can see reviews of both HTML and interpreted/browser redendered versions. The HTML review will go better with ‘clean’ coding, coding standards, and possibly code revision management — all of which might be clobbered by some WYSIWYG editors. That is, the editor and other tools must support the process.
The other thought is MS FrontPage. If you want to code standards, and then adapt your work to handle browser peculiarities, you need to pick an editor that doesn’t generate non-standard, proprietary tags.
I can see working without a WYSIWYG editor and not running into problems, if you know HTML. But even with the best WYSIWYG I would want one or more text/HTML editors (Homesite 5.2 & Arachnophilia 4.0 — love that global search and replace function — for me, right now).
The tools that best meet the organization’s needs for development and quality processes, best suited to the task at hand, and compatible with skills available — it depends!
Interesting question Jennifer.
I think certainly if your interested in standards, todays offering is very questionable. I have a licensed copy of DW8 but frankly spend most of my time in the editor (which I love!). I’m going to be looking very closly to see what kind of code the next version of Dreamweaver produces before I decide to upgrade. I’m really hoping they come a long way in this area.
Bob
As an independent webdesigner I prefer hard code to WYSIWYG although if I need a quick page I use WYSIWYG. Thorough knowledge of the mechanics of a web page make it easier to modify, update, and build from scratch. As far as saving business personel costs, it is penny-wise and pound foolish to hire cheap “web-designers”.
The key to a quality site is accessibility and functionality. Either a text editor or a WYSIWYG editor can achieve that. I design sites all day long in Dreamweaver 8 and I create sites that are tabless, valid HTML 4.01 strict, and use proper layout for optimal search performance.
The real question is if someone actually knows what their doing, to make something work properly.
Using a WYSIWYG editor because you don’t understand how to design a site effectively is not the way to go. Using a WYSIWYG editor to streamline your work load is.
In my opinion, using a WYSIWYG editor is optimal, if you know how to control it and develop a site appropriately.
And if anyone feels that valid code or accessibility isn’t important, simply ask Target how a non-accessible web site is working out for them.
My concern regarding any WYSIWYG interface (assuming the user does not know HTML) is that they become reliant on the creators of the WYSIWYG for good code, instead of knowing good code in the first place. As a rough analogy, I picture a tourist with one of those quick translator books in a foreign country - he might be able to get by, but a lot of meaning and depth of conversation is lost or not fully discussed in his book.
With that said, I support Wes Linda. The full functionality of a WYSIWYG interface is brought out when you know HTML in the first place and understand the structure of the language you are working with, and the WYSIWYG part is more of a visual reference.
Clients (site web masters or operators) always very happy while seeing editor first time, but always feels nasty at the end.
Why?
1) Editor’s Behavior is the key to like and dislike, Even more popular editor like FCKeditor show different output for simple input.
2) Editors non compatibility with word and other D HTML resources, most editor can not accommodate copy/paste from word document or any other document, or need some special option to use for this. Non technical clients use this option simple by copy/paste and feel it difficult to manage the results. Hence report dissatisfaction with editor.
Does any body know a good link to some good editor? Who should be compatible with word documents.
I can’t speak for business coders since I am only a casual coder who has designed 2 sites and maintained a third over the past few years. But I have acquired a few ideas over the past few years that I would like to interject here.
1) Have a good combination editor, like FrontPage or Dreamweaver that lets you jump back and forth between hard coding and WYSIWYG. This necessitates having some knowledge of hard coding.
2) Have as many references for hard coding as you can acquire. I have 5 for basic coding and web design plus a few more for Java and Javascript, which I haven’t gotten into yet.
3) Be able to test your code in as many OS/browser combinations as possible. I had as many as 4 browsers and 3 different operating systems to test my pages in, both on the computers and over the Internet.
I tend to use both types of editors. I use Dreamweaver for layout and css stuff but I also use Editplus or Primalscript as a sort of high performance cut/edit/paste tool; especially when hacking out code blocks for reuse in other modules. Just my preference.
I agree with Leon. WYSIWYG can make editing on a site look less complicated than it is. That’s good in some ways because it allows content editors to have more direct control of their material, but if you’re working with a CMS backend and CSS, it can be confusing. Not only does it mean that ‘What They See Is NOT What They’ll Get’, but will in some circumstances break the CSS rules and allow the site to become inconsistent.
I think the main challenge on websites with many content editors, is finding a way to make it fairly easy to input content without throwing site quality to the wind.
With the organization I work for, we have both. Since I’m the web developer, I use Dreamweaver 8, and I always look at the code, using the WYSIWYG portion of the program only for referencing certain non-dynamic text.
Because we currently have 538 locations, rather than having them each rely on me to make content changes to their own sub-pages of the website, we have them each using InnovaStudio, a WYSIWYG editor, to change their website content. Something influencing the use of that particular WYSIWYG editor was the extra step of having a flash video tutorial (divided into 20 short lessons in this case) of how to use the editor, so I wouldn’t be investing my normal programming time in tutoring the InnovaStudio users on how to use the editor.
With that said, I would recommend having a WYSIWYG editor for departments that only need to do basic HTML… and make sure that there is a visual training method (screen shots OR video) to make it easy for them to learn. On the other side of the coin, it is still important for an organization to have someone proficient in website development, and having a website editor that is code-viewing-friendly (such as Dreamweaver or EditPlus).
For me, the benefit is the ability to toggle between code and WYSISYG, albeit, most WYSIWYG editors only do a fair job at displaying what you would see in a browser. So it’s really WYSI*almost*WYG, but it’s good enough to visually capture “obvious” errors.
Editors like Dreamweaver and FrontPage can display html and WYSIWYG in a split screen mode. This is a very handy feature — I wish my Visual Studio editor could split the screen, but for now, it’s only code and design mode.
But I think the real problem is that we tend to compare our beloved html editors with other types of document editors such as word processors and spreadsheet programs. Let’s take MS Word for example. We open a word document and start typing away. We format the document until we turn blue in the face and we are happy. We never see the underlying code, nor do we care to; it simply looks pretty so no need to go any further. If you want to distribute the Word document, you would expect the recipient to open the file using the MS Word software. No problem; it still looks pretty and we still get away without exposing the code. In all fairness, you can break a Word document by viewing it in a cheap viewer but let’s stick to the assumption that Word docs were intended to be used in the Word software. (By the way, Word is intended for a print medium as opposed to html being multi media, but that’s a whole ‘nother can of worms.)
Web pages, on the other hand, are viewed by a multitude of devices. Most common are web browsers, but there are devices such as text readers, brail, WAP and so on. Just within the web browsers, we have different flavors such as IE, FF, and Opera etc. It’s really a shock for folks who don’t do cross browser development when they discover that their web page breaks when viewed in different browsers. The situation is becoming better with browser vendors coming closer to attaining standards compliance, but the gap still exists. So until then, we need to touch the html code directly.
I’ve proammed help files for a visual basic system in HTML and basic information web sites. No way could I do the same amount of content using HTML. Time saved over weeks of 8 hour days is substantial. Resulting in much more content. The only time I’ve not used a WYSIWYG editor was when I used MS Word, then I had to clean up the code manually. Production was very slow then.
you should ALWAYS learn how to code by hand first, then pick up an editor and use it for it’s time-saving benefits.
Most companies require hand-coding in their job descriptions, though I have found that once you begin working, a WYSIWYG needs to be used in order to meet deadlines.
It’s when you are doing cutting edge coding or fixing a complex CSS structure that the ability to understand how things work comes into play.
Mike:
You wrote:
I wrote an article on that very topic, because I got tired of fielding comments from beginning designers along the lines of “Why does my page look great in Dreamweaver and then not look right in the Web browser?”
Jeff: I don’t know that I’d consider MS Word an HTML editor - WYSIWYG or otherwise. It’s very frustrating that it saves as HTML because man, the code it saves isn’t worth the pixels it’s printed on! I’ve found it faster to save a Word file as text and build it as HTML from scratch than use Word to write it.
Almost anyone can make a web page with WYSIWYG so training is minimal. More attention can be made to design and detail and format. I believe WYSIWYG is the coming Web Designers way to go. Also other author contributions can be entered easily and changed to suit easily. I use Homestead anad they give me everything I want.
@ Jennifer,
“Why does my page look great in Dreamweaver and then not look right in the Web browser?””
For people who say dont really know either to use HTML or the Dreamweaver or both.
For me, like everyone I started handcoding, learning the basics and then move d to Dreamweaver.
I agree with Leon cause if we know the code properly.. we can profit from the various fonctions DW or anyother software offers and ignore the rest.
Its too bad cause due to these novice “designers”, functions such as Code collapse in DW8, Replace, Linking the site at one go…are ignored.
And yes i am using CSS for websites which i handcode in Code view and see it browser indtead of display pane in DW
@ Jennifer,
“Why does my page look great in Dreamweaver and then not look right in the Web browser?””
For people who say that dont really know either to use HTML or the Dreamweaver or both.
For me, like everyone I started handcoding, learning the basics and then move d to Dreamweaver.
I agree with Leon cause if we know the code properly.. we can profit from the various fonctions DW or anyother software offers and ignore the rest.
Its too bad cause due to these novice “designers”, functions such as Code collapse in DW8, Replace, Linking the site at one go…are ignored.
And yes i am using CSS for websites which i handcode in Code view and see it browser indtead of display pane in DW
Jennifer:
Thanks for point me to the article you wrote relating to my WYSI*almost*WYG comments. That is exactly what I’m getting at. For me, these editors are nothing but a tool. I always test my code by double checking them against the targeted media – usually web browsers. (I recently bit the bullet and dropped testing for Netscape 4.x)
In short, if my code fails in the WYSIWYG editor then it will, without a doubt, fail in real world applications. Conversely, just because my code looks great in WYSIWYG mode, it’s not guaranteed to work outside of the WYSIWYG editor. Thus the requirement of QA testing.
Perhaps one of these days, we won’t have to worry about hand coding. Our current process is very inefficient; our content owners are almost required to have a PhD in html coding. That’s a huge and unfair obstacle when all they want to do is communicate their writings through the web. My content owners should be able to do their jobs using their writing skills, not their IT skills. Html code should be transparent, but until then, I guess I have job security.
Hey. WYSIWYG is faster! Especially when writing XHTML. As webmaster for a k-12 school, I sometime add updates two, three, or four times a day and with only a very few minutes to get it done and posted on the server. I’d never be able to do that by strictly hand coding.
I do, however frequently have to come back and clean up the “digital do-do” that MX 2004 leaves behind.
For new pages and new sites, I find a combination of code view and WYSIWYG works best for me.
It’s like riding a very fast motorcycle, you don’t have to go full throttyle all the time.
WYSIWIG editors are like that. Switch off the design mode and hand code away.
Clean up odd Editors based code intermittently.
Voila.
Good hand code loads faster than most WYSIWYG generated HTML. I haven’t seen that issue mentioned. Even in these days when all the designers have fast internet connections, many end-users are still limited to dial-up connections. Getting your content down the pipes to the end-user quickly is still important.
Don: What WYSIWYG editors have you used lately? The best modern WYSIWYG editors don’t add any more code bloat than hand-coded pages. For example, the code in this example was written in Dreamweaver 8 design view (WYSIWYG). Yes, it has things like the label, accesskey, and tabindex - but those elements and attributes were added at my request, and I would have added them if I’d hand coded the page as well.
I also realize that this screen shot doesn’t show the head of the document, but Dreamweaver doesn’t add any extra meta tags to the head unless I ask for them.
You are 100% right that getting your content to your readers as quickly as possible is vital to a good Web site. But these days, using a good WYSIWYG editor doesn’t preclude that.
I have always preferred using text editors for HTML coding, in fact, my first two “paid” jobs as a freelancer (which I still am) were done completely using MS Notepad and some graphics editing programs (for the images obv.). But, after purchasing Dreamweaver I have become very comfortable using it over the last year, but still need to edit the raw code from time-to-time if something isn’t fitting quite right.
We don’t use much autogenerated coding on our designs. Most of our codes written by our prgrammers on custom basis. Even in this era of high speed connections, most of US populations do not have high speed connections. So our practice is to look at client’s business to see what their target domains is, before we hand code or auto-generate code.
emathew@confluencecorporation.com
www.wspgusa.com
Jennifer said:
>Once a Web team grows beyond two to three people, it’s good to standardize on one piece of software for developing Web pages. This insures that your entire team is working in the same fashion and you’ll have less compatibility issues later with uploading and file sharing.
Jennifer, I find this statement mystifying since AFAIK none of the main WYSIWYG and text editors add any proprietary code, so I cannot see sharing files as a problem. As far as uploading is concerned there is no difference using an FTP program or the built in capabilities of one of the WYSIWYG programs (other than perhaps using the lock out system in DW for large teams).
Team processes should be built around standards for code, validation, and testing, rather than the program used.
>extra features that many advanced editors provide, like FTP and validation.
Many simple code editors provide these features as well as the WYSIWYG programs eg. HTMLKit
Sinebeg:
You’re right that none of the major editors add proprietary code, but here’s an example of how it might help having teams standardized:
* documentation - We wrote up documentation on how to edit our Web pages using DW, and used screen shots and examples from the software. When new designers/developers arrived they are pointed at that documentation and can just follow along to learn how to use our system. If they use a different editor, they have to figure it out on their own.
* training - similar to the documentation issue, when I brought in a new designer who didn’t have a lot of experience, it was easy to have her sit next to a co-worker and follow along. The co-worker knew DW, and that’s what we had installed on the newbie’s machine.
* special features - yes, many editors have FTP but they all do it differently. And if you’re in a corporate environment with firewalls and staging servers, etc. Having everyone on the same system makes it much easier to troubleshoot. For example, there was a point where I had 2 people on DW MX and 2 on DW MX 2004. But DW MX didn’t handle our connections - and they couldn’t FTP with it. It took us several months to figure out what the problem was. Mostly because when asked what editor they were using, they’d say DW - and we didn’t realize that the versions didn’t handle file transfer the same way.
Yes, processes can be built around standards for code, and we did do that too (mostly because I was one of those annoying managers who refused to stop using Vi and Homesite, even after we standardized…). But it was much easier to just go to everyone’s DW options and say “change the tab length to 2 spaces” and know that everyone would be writing code the same way - because they were all using the same software.
I am saying these things based on my experience as a Web manager for many years. All of what you say is true, but it’s much easier to manage the situation if all the extraneous variables are removed.
Finally, this was not an article specifically advocating WYSIWYG. I was trying to do two things:
1. point out that a lot of the reasons that people cite for refusing to use WYSIWYG editors are no longer true.
and
2. show how you might evaluate the software tools your company uses in a critical fashion, rather than just saying “I like X” or “Y is the cheapest”.
Hi
I think each has its place in a business context. There are, after all, CMS systems like Joomla! that are built upon their ability to provide users that have no need of HTML knowledge to provide and update content for their works’ website. Yet, the web developer is most likely to work with both hard code and WYSIWYG.
Good debate