Lesson 1 First of all, let's nail down a default font for this whole page. I use Arial on the whole website, so Iet's enter "Arial" in the menu for the default proportional font. The browser preview actually shows Arial, but this is what it looks like:

I chose Arial for this paragraph!

This is what the HTML code should show at the top of the page if a default font were actually defined: <basefont face="Arial">, but it's simply not there. Well, Netscape doesn't support the base font anyway, so it's a bit like a swindle by Frontpage to offer this option at all - especially since Netscape was the all-dominating browser when they introduced the base font in a previous version (Frontpage 2.0 already had it). If they use it though, it should at least work in Internet Explorer, but the tag isn't even created! Note that I actually have to format every single paragraph like this one with <font face="Arial"> to actually get Arial. This takes me to the next nifty feature.

Lesson 2 Let's continue with Arial - and say hello to my best friend, the font dropdown menu. It seems Frontpage tries its best to always take me back to the only correct HTML text format in the universe, Times New Roman 12pt.

This paragraph I inserted is formatted with the default font, which, as we know, is always Times New Roman.

Hey, this paragraph starts with Arial again! It is so annoying that Frontpage reverts parts of the text to the "default font", unless I type paragraph by paragraph strictly from the top to the bottom.

Lesson 3 I hope your browser shows the font change which happens exactly now. Frontpage is creative in leaving occasional </font> fragments in the HTML which are interpreted by Netscape as being closing any other font format, such that the browser returns to the default font (see also above). The font change is not displayed in Frontpage, and in some cases it can't even be edited. BTW, the second "font" command I typed manually changed the paragraph back to Arial, otherwise the rest of the letters would be in Times New Roman too.

Lesson 4 This is an example of strictly adhering to one font size. As you can see, everything is font size 2:

Romulans, Ferengi, Bajorans, Cardassians, Dominion, Borg, Species 8472

Well, that's what I thought until I had uploaded it to the server. Although the whole line was visually font size 2 in Frontpage, the text after the new word ("Bajorans") was changed to font size "standard" for unknown reasons.

Lesson 5 Now let's insert a small image:

Isn't it cute? You will notice that it's one of the banners from my homepage. What, you don't see it? Well, I do. Strange URL
file:///c%7C/WINDOWS/TEMP/FrontPageTempDir/wpe15230.jpg? Impossible. I just copied it from my homepage and pasted it first to another page and then just above this paragraph. Well, I agree that something was wrong, since Frontpage prompted me to save it once again, and I didn't. But what happened?

It's obviously a bug in the web management. Frontpage doesn't remember from where a copied image actually comes if the source has been closed in the meantime.

Lesson 6 Let's try once again:

Bird of Prey

It seems to be the same crap as above, but is still another (albeit related) error. This time the link doesn't point to the temp directory, but both the image text scans/bop-top-color-t.jpg and the link scans/bop-top-color.jpg remained unchanged when I pasted the image in WYSIWYG mode (not the code!). They are defunct from this directory and would work from the root only. If I have to edit links manually anyway I don't need Frontpage to keep track of them.

Lesson 7 Absolute links are already bad enough, but I once encountered something even more deceitful. While I was editing an HTML page I downloaded a file with capital letters in it to be included in the page. I routinely changed the file name to small letters, and I did so in the link too. Frontpage, however, for some reason insisted on the link being written in capital letters when the file already had small letters. I tried it several times, I edited HTML directly, I closed the program, I even deleted the administration files for the HTML page. No use, every time I typed the small letters the link was again in capital letters afterwards, and it gave me a 404 on the Unix server. Well, maybe all this trouble with links won't happen in a new web.

Lesson 8 So let's create a new Frontpage web. I have been using Frontpage 2.0 for quite a while, and the default directory was webshare\wwwroot\my_web, where it didn't matter on which hard disk it was created - at least it could be changed after it had been created on drive c. The next generation, Frontpage 98, prompted me to move everything to a new directory Frontpage Webs\wwwroot\my_web, and once again I could select any drive. It was easy to anticipate that the site had to move once again with Frontpage 2000. Now everything has to be in c:\Eigene Dateien\Eigene Webs\my_web, and there is no way of creating a new web elsewhere. It's the enforced directory in the German version of Windows 98, where I am supposed to save *all* my data - My Documents in the English language version. I have tens of thousands of files, and I comply - they are all below this directory. Just kidding. Microsoft makes it really hard to keep system, application and personal data separate. Fortunately, while it can't be deleted, the My Documents directory can be moved where it belongs - out of my way. I was told that this is possible just as my disk c: had no space left thanks to Windows and other overly inflated programs.

In addition, note especially the Netscape-friendly directory names with spaces in them! Netscape doesn't recognize spaces, and you have to fill them with %20, otherwise the link is defunct. Fortunately it works on the local hard disk, but many people might get the impression this would be possible on the server too.

Lesson 9 Unfortunately, there are some amazing Frontpage bugs features that cannot be experienced with every browser. Only if you use either Netscape 3 or Internet Explorer, you will enjoy the refreshing difference between the two following images:

Studio model - side (Star Trek Mechanics)

Studio model - side (Star Trek Mechanics)

Well, the images are the same and the links are too, but do you notice the difference? The image and text on the left share a common link, and when you click the text link with Netscape 3, you see the image frame flashing, and a common dotted frame is drawn around the image and link in IE.* In the right combination the links are separate, and you don't see the flashing frame in Netscape and only a frame around the text link in IE and Mozilla 1.4.

The program occasionally seems to create arbitrary codes when editing an already existing thumbnail/link combination with a <br> (line break) in between. So what is so bad about it? I actually have to verify each single thumbnail link in the browser and if the link is not according to my standard (which is currently "common" on the most pages and "separate" only on older pages) I have to apply a complicated procedure that takes a minute or so for each dumbnail. This might seem like a minor bug, but it makes me mad, for it undermines all my efforts to create a perfect website. In my view editing an ordinary gallery page should be possible without trouble, since once I have one template of links and thumbnail locations I might just replace them, and most importantly without caring about the format. This is simply not possible with Frontpage 2000. The editing and correcting may take three times as long as it should, and even longer than in Frontpage 2 which had crappy editing functions but whose code was at least predictable, some experience provided.

Lesson 10 The inventors of HTML knew what they were doing. They didn't allow anything but tables to format any kind of text and image arrangements in HTML. I would never consider using absolute positions for everything in units of pixels, even though one day a new browser generation will force me to spend months to convert this whole site to CSS. But bad use of CSS has brought us either messy designs which look different in every browser or "professional" page designs for 640*480 pixel VGA resolution. This is not what I have a 19" or bigger monitor for! Therefore I stick to variable width tables for the page design.

However, this is what a newly created table looks like in Frontpage:

There's nothing more annoying than having a 3D border around every table, a feature which isn't desired in 99% of all cases and which I don't use at all since it looks so 1994. Moreover, the above table has a cellpadding="1" (which is the default and therefore not displayed in case you bother checking my HTML), which means that the text is only one pixel away from the very edge of each cell. Anything but well-designed. To complete my annoyance, the table width is "100%" and its alignment is "default" (usually meaning left-aligned). Oh yes, and it's Times New Roman in every new table, of course. I have to change all these settings before the table is half-way reasonable and before I can even think of changing colors (which is very convenient in FP 2000, by the way) or adding content.

Lesson 11 Graphical editing, meaning dragging edges or corners of something instead of typing numerical values is usually a pleasant thing, but not in the case of Frontpage tables. If I hold the mouse button while moving through a table (to select a couple of cells), I may easily get too close to the cell boundaries and *all* the table and cell widths (or heights, depending on the direction of movement) are changed to absolute values in pixels. There is no way of globally removing the new formats from the table (unless I want to remove all width/height formats), except for pressing "undo" (see below). If undo is not possible it is often easier to create a new table and move all the content there.

What is so bad about absolute values? Well, in some cases it's quite useful, for instance if there are images with certain widths and heights for which a definite table layout may be created. Usually, however, the table should be as wide as possible and as high as necessary, especially if the page is designed to fit into different screen resolutions (like EAS which is designed for a minimum of 800*600, but for which there is no notorious "optimum" or "recommended" resolution). Thus, a single mouse click may mess up a whole page layout. If you have ever seen websites with table widths of more than 1000 pixels at a resolution of 1024*768, you know what I'm talking of.

Lesson 12 Well, with so many bugs in Frontpage it's comforting that there is an "undo" function. Every time something has been screwed up, I simply push the "undo" button and Frontpage returns to the version before the last action - well, sometimes it really does. Occasionally, however, Frontpage returns to the first version - not even the last saved state but the very first state when the page was loaded! The undo list seems to have reversed its order and shows the first action first, and not the last one! Only quickly pressing "redo" and trying to fix the error manually helps in such a case. Meanwhile I often refrain from using the undo after it has caused me nothing but trouble. And I follow the old rule rule "Save early - save often."

Lesson 13 If I really hate something about the Windows 98 user interface, then it's the menu animation. I have already installed Win 98 on a couple of computers, and my first step after the welcome screen always was to disable the animation - except for the first time when I had to search a while where it could be disabled. Frontpage has an independent menu animation, but fortunately it's not the default setting. It takes *several seconds* for the menu to roll down on my Pentium 500MHz computer! It seems Microsoft thinks people actually take the time to "enjoy" these nifty features. I don't, because I want to work with my computer.

Lesson 14 There is an inexplicable error in the following table:

Skrreean emigrant ship (image by Neutral Zone Starship Database)

Petarian freighter Xhosa (Star Trek Fact Files)

Xhosa screencap (image by Neutral Zone Starship Database)

This happened when I selected the whole table row and assigned it the font Arial. For some reason the font tag was removed from instead of assigned to the left cell. As if this were not bad enough, the editor window still displays Arial whenever I open the document, although the font face format is gone. With the idiotic "default font" option (see above) disabled, it should be displayed as Times New Roman like in the browser (IE, it is Arial in Mozilla) too. The worst of all is that the table cell is not editable. Frontpage insists on the font being Arial, and my only chance to really get Arial is to change it in the HTML code. Also, the text in question is shifted down with respect to the other cells (in every browser), apparently the result of a space behind the image that is not editable in WYSIWYG either.

Lesson 15 Website management is only as efficient as it is fast. If I have to wait up to 30 seconds for a single page to save, I may hit the "save" button too seldom, and some changes may be lost. 30 seconds, that's about what it took to save each single HTML page irrespective of its size, until I discovered the reason: There was a huge file in the \_vti_txt\default.wti directory of my web (some webs have this directory, some not). It seems to be some sort of log file that is completely rewritten each time the slightest change is made, and after hundreds or even thousands of actions it will sum up to over 20 megabytes. I have no idea what it's actually needed for and I don't care, since it can be simply deleted without any consequences!

Lesson 16 "Width" and "height" properties allow to predefine the size of an image when it is being loaded. Every HTML tutorial says that each image should be given a width and height, to keep a page from shifting forth and back a page with images when it is loaded. This is not always useful, though. Especially banners and other images provided by another party or from another server should not be tied to a specific width and height for the simple reason that the proportions could change without notice. Frontpage, however, ignores its own option to decide whether an image has a fixed size or not. No matter whether the box is checked or not, the size is always nailed down to *something* in the HTML Frontpage creates. This is no problem as long as the image is on one's own server because in this case the width and height tags are always the width and height of the very image as it should be. But in the case of banner images from other servers I need to disable the fixed size. However, if I uncheck the fixed size, the size is set to 32*32! So trying to create a banner page with adaptable widths as it should be is not possible in the WYSIWYG view.

Lesson 17 Frontpage occasionally leaves fragments like the following in the code: <a href="http://www.someothersite.com"><br></a>. That's right, a line break with a link! Something totally useless that remains invisible in the browser. So why is this small pollution of the code so annoying? At latest when Frontpage itself or another link checker tells me there is a dead link, I have to verify whether it is a real link that I have to fix or an invisible one that I should remove. Moreover, as stupid as it is, while Frontpage allows me to edit links with its built-in link checker, it is not possible to simply delete them! Moreover, with false links the site structure as recognized by Google or by other crawlers will look like it were messed up.