 |
|||||||||
|
|
|
5 - Intranet Document Management by Joan Bannan TalkBack
Chapter 5: Authoring
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| URL | What You Will Find There |
| http://www.ncsa.uiuc.edu/General/ | A Beginner's Guide to HTML |
| Internet /WWW/HTMLPrimer.html | |
| http://www.pcweek.com/eamonn/ | Crash course on writing documents |
| crash course.html | for the Web |
| http://werbach.com/barebones/ | The Barebones Guide to HTML |
Another resource is existing Web-head authors like me. All the resources in this book and new resources destined for reprints will be kept up-to-date on my Addison-Wesley Web page linked to my home page at http://www.bannan.com or you can e-mail me and ask me questions at joan@bannan.com. One of the many newsgroups where authors find each other and help each other with this ever evolving technology is the HTML Writers Guild. Their home page (at http://www.hwg.org/) states, "The HTML Writers Guild is the premiere international organization of World Wide Web page authors and Internet Publishing professionals. Guild members have access to resources including: HTML and Web business mailing lists, information repositories, as well as interaction with their peers."
There are also numerous books that cover HTML authoring in depth such as
* Teach Yourself Web Publishing with HTML 3.0 in a Week, by Laura Lemay (SAMS)
* The HTML Source Book, by Ian Graham (Wiley)
* Webmaster in a Nutshell, by Stephen Spainhour (O'Reilly Nutshell Handbook)
Creating Hyperlinks
The most common hyperlink uses HTTP, but several other protocols or tags can also be coded into your HTML:
* HTTP
* FTP
* MAILTO
* GOPHER
* NEWS
* TELNET
The three tags you will use most often when authoring for an Internal Web are HTTP, MAILTO, and FTP.
HTTP is the one you will use most as you author Web documents. It's the reason the Web is a web. You can use relative URLs (discussed later in this chapter) to establish links between documents within your server or full URLs to establish links to any Web server in the world.
MAILTO is sooo handy. If you've surfed the Web at all, you've seen one. This protocol lets your users send e-mail directly from the Web page to a feedback e-mail address, to the author of the page, or to anyone on e-mail. For instance, on my home page at http://www.bannan.com I have my e-mail address hyperlinked with the MAILTO protocol. The HTML looks like this:
<A HREF="MAILTO:joan@bannan.com">JoanBannan</A>
FTP is another of my favorites because it can fetch documents stored on computers that do not have Web servers installed on them and therefore do not support HTTP. When users click on this kind of hyperlink, they are prompted to download the file using FTP. An example of a good use for an FTP hyperlink is making available the printed copy of a huge electronic document delivery whitepaper that you have chunked into small HTML pages for Web consumption. You want to offer the whitepaper in its original, printable form on the first page of the Web version. You have a server and a "public" drive behind your firewall where you keep these sorts of papers so you'd rather store it there where everyone expects to find it, rather than place it on your Web server. Your FTP hyperlink might look like this:
<A HREF="FTP://coserv/public/doc-mgt/edd/eddwhite.zip">EDD White Paper (zipped version)</a>\
Definition
Chunking means breaking a document into smaller pieces. This is a bandwidth-friendly, not to mention a user-friendly, way to present information. Usually you can just link each section to the next and create a hyperlinked Table of Contents to retain the document's unity. (See Chapter 10 for information about chunking huge documents.)
For more about offering differently formatted versions of documents at your Web site, see Chapter 7.
There are four factors to consider when creating hyperlinks:
* relative URLs
* relevance
* reasons
* recommendations
Definition
A hyperlink is a text or graphic that jumps to a new location when you click on it. On the Web the click may jump you to a document or resource on a server somewhere else in the world. In an online help application, the click only jumps you to somewhere else in the document or opens a little window displaying, say, a definition. On the Web, a common practice is to use an image in place of the text for the hyperlink.
Using Relative URLs
Relative URLs are particularly useful if you are creating a multipage document with dependent links. For instance, you may have a large whitepaper that you would like to publish on your Internal Web, but you don't want your Web users to have to wait for 25 pages to download all at once. You therefore create an HTML version of the document that breaks at each point where a Heading 1 style starts a new topic. This is known as chunking. You then add navigational aids that link to each "next page" of the document, to each "previous page," to the hypertext table of contents, possibly to a hypertext index, and to the home page or title page of the document. As you are coding this document with HTML, you assume that all the pages of the document will be loaded into the same subdirectory on the Web server. Relative URLs make it easy to test the navigation of the document while you are still holding it on your local drive, and they still work when you move the whole set to another directory on the server.
Definition
A URL (Uniform Resource Locator) is the string of characters at the top of your browser that starts with http:// and often includes www. If you put an address there and then press Enter, it "tells" the browser which Web page to open.
Definition
A relative URL is a Web address that "tells" the computers
to "start where you are and use http:// to find the address you are
looking for as opposed to an "absolute" or "full" URL,
which gives the full protocol and path of the item you want to hyperlink.
For instance, if you want to point to an HTML document named d-duck.htm
from within a document named m-mouse.htm and they are both located within
the Disney subdirectory of your Web server, you only need to put <A HREF="d-duck.htm">Donald's
Home Page</A>. You do not need to put the full address, which might
be <A HREF="http://Amusement/Disney/
d-duck.htm">Donald's Home Page</A>.Or if you want to use a
relative address to point to an image file on the same server but in a different
subdirectory, you need to "tell" the computers, using slashes
and dots in front of the filename, to start here, and go back or forward
through the directories. Using the previous example, to go back to the Amusement
directory (back one directory) then into another called images (at the same
level as the Disney directory), the relative URL might be <IMG SRC="../images/mickey.gif"
ALT="Mickey Mouse">.
The easiest way to explain a relative URL is by example. For instance, you may have a contact list containing everyone's home/work phone numbers, e-mail address, home address, birthday, and emergency contact. You, of course, would have this residing in the Personnel Department of the Human Resources Department. (I know it's the Department of Redundancy Department, but this is only an example.) Your company Web server has a subdirectory named Personnel under another subdirectory called Human-Resources within the Orgs (for Organizations) subdirectory off the company home page.
The full URL within the hyperlinked reference HTML tag might look something like this:
<A HREF="http://home.mycompany.com/Orgs/ Human-Resources/Personnel/contact.htm"> Contact Information</A>
If you place other documents in the Personnel subdirectory you can use a relative URL to point to this list, and it would look like this:
<A HREF="contact.htm">Contact Information</A>
The advantage of using relative URLs is the mobility of a set of related documents. For example, you might author twelve related Human Resources documents in a local directory of your office computer and then move all of them to the server. You might not even know the server subdirectory on which they will reside. It doesn't matter. You can complete your documents, link them to each other, and test without knowing what the full (absolute) URLs will eventually be. In this case, if you used full URLs you would have to know the full path on the server where you would be placing the documents, and if you move them, you would have to edit each document within the set. Note that you can also include full URLs to other locations within these documents that point to places elsewhere on the Web. You do not need to exclusively use relative URLs. For more about uploading files, testing links, and finding "broken links" see Chapter 7.
You can also anchor a spot in an HTML file using a relative address and jump to that spot from within the same document or from another document. This makes it easy to set up a hyperlinked table of contents at the beginning of a larger document. For instance, in contact.htm you could put an anchor using the HTML name tag within the contact information document at someone's name like this:
<A NAME="bannan">Joan Bannan</A>
A relative link to this anchor from within the same document would look like this:
<A HREF="#bannan">Joan Bannan</A>
A relative link from another document within the same subdirectory would look like this:
<A HREF="contact.htm#bannan">Joan Bannan</A>
A full URL reference to this anchor would look something like this:
<A HREF="http://home.mycompany.com/Orgs/ Human-Resources/Personnel/contact.htm#bannan">
You could also use a relative URL to another subdirectory within the Human Resources subdirectory, which could look something like this:
<A HREF="../Benefits-Forms/">Health and Dental Forms</A>
The HTML coding in the previous example tells the browser to go back one subdirectory from where this HTML document is loaded, then forward into the Benefits-Forms subdirectory. Since there is no file listed after the slash (/) this URL will bring up an index of the files in this subdirectory or a page that has been associated with the index to replace it. Table 5.2 is a cheat sheet for coding relative links and anchors. For more about linking a page to the index of a subdirectory, see Symbolic Links in Chapter 7.
Table 5.2 Relative Link and Anchor Cheat Sheet
| Link | Tells the Web Server to Use HTTP and... | |
| /DirectoryName-or-FileName | Start at the root | |
| DirectoryName-or-FileName | Stay in the directory you are in (or document--see #AnchorName below) | |
| ../DirectoryName-or-FileName | Go up one directory toward the root then into a directory at the same level you are in | |
| ThisDirectory/NextDirectory | Start in this directory and go into a | |
| WithinThisOne | deeper directory | |
| #AnchorName | Stay in this document and find the spot I marked with an anchor tag | |
| "." | Stay in this directory and go to the home page or default index page | |
Hyperlinking
Hyperlinking is what makes the Web so cool. However, it's a great responsibility to author in such a way that the links you create enhance your documents rather than disrupt your reader's train of thought. For instance, you may be posting on your Internal Web for the Human Resources Department a document that contains information about retirement benefits. This document mentions how the IRS taxes deferred accounts. You could link the word IRS to the IRS home page at http://www.irs.ustreas.gov/prod/. But what's the point? Sending users to that location just because it exists may be a proverbial rabbit trail. On the other hand, if a recent change in a tax law affects the way your company does business, a specific IRS page may be totally appropriate and helpful.
Definition
Hypertext is text that is coded to jump to another location when you click on it. It's usually indicated with underlining and a different colored font.
There are several good reasons to use hyperlinks:
* to conserve bandwidth
* to take advantage of existing Web information
* to update chunks, thus keeping content current
* to help users find the right information
Bandwidth should always be a consideration to Web authors. You have the power in a popular document to slow all servers within your Internal Web to a frustrating near-halt. If a document can be downloaded in chunks, it's faster for the user and more prudent for the network. Chunking is breaking a document into connected smaller pages with hyperlinks to other sections of the document. For example, I often create a hypertext table of contents on a separate Web page that links each heading listed in the table of contents to the actual heading of a multipage document.
Another way to save bandwidth is to embed hyperlinks to images, making them available at the user's request, rather than downloading them with the document. This greatly reduces the main document load time. If visitors do not need the images to fully understand the prose, they may not need to access the image at all.
Take advantage of existing information. Why reinvent or rewrite what already exists when you can jump to it? For example, Pacific Bell's Internal Web publishes Help documents with instructions on how to configure the Pacific Bell standard browser to launch a document's native application (such as launching Word when you click on a Word file). Each time someone puts in a link to a document that is intended to launch the user's copy of the native application, there is always the chance that the user who wants to do so has not yet configured his browser to do so. With the Help information pages, already in place, the Pacific Bell author need not write instructions for the user. Instead, the author creates a link to "How to Configure Your Browser for Helper Applications."
Chunked updates. Another efficient use of hyperlinking is to single out pages that need to be updated regularly and separate them from parts of the same document that remain more or less static. For example, on the home pages for technical teams you may be tempted to list the team members, their phone numbers, and e-mail addresses. Instead, consider hyperlinking the word team to a spot on another Web page that contains a list of several technical teams. That way when you update the team list, the information on each technical team home page is up-to-date sans maintenance. The same is true for resource information "out there" that other people keep up-to-date. For example, on Silicon Graphics's Internal Web site the stock price is automatically updated by fetching the information from Yahoo every 15 minutes--the responsibility of updating the resource lies with Yahoo.
Recommendations for Hyperlink Authoring
Click Here. I once read criticism of Web authors who use "Click Here" instead of incorporating the link into the prose. I took the criticism to heart, criticized another person's work (at her request) passing along what I had read. Then I found that sometimes "Click Here" was clear, concise, to the point, and preferable. As mentioned earlier, one reason you might want to add a hyperlink is to have an image be optional or on "click-demand." Putting diagrams, screen captures, and other images in a separate file makes you a good Netizen. "Click here for a picture of the database input dialog box" might be preferable to just linking the words database input dialog box in the middle of a sentence.
Copying Source HTML
When you see a page that has the formatting you've been dying to "create," it's really easy to borrow it. For example, from a Windows machine go to the URL where the document is and then do the following:
- 1. Open your HTML editor to a new page (or Notepad or word processor
if you wish).
- 2. Choose View, Source from the browser menu.
- 3. Select the area you want to copy with the mouse.
- 4. Press Ctrl+C to copy.
- 5. Hold down the Alt key and press the Tab key until you're back in your editing application.
- 6. Press Ctrl+V to paste the selection into your file.
- 7. Replace their data with yours.
- 2. Choose View, Source from the browser menu.
Another option is to copy the whole page. To do that you simply choose File, Save As Source, and download it to one of your computer drives. With these instructions, let me warn that just because something is on the Web it is not necessarily free. Copyrights are enforced, and permission to copy is easy to obtain.
Testing Your HTML Code
After you have created a Web page, you will want to test it by looking at it in your browser.
Some HTML editors, like the one I use, have a test button that automatically opens a copy of your default browser and displays your document. I only use the test button once with each document. I see the page displayed, go back to my file and make the changes, save them. I then switch to the editor and click on the Reload or Refresh button. Also, working in this environment I find that the editor puts a less logical string in the Location or Address textbox than my browser can recognize for relative links. For example, it may put file/local host rather than just file:c:\filename.htm. When I click on relative links, my computer doesn't recognize that "local host" stuff. Therefore, if I really want to test my files, including all my links, I open the browser and choose File, Open or File, Open File (depending on my browser du jour) and keep all my test files with relative URLs in the same subdirectories that I will duplicate on the server. If your editor does not have the test feature, or if you are using Notepad or word processing software, you will need to display the file in your browser this way in the first place.
For some people, an HTML editor, conversion utilities, and WYSIWYG editors are way overkill. If you are one of those people who needs to create only a simple HTML page on rare occasions, you may choose to read a little about HTML, consider the freeware conversion utilities later in this chapter that convert documents and Excel spreadsheets, and then create/edit your pages in Notepad or your word processor. You will still need to test your code. If you are on a 16-bit system, you may run into a little trouble using your word processing software, but not if you follow these instructions:
- * Save your file.
- * Close the file out of your word processor.
- * Choose File, Open or File, Open File from your browser menu.
- * Close the file out of your word processor.
* If you need to make changes to the file, you will need to open it again in your word processor, but you can leave it open in your browser. Make the changes, close the file in the word processor each time you want to test it, and then switch to your browser and press the Reload or Refresh button.
For these test scenarios, you may want to tile two windows, one with your editor open, the other with the browser open, and switch between them.
If you are using Notepad or have a 32-bit system or a Mac, you should not need to close the file to open it in your browser. When you want to see the changes you are making, switch to the editor you are using, make the changes, switch back to the browser, and then choose Reload or Refresh from the browser menu.
Tips for Using Images
Copying Images
Downloading images from the Web is easy. Background images can be a little tricky or not accessible, but here's how to copy most images sitting in full view:
- 1. Click on the image with the right mouse button (MacPeople hold down
the only button).
- 2. Choose Save This Image As . . . or Save Picture As . . .
Background images are a little harder to capture, and sometimes the directory in which they are stored is not accessible. For example, you might want the beautiful gradient background of Addison Wesley Longman's parent company, Pearson, located at http://www.pearson-plc.com shown in Figure 5.1.
Figure 5.1 Pearson's home page, which is much prettier in color
You need to get the image "alone" as the only file open in your browser screen, then choose File, Save As from your browser menu. To do this, you need to read the HTML code on the page where you found it:
- 1. Open the page in your browser that contains the image you want.
- 2. Choose View, Source from the menu.
- 3. Look near the top of the page for the <BODY BACKGROUND=...> tag, for example,
- 2. Choose View, Source from the menu.
<BODY BACKGROUND="/pics/bground.gif">
Often these images are stored in relative addresses as in this example. Therefore, it may take some figuring out. (See Relative URLs earlier in this chapter.)
4. Use this information to change the address of the URL to open the image. In other words, get the Location or Address to read the full path to the image, and then the image name, for example:
http://www.pearson-plc.com/pics/bground.gif
In this case you would add pic/bground.gif to the end of the present URL in the Location or Address text box of your browser.m
- 5. Then press Enter. The image should appear on your screen. The Pearson
home page background is shown in Figure 5.2.
- 6. Choose File, Save As from the browser menu to save the image on one of your own hard disks with whatever name you wish.
I am not advocating the use of background images and rarely use them for Intranet documents. This is at the request of a broadband narc I know who counted how many hours it would use each day for X number of employees to "hit" the home page and wait for "gratuitous graphics" to download. I make a concerted effort to make sure the graphic images that are added to the pages I author have meaning and/or value. See Chapter 7 for tips on shrinking the size of documents.
Figure 5.2 Pearson's home page background image
Finding a Whole Library of Images
If the subdirectory where images are stored is at a different level than the one you are in, you may discover a whole library of images while you are going through the downloading process. For example, in the Pearson home page, notice that the background image was stored in a subdirectory called pics. Apparently the Pearson Webmaster stores all the graphics for the Web site here. Many Webmasters wisely organize their sites this way. You may see a subdirectory such as images, icons, or gifs that will give you a clue about the contents. In this example, if you remove bground.gif from the URL you will see the index of Pearson's pics as shown in Figure 5.3.
Figure 5.3 A whole library of images
Linking Images
If you have done any Web surfing at all, you have probably clicked on an image instead of text to jump to another place on the Web. I call these hyperimages. When part of an image jumps one place and another part of the same image jumps somewhere else, the image is called an image map. For more about creating image maps, see Chapter 6.
Definition
A hyperimage or hypergraphic is a graphic that jumps to another location when you click on it. An image map is a graphic with sections (defined by coordinates) that hyperlink to other locations.
When you author documents containing hyperimages you can code the link with BORDER=0, which causes the outline to disappear. For instance, in Figure 5.4, the image at the top is coded with BORDER=0 so it will display without a halo box and look as it was originally designed to look.
Figure 5.4 Two linked images. One with a border and one unlinked image
A conscientious HTML author will also faithfully use ALT text with every graphic. Users who are on a slow link often prefer to turn graphics off completely or press Stop after the browser receives the main document.
This means if you get tired of waiting for all the graphics of an HTML page to download and you press Stop after the main document is downloaded, you will have an idea of what the pictures are even though you couldn't wait any longer to see them. More importantly, if the graphics are hyperlinked, you will still have all the navigational savvy to know where the graphic might link to. For instance, the ALT text of a little button with "TOC" on it should probably be "Table of Contents." This is a human factor consideration as well. Blind users turn all images off in their browser. The reading tools they use that send messages to be read by touch cannot view graphics.
Definition
A good HTML author will always put in ALT text that describes the image.
Slow-link users may also be Intranet users in outlying offices or telecommuters who are dialing in. Figure 5.5 shows how the ALT text of the images in Figure 5.4 would look if the user interrupted the transfer of the document. The file cabinet is replaced by a broken image, but the ALT text tells the user what the image represented. Notice that the top two images include the word hyperimage in the ALT text to clue users in.
Text Files
Browsers can read text files. So, if you just want to get information posted to the Web, you don't really have to convert it to HTML. This is nice to know if you have a page of information that does not require fancy formatting, hypertext links to other documents, graphics, or anything special. For instance, if you have simple news flashes or other items that you would like to post to a Web site and your main concern is merely content, all you have to do is save it as a text file in your word processing program or from an e-mail message and then upload it to your Web server.
Figure 5.5 The ALT text of the images in Figure 5.4
Three Examples of Text Files Loaded on the Web
To get the best readability in a Web browser, your text files need a little bit of preparation. For example, the previous paragraph was saved with no preparation using File, Save As Text Only from a Microsoft Word 6.0 document. Figure 5.6 shows how hard it would be to read this file in a browser because it doesn't wrap the sentences to the next line.
With just a slight change using File, Save As Text Only with Line Breaks, the paragraph returns at the end of each line, readability improves considerably as shown in Figure 5.7.
As a content provider you will always want to consider the "lowest common denominator" of viewers. In most cases this will be users with laptops. There is one other slight improvement you can make before you save a text file destined for Web browsing. Reduce the width of the lines on the word processing page by increasing the right and/or left margins before saving as Text Only with Line Breaks. This will cause the line breaks to "wrap" so users can read the text without scrolling, as shown in Figure 5.8.
Figure 5.6 Saved as Text Only with no preparation
Figure 5.7 Saved as Text Only with Line Breaks
Figure 5.8 Saved as Text Only with Line Breaks and reduced margins
Alternative Viewing Possibilities
It's hard to compete with HTML for low bandwidth and hypertext capability. And each new generation of HTML comes up with new formatting capabilities. As several companies scrambled to create programs that would present desktop publishinglike formats on the Web, HTML evolved with features such as tables, frames, and text wrap-around images. However, converting everything to HTML is time consuming and therefore expensive. It is also unnecessary, but text documents can be really boring.
Portable Documents
The first alternative viewing possibility is portable documents, which basically aimed for a "fax on glass" approach using Web browsers as a printer. You may recognize this type of product as Adobe's PDF, Tumbleweed's Envoy, or Common Ground's Web Publishing System. These portable documents are like HTML in that they are platform independent but they require proprietary viewer programs for accessing files. Their big plus is that they allow authors to control type, design, and layout. They are easy for authors but not so easy for users. Just as I'm sure you've experienced difficulty reading small print or graphics on a fax, viewing is sometimes limited. This requires special software, skills, and extra effort for HTML functions such as hypertext links or "hotspots." Also, it is impossible to implement forms using this format. But they definitely have their place. For instance, you may have documents such as timelines produced by applications such as Microsoft Project that you want to link to other documents. Using portable document formats is the only way to accomplish this.
Universal Viewers
Another wonderful technology that is rising to the occasion of Internal Web Document Management is universal viewers (mentioned in Chapter 9 as a document management solution). Some products that you may recognize in this area are Quick View Plus from INSO, KEYview from FTP, and Adobe File Utilities. These are plug-ins or add-ons to browser client software. There are presently a lot for Windows, a few for the Mac, and very few for UNIX. Plug-ins allow you to view documents in their native format without launching the native application. All you can do is view, but for many legacy documents viewing is all that would be necessary anyway. It's a real plus to be able to view documents without having the threat of Trojan horse viruses lurking in open and close macros and sans the waiting time of launching an application. Table 5.3 compares the various document formats for viewing Web documents.
Authoring Tools
HTML Editors
I work on the Windows platform and after evaluating several editors, I chose HTML Assistant Pro (http://www.brooknorth.com/htmlpro2.html). After I was pretty locked into its familiarity, Hot Dog (http://www.sausage.com/) entered the market. I tried it out and considered it better than many editors I had previously rejected, but I stayed with HTML Assistant Pro because I was used to it and had already purchased it.
There are several Web pages that have lists and comparisons of editors. Two URLs where you can find such lists are shown in Table 5.4.
Table 5.3 Viewing Web Documents
| Launches | ||||||
| Another | ||||||
| Document Format | Hypertext | Application | Drawbacks | |||
| HTML | Yes | No | Requires author expertise | |||
| Text | No | No | Boring | |||
| Portable | Yes, but | Yes | Need conversion | |||
| documents | not easy | software (expensive) and viewing software (free) | ||||
| Native file format | No | Yes, the native | Consumes time and | |||
| application | machine resources; possible vehicle for Trojan horses and viruses | |||||
| Universal viewer | No | Sort of, it's a | Possible interference | |||
| plug-in or | with other installed | |||||
| add-on | applications on the client PC | |||||
Table 5.4 HTML Editors
| URL | What You Will Find There |
| http://204.91.49.11/hteds.html | Public HTML editors |
| (http://www.columbia. | Suggested editors |
| edu/~rk35/www/editors.html) |
WYSIWYG Editors
Every day more products are entering the market, so I don't dare tout one too highly because I might have a new favorite before the copyeditor gets through with this chapter. But, because as I said in the introduction, I want to give you the wherewithal to make the right choices, so here are my opinions about the WYSIWYG editors I have used.
Some of the big names are Netscape Gold, Microsoft Front Page, and Microsoft Internet Assistant. They are wonderful, especially if you are creating tables. They are terrible if you want to see what's going on with the HTML. Actually you can see what's going on with the HTML by viewing the source in your browser, but you cannot edit the HTML, which to me is a huge drawback.
WYSIWYG editors decide what META data to include, and they always say they are "created by this wonderful editor" even if you open the document you created another way to make a few additions to a table. This means if you want to put "Subject Matter Expert" in the META field, or duo authoring credits, or your e-mail user ID as comments in the source, you need to add these changes in Notepad or another editor. If you are using one of the many plug-in/add-ons WYSIWYG editors to Word and you want to edit the HTML in Word, you will have to rename the file as a .txt file, then open it in Word in order to see the HTML. Otherwise if you open the file as an .htm it will automatically launch your plug-in/add-on.
Now I don't want to be rude, but I also found a few bugs. I will not name products because both bugs I am about to mention are in two major players, who battle each other in the press, and sometimes in court, daily. These two major players are so competitive that they will probably fix these bugs before this book goes to press. Nevertheless, I recommend that you download free software and test it before you buy it or if it is free, that you make sure you can uninstall it if you don't like it.
Bug Alert #1. Test to see how it converts legacy documents. My testing of duo purpose editors showed that they were good at one thing but not good at another. I basically got a mess and had to invest way more work clean-up time than it would have taken to create a new document.
Bug Alert #2. Test to see how links are formatted. One WYSIWYG editor that uses drag-and-drop technology automatically chose to insert relative links in all caps. These relative links retained the original file source. This means that they contained information that became obsolete as soon as they were on the server, some such nonsense like c:\|file/// which of course caused lots of "404 Not Found" consternation. And, since different operating systems pass along filenames in various ways when you move your documents to the server, they often end up as lowercase filenames, and therefore unreadable by these documents. Way, way, way too much postprocessing for my taste.
What to Look for in an Editor. There were three main drawbacks that I encountered while evaluating HTML editors:
- 1. Most of the editors choked on documents over 32K. (HTML Assistant
Pro's free version has this limitation, but the licensed version does not.)
- 2. The editor was a "plug-in" or "add-on" to Word. This is really cumbersome because Word for Windows "holds onto" the document if you are on a 16-bit operating system. This means that if you want to look at your document in a browser you will get a message that says it's already open or not available. You have to close the document, open it in a browser, then if you have any corrections open the document again, and so forth. The 32-bit version doesn't hold onto the document and neither does the Mac version, according to my MacFriends. I also personally do not like Word plug-ins and add-ons because they are often difficult to uninstall.
- 3. I didn't like the editors that "validated" the code for me. It took too long to figure out what messages the editor was reporting. In the meantime, the editor would not let me proceed. I prefer to debug the HTML myself after proudly displaying my mistakes in my browser :-).
- 2. The editor was a "plug-in" or "add-on" to Word. This is really cumbersome because Word for Windows "holds onto" the document if you are on a 16-bit operating system. This means that if you want to look at your document in a browser you will get a message that says it's already open or not available. You have to close the document, open it in a browser, then if you have any corrections open the document again, and so forth. The 32-bit version doesn't hold onto the document and neither does the Mac version, according to my MacFriends. I also personally do not like Word plug-ins and add-ons because they are often difficult to uninstall.
Conversion Utilities
You can actually create your online documents in the familiar environment of word processing or create tables in Excel and then convert them to HTML.
Advantages to Using Conversion Utilities
Here are some advantages to using conversion utilities:
- * You can maintain a printed version and an HTML version of your document
in a "one-button publishing" format. Sort of. (See the Drawbacks
to the Advantages section.)
- * Conversion utilities often have other perks, like automatically building a hypertext table of contents or an index. They can break the document into smaller bytes, create HTML tables, and do a great job of converting graphics.
- * You can work in the familiar word processing, WYSIWYG environment.
- * Conversion utilities often have other perks, like automatically building a hypertext table of contents or an index. They can break the document into smaller bytes, create HTML tables, and do a great job of converting graphics.
Drawbacks to the Advantages
You'll want to weigh the advantages of using conversion utilities against a couple of drawbacks:
- * The names that conversion utilities give to anchors and converted
graphics are not as intuitive as the ones you choose. For instance, within
a team phone list you may want to have a table of contents that hyperlinks
to each subteam. If you were naming the anchor for the LAN team, the Messaging
team, and the Remote Access team, you would probably choose names like
lan, messaging, and remote. Conversion utilities generate names like l1,
l2, and l3. They also use a preponderance of lowercase Ls, which look a
lot like the numeral one. This makes reading the HTML code nearly impossible.
So I use Edit, Find a lot once I've converted a document and want to tweak
it in my HTML editor. Likewise, a graphic that you name bell-curve might
be named l13.gif by a conversion utility.
- * Don't be fooled into thinking you don't need to know at least a little about HTML--it rarely converts seamlessly.
Three Utilities
There are a lot of conversion utilities out on the Web and more appearing every day. As mentioned earlier, some HTML editors (including my fave, HTML Assistant Pro) now contain conversion utilities. But I would be amiss if I didn't tout the one that I think will lead the pack for a long time: HTML Transit.
HTML Transit. HTML Transit maps word processing styles to HTML tags. The better you "style" the document up front (see the next section), the better results you will get after conversion. It also converts tables and graphics in the process. I think the feature I like best is that I can mark index items in a word processing application and when I run the document through HTML Transit, it creates a hypertext index. Way cool. The latest version even allows you to put HTML code in a word processing document, hide it so the printed version doesn't print it, but the converted HTML version has a link. You can download an evaluation copy at http://www.infoaccess.com.
RTFTOHTML. This is a free utility that works on Windows, UNIX, and Macintosh platforms. After you create a document in Word, you save it in RTF (Rich Text Format) and then run the conversion. It does not do a great job of converting tables, and it doesn't do graphics at all. It does, however, create an automatic link to all the graphics it finds in a document. This means that once you convert the graphics to a GIF or JPG format, you can "plug them in" the spot RTFTOHTML creates, using a "click here for picture" remark. This free utility combined with XL2HTML and a good graphics application would be sufficient for someone who doesn't have a lot of Web-head responsibilities. (See Chapter 7 for some tips on converting graphic images.)
XL2HTML. Not only is this utility useful for converting Excel tables to HTML tables, but you can also drop a Word table into a spreadsheet to get some extra mileage out of it. It's free and easy to use. Directions for using it are on the same page where you can download it:
http://rs712b.gsfc.nasa.gov/704/dgd/xl2html.html
Using Word Processing Styles for Mapping
Word processing styles are a saved set of formatting for a paragraph or characters that have a name. They not only help with conversion; they make it easier to author documents because you simply choose a predefined format. For example, making a title big, bold, and blue takes only one step when applying a style rather than selecting three different formatting properties.
From a word processing point of view, styles save time. Here are the main advantages to using styles while word processing:
- * It's easy to format more than one paragraph or set of characters
to look the same.
- * You can change all instances of a style in one fell swoop.
Tables 5.5 and 5.6 show examples of paragraph and character style names and their associated formatting styles.
Table 5.5 Paragraph Style Examples
| Style Name | Formatting Associated with the Style |
| Heading 1 | Arial, 20 point and bold |
| Heading 2 | Arial, 14 point, bold italic |
| Normal | 12 point, Times New Roman |
| Quotes | 12 point, Times New Roman, indented 1/2 inch on each margin |
Table 5.6 Character Style Examples
| Style Name | Formatting Associated with the Style |
| Warning | Bold, Small Caps |
| Author | Bold, Italic |
One-Button Publishing
For the Web publisher a big advantage to using word processing styles is that they can be mapped to electronic publishing. Here are a few of the existing tools that convert word processing styles into HTML tags:
- * HTML Transit
- * HTML Assistant Pro
- * Internet Assistant
- * OmniMark
- * RTFTOHTML
- * HTML Assistant Pro
This is not a complete list; in fact most of the HTML editors have a conversion feature. That is, you can have a printed version and an electronic version of the same document. When you need to update the document, theoretically you need to update only one version, and then run the mapping program. Unfortunately this process is not seamless and usually requires posttranslation processing on the electronic copy that will need to be repeated after each update.
Summary
There are lots of ways to view documents on the Web besides authoring them or converting them to HTML. You will want at least a few HTML documents, however, to make your site a cool hypertexted Web. You don't have to master HTML to author these documents. WYSIWYG editors and conversion tools simplify the process of authoring, but someone in your organization will need to know how to read the HTML source. Using relative URLs within documents allows you to move a set of Web documents from local drives to the server or to a different spot on the server without recoding the links within each document. Conversion tools make it possible to have one-button publishing as well as a printable document and an HTML version. Finally, the quality of these documents, especially the hypertext capability, is greatly improved if you use styles in the word processing version.
| TalkBack: Post your comment here |
Copyright © Intrack Inc. Privacy Policy