There are different ways to approach authoring Web pages for your project. How you decide to do it should depend upon the types of interactivity you plan to use, your team members’ levels of expertise, and their preference for working either directly with the source code or using a visual method.
HTML can be written without using a Web editor. With the most basic text edi- tor, Notepad (Windows) or TextEdit (Mac), you simply write the HTML markup code manually. This is probably not the most practical approach for the novice, however, because it is quite time consuming, is prone to error, and requires in-depth knowledge of HTML coding and other scripting languages. At the other end of the spectrum are simple visual editors that require no knowledge of HTML and operate like a word pro- cessing application. An example of this is Netscape’s Composer, which is part of the Netscape suite of components. It works well for authoring very basic pages but does not include the functionality that will support the integration of higher-level features, which are discussed in later chapters. Word processors such as Microsoft Word also have built-in functionality to save documents as Web pages, but here again, you will sacrifice the capability to control the editing to the level that is optimal in authoring Web pages.
It is best to select an application that has been developed specifically for author- ing Web pages. Today these applications have matured to the point where they provide all the features necessary to build complex and advanced Web pages. Prices range from zero to several hundred dollars—but don’t assume that the most expensive is the best.
The two main types are code-based and visually based (WYSIWYG, for what you see is what you get, pronounced “wizzywig”). Both perform the same functions, but are very different in how the author works to build a page.
With a code-based editor, the code is in plain view (see, for example, figure 4.6).
You can see exactly which tags and attributes you are using. Unlike a plain-text editor, however, a code-based editor can automate the creation of tags and often also can automate generating the higher-level features that will bring interactivity to the page.
Code is generally color-coded so that it is easy to distinguish from the page text.
Traditionally, this type of editor has been considered to be the choice for power users who don’t want to give up control of the code. Two examples of this type of editor are Macromedia HomeSite (for PC, http://www.macromedia.com/software/homesite/) and Bare Bones Software’s BBEdit (Mac, http://www.barebones.com/products/
bbedit/index.shtml).
The visual-based editor has typically been considered more user friendly for most Web authors. When using a visual or WYSIWYG interface, the author is shielded from the HTML coding and sees only how the page will display to a user. This method allows the author to concentrate on how the content should appear, but sacrifices con- trol of the author’s ability to fine-tune the source code. Another obstacle to be aware of is that WYSIWYG code is often bloated, meaning that unnecessary code is gener- ated. This generally will not make any difference in how your page displays, but may become an issue if you need to troubleshoot or want to reformat the page. Two exam- ples of a WYSIWYG editor are Macromedia Dreamweaver (for PC and Mac, http://
macromedia.com/software/dreamweaver/) and Adobe GoLive (for PC and Mac, http://
www.adobe.com/products/golive/main.html). In April 2005, Adobe announced an agreement to acquire Macromedia, so it will be interesting to see which direction is taken with their competing software applications.
FIGURE 4.6
Web Page Viewed in Code-Based Editor NoteTab Pro
From Fookes Software, Charmey, Switzerland. Available: http://www.notetab.com/html.php.
Most of each type of editor provide a bridge between the two methods. For instance, a good WYSIWYG editor will have a source inspector in which the author can view and edit the code directly. Similarly, a well-designed code-based editor will have an interface so the author can view the page layout in a browser (see, for exam- ple, figure 4.7).
No matter which style of editor you decide on, you will want to look for certain features that will help you achieve advanced designs and interactivity. Look for an edi- tor that includes support for the features listed below and that can help with advanced features, which are discussed in later chapters:
site management
checking the integrity of source codes cross-browser compatibility check spell check
link check
global find-and-replace
support for scripting languages such as JavaScript, Perl, and PHP support for standards including XHTML, XML, and XSL CSS (cascading style sheet) support
FIGURE 4.7
Web Page Viewed in Dreamweaver WYSIWYG Editor with Code Editor View
From Macromedia, Inc. Available: http://macromedia.com/software/dreamweaver.
support for team collaboration multiple document display design templates