FrontPage 101

As will be obvious to some, this HackingFamily.com website was put together with Microsoft FrontPage.  I've looked at Macromedia DreamWeaver, but FrontPage seemed easier to use.  I've spent a lot of time repairing some disasters put together by DreamWeaver.

This FrontPage 101 page is not a tutorial, but a collection of thoughts we've put together over the course of building this site.  After emailing these thoughts to a handful of friends who are starting websites, I decided to publish them so others could benefit as well.  Some of these are fairly advanced concepts and some very trivial.  If you're just starting out building your own website, you should probably consider getting some sort of tutorial.  We used the book "FrontPage for Busy People" to start out, which was helpful, especially for planning our site.

If you're interested in this, you should also check out our FrontPage Frequently Asked Questions page.

I hope this page will evolve and get more detailed, but for now I've included:

Please email me if you'd like to see other topics covered.  Also, if some of this is unclear, let me know and I'll modify it to really confuse you!

The first thing you want to do, before you even think about firing up FrontPage (or any other web authoring tool) is to plan your site.

	What kind of information or data will you be presenting?
	What's the most effective way of presenting it, so people can find it?
	What sorts of headings do you want?
	How do you want to organize your site (its presentation)?
	What folder structure will best hold your information?
	Plan now for future expansion and for modification (which can be difficult).

For instance, in June 2005 we redesigned our home page.  We wanted folks new to our site to know where they've got to (which our old home pages handled too well) but we also wanted regular visitors to know what's new on the site quickly and easily.  We also wanted our home page to be easy to modify incrementally, without having to re-write the whole thing before each website update.  To achieve these goals, we shrank our font a bit and put 3 columns of information near the top of the page, in more of a news type format.  Hope you like it!

Hierarchical Pages:

FrontPage has the concept of hierarchical pages, which is important to understand (I could not find this concept in DreamWeaver).  They're similar to the folder structure on your hard-drive, but are not actually related to that structure.  That is, just putting a new file in a sub-folder does not put that page "under" the parent.  A Parent page can have children from all over the website if you want.  However, you'll probably want to keep parents and children close to each other, just for maintenance purposes.

For instance, all of my pages are in a "Jon" folder.  Jon.htm is the parent page, and all my other pages (like this one) are children of that parent page.  Another child of Jon.htm is my pre-history page, which itself has several children.  This means that my pre-history page is all 3: a parent (of the many stories under it), a sibling (of this page as well as others) and a child (of Jon.htm).  Physically, my pre-history page and all its children are in a Pre-History_Stories folder under my Jon folder, as my Brewing pages (parent and children) are all in a Brewing folder, also under Jon.  This physical similarity to FrontPage's hierarchical structure makes finding pages quickly easy for us.

Our Destinations section has quite a complex structure, but since it's all hierarchical, they're easy to find and organize.  All our Tonga pages are in a Tonga folder under our Destinations folder.  Tonga.htm has all of our other Tonga pages as children, and all reside in the Tonga folder.  Its parent is the Pacific Ocean page, which, in turn, is under Destinations.  For our own convenience, we've put our main Destinations page, as well as our Pacific Ocean page and our Indian Ocean page, all in the same (Destinations) folder, even though Destinations is the parent of the other 2.  So, while our relationship between folder location and page hierarchy is close, it is not exact.  We tend to have a deeper hierarchical structure (more layers) than our folder structure.

This hierarchical structure is very handy, as once established, FrontPage will then automagically generate appropriate navigation bars (FrontPage calls them Link Bars) for you!  If you look at our site, all the links on the tops, sides, and bottoms of the pages are all auto-generated and auto-maintained (click: Insert, Navigation, Link Bar).  Very cool.

To see and manipulate the hierarchical structure of your site (once you've added some pages), go to the View menu and select Navigation.  You can add new pages to your structure, or move existing pages around just by clicking, dragging and dropping.  There's no automatic sorting - whatever order your pages appear in will be the order they're displayed in on the Link-Bars.  If you want to change the order pages are displayed in your link-bars, change the order in the Navigation structure.  Small sites will probably be fine with the default landscape view, but larger sites may want to switch to the portrait view (button in upper right corner).

Note that FrontPage does not immediately create the new pages.  Instead, it waits until you try to leave the Navigation View.  Then there may be a noticeable delay, accompanied by appropriate crunching and gurgling from the hard drive, as it creates the new pages.  When the new pages appear, FrontPage puts them in the root folder, so you will probably want to move them to a more appropriate subdirectory (folder) right away.  See also: Hierarchy on the FAQ page.

On a related topic, the graphic buttons (which are the default) that FrontPage generates for these Link-bars are all .GIF files.  These graphic files aren't very big (typically only 2-3KB each) but each one has to be downloaded separately to the client's browser.  On a high-bandwidth connection, you hardly notice these downloads, but lots of the world doesn't have such nice connections.  Our site takes hits from all over the world, many on slow connections, so we've started replacing the pretty graphic buttons on the site with text-based Link-bars, like the ones on the upper left (and bottom) of this page.  These are typically 200 times smaller and therefore much faster to download, making the page appear on the client's computer that much faster.

Some general rules:

	Plan the structure of your site first, before you start writing the text.  What sort of headings or areas will you want?  What sort of content will you be promoting?  How do you want to organize it?  Look at several sites to see what you like and what you don't.  Take notes.
	The vast majority of folks will find your site via search engines like Google.  Therefore, do not change the location of pages later (which will confuse all search engines).  Plan for expansion (this can be difficult).
	Do NOT use spaces in the file-names or folders (or even photos and other objects) on your site.  Yes, it's perfectly legal to do so, but it's a pain to send a link to someone.  We goofed several times (see http://HackingFamily.com/Boat%20Guests/boat_guests.htm).  Notice the %20 I have to put in for the space between "Boat Guests"?  Problem is that there's a fairly elaborate structure under there with ~30 pages, so it was difficult to change it.  Too many people (and search engines) had bookmarked it the way it was, so each page had to be meticulously duplicated with a custom auto-redirect to the new location.  Click on the link above to see this.  The relevant bit of JavaScript code to make this work is: <script LANGUAGE="JavaScript"><!-- parent.setTimeout("parent.location.href=\"new_page.htm\"",5000) // --> </script>
	All pages should be added via FrontPage, or it will not know to add them to the automatic Link-bars
	By default, FrontPage puts all new files in the root folder (probably not where you want them)
	Once created, files can be moved to more appropriate folders, but again, this MUST be done in FrontPage, so FrontPage can adjust all the (many) links associated with that file.  Also, once you publish a page, do NOT move it (as per above) so make sure everything is correct before you publish.
	I suggest putting all user created image files (jpg, bmp, gif, etc.) in the IMAGES folder.  FrontPage will not always do this automatically, so you have to check it each time.
	When adding links to other websites, you probably want them to open in a new window, so folks don't leave your site.  To do this, in the Hyperlink Properties dialog box, click the Target Frame... button and select New Window.
	If you put in dated updates, I suggest 2 digits in front of your monthly file-names so they sort appropriately - that is, 07_xxx for July, 10_xxx for Oct, etc.  Otherwise you end up with silliness like December coming before January.

Non-breaking characters:

Sometimes you want the browser to keep certain word-groups together, like "St. Martin".  You don't want the browser to break the line between the "St." and the "Martin".  To accomplish this, use a "non-breaking space" where you don't want breaks.  In FrontPage, this can be done by holding down ctrl-shift-space.  If you look at the html, it will produce something like    This tells the browser that if it can't put all of St. Martin on the line, put the line-break before it and move the whole thing to the next line.  This is very handy, and we use it a lot.

Similar in concept is the non-breaking dash.  MS Word has a concept of this (ctrl-shift-dash, or "‑") but FrontPage isn't so smart.  Copying a ctrl‑shift‑dash from Word to FrontPage does work, but it produces the character code #8209;, which I'm not sure displays correctly on non-Windows browsers.  Within FrontPage, the best I can come up with is to insert a "horizontal bar" or ― (Insert, Symbol..., and it's usually down near the bottom).  This method has 3 problems:  First, the bar is longer than than a dash and doesn't look as nice, the Insert, Symbol... tool always puts in a <font> tag (which I have to remove afterwards) and the code produced is #8213; which may also not display properly on non-Windows browsers.  Probably the easiest thing is to copy a ctrl‑shift‑dash from Word or just copy the character from this webpage.

Page Width:

One decision you'll have to make early is: do you want to design your page to a fixed width, or do you want your pages to fill your customer's window, expanding and contracting as they change their window size.  This is actually more important than it sounds.  Designing to a fixed width is easier to both build and test, and it guarantees that your viewers will see just what you do.  But if you decide to make all your pages, say, 1,000 pixels wide, it will be a pain for those folks using 800x600 displays, or windows smaller than 1,000 pixels.  Nobody likes having to read something while futzing with the slider-bar at the bottom of the screen.  Also, those folks with nice wide displays will be annoyed at the wide margins with no information.

As you can easily tell just by changing the size of the window you're reading this on, we try to accommodate whatever size our user's window is.  We believe this gives you, the user, a better experience, but it presents some interesting design and testing challenges.  From a practical standpoint, we don't really test below 800 pixels wide (most folks will use windows of at least 800 pixels) and we can't really test on windows above 1440 pixels wide, because that's the size of our biggest computer screen.

One of the main issues with a variable size screen is trying to keep your photos from "catching" on each other.  We tend to alternate our photos, first on one side, then the other.  This minimizes the problem.  Even so, if there's not enough text (or the screen is too wide) then the pictures can run into each other, with unintended effects.  One way out of this is to enclose both text and photos in a zero border table with the width set to 100%.  If the table is allowed to run the full width of the screen, then other text (or tables, or photos) below will display better.  Our entire Reef Animals and our Flora and Fauna sections make extensive use of this technique, as they're mostly photos, with relatively little text.

To start a new site (on your own hard drive, in order to upload it later):

1. Start up FrontPage (lets get down to basics here...)
2. Click File, New... to bring up the "New" menu on the right
3. Select More Web site templates (near the bottom) to bring up the Web Site Templates dialog box
4. On the right, Select the location for your new website on your hard drive.  This defaults to ...\My Documents\My Web Sites\mysite, but you'll probably want to rename at least the last bit.
5. On the left, select the type of site you want to create, usually Empty Web Site or Personal Web Site.
6. Click OK.  FrontPage will crunch and grind for a few moments creating your site.  Once it finishes, you can start editing your site.

Your home page will be called index.htm, and that should probably not be changed (for reasons that have to do with how web-servers work).  Depending on your selection above, FrontPage may have created other pages for you, which you can use or discard as you see fit.  One thing you will probably want to do early is to give your page(s) a theme.  When editing your page, select Format, Theme... and choose from the list that appears on the right hand side.  You can right click on the Folder List on the left to add new files and/or folders.  Double-click on a file to start editing it.

To add a new page in FrontPage (there are several ways - this one works, and it's not as complicated as it looks):

1. In the View menu, select Navigation.  This brings up a hierarchical representation of your website.
2. Click on the + sign on each page to display pages that are "under" that page.
3. Get to the parent page, ABOVE where you want to add your new page
4. Right-click on the parent page and select NEW and then PAGE.
5. Select the new page (new_page_1) and re-title it appropriately (ie, Oct 1, 2004).  This title should be short enough to fit in a Link-Bar button (18-20 characters MAX).  Spaces are OK here.
6. Drag the new file-box to the correct place in the hierarchy (ie, between Sept and Nov).  The order that these files are listed in the Navigation window will be the order they are displayed in the Link-Bars.  You can rearrange the order to suite your site just by dragging the boxes around.
7. Strangely enough, FrontPage has NOT yet actually created the page.
8. Click on some other view (like Reports or Folders).  You will notice FrontPage crunching and grinding for a moment as it actually creates the new page file.
9. In the folder list, note that the new file has been created in the root.  The file-name chosen by FrontPage will resemble the title chosen above (ie, Oct__1,_2004.htm).
10. I like to rename such a file (ie, 10_Oct__1,_2004.htm) to make it sort correctly in the Folder view, but this is just a nicety and not really necessary.  Do NOT use spaces here.
11. Drag the new file to the appropriate folder (ie, Voyage\Logs_2004).  Note that FrontPage corrects all links to and from this page
12. Double click on the new page to start editing it.

A somewhat faster way to add a page, for the more experienced:

1. Copy an existing page (that already has all your banners, link-bars, themes, etc.) to the folder where you want the new page.  It's best if you use a page that's at the same hierarchical level as the page you want to create, so all the nav-bars are correct.
2. Go to the Folders view.  Rename the copied page to what you want (ie, vavau_group.htm - no spaces!) and change the title (ie, Vava'u Group).
3. In the Navigation view of your website, go to the parent page of the one you want to add (ie, Tonga).
4. Right click on the parent and select "Add existing page..." or click the "Add existing page" button in the upper right.
5. Select your new page, so it will show up correctly in the page hierarchy.
6. Position your new page in the Navigation View so it's in the correct order (new pages default to being first).
7. Edit your new page by double-clicking on it.
8. Strip out all the cruft from the old page and add your new content, being careful to leave nav-bars and anything else you want to keep.

Notes:

	If you do NOT want a page to show up in the Link-bars, go to the Navigation view, select the page, right-click, and un-select "Included in Link Bars".  We do this to several of our map pages.
	I often open a page similar to the one I'm adding and look at the HTML (go to the Split view, at the bottom).  Then I can copy out things like the header and footer stuff, so all the pages all look the same.
	HTML is easy to read and modify - just make sure each open tag <blah> has a corresponding closing tag with a slash in front </blah>

Some general thoughts on photos and graphic files:

1. Alternating pictures from Left to Right down the page will make them flow better when the page gets re-sized.  You can do this easiest by selecting your photo (or the table the photo is in) and clicking either the "Align Left" or "Align Right" buttons on the Formatting bar.  This will also allow text to flow around the pictures.
2. Avoid putting pictures too close to each other.  They get "caught" on each other, creating strange and unwanted flow problems as the pages get re-sized.
3. If you want to put 2 photos next to each other, you should probably center them on the line and not have any text to the sides of them, just top and bottom.
4. Always check the Specify Size box (as well as the Keep Aspect Ratio box) in the Picture Properties dialog box.  This will tell the client how much space to allow for the photo, so the text won't be jumping around as the page loads.
5. FrontPage now has an auto-thumbnail feature that I've never used, but I should probably learn it.  It would probably save me a bunch of time.
6. Even so, you'll want to decide how big you want your pictures.  We usually use 320-350 pixels as our long side, but that's bigger than the thumbnails on most other websites we see.  We set the larger photos you get by clicking on a thumbnail to have maximum dimensions of 900x600.
7. Test your pages on your own computer before you publish them.
8. To view your pages on your own machine, make sure you use relative links.  FrontPage defaults to relative links, but some other web authoring tools may not.
9. To test how a page flows, open it in your browser and slowly re-size the width, watching how the text flows around the pictures and tables.
10. You might want to get a copy of FireFox and test your site with that as well as Internet Explorer.  Over 15% of visitors coming to our site now use FireFox (IE is down to less than 75%).  Making everything look the way you want with all browsers is difficult, as all use different rendering engines, but you should at least check it out.
11. Get a copy of IrfanView, a free download off the web.  It's a GREAT image manipulator, not as sophisticated as PhotoShop, but much faster and much easier to learn and use.  We use it to touch up color balance, gamma, and contrast, and to crop, rotate and resize our images for web publication.

Adding Mouse-over Text to your Pictures:

We like to add "mouse over" text, so a little descriptive text box will show up as the user mouses over a photo.  Only IE will display the contents of an ALT="description" tag if you mouse over a photo, but other browsers (and IE as well) will display the contents of a TITLE="description" tag.  Unfortunately, FrontPage only makes it easy to add an ALT tag, not a TITLE tag, but once you put in an ALT tag, a TITLE tag is easy to add.

1. In FrontPage, double click on the photo to bring up the Picture Properties dialog box
2. Select the General tab, and fill in the Text box with a short description
3. Close the dialog box by clicking OK.

To turn the ALT tag you just created into a TITLE tag, FrontPage makes you edit the HTML (don't be scared here).

1. Click the Split button at the bottom of FrontPage to display the code that FrontPage is generating.
2. Click on the photo to find the text you just entered (should look like alt="text you just entered").
3. Select the alt and change it to title
4. Click the design button at the bottom of the page to bring you back to your normal view.

Bingo - now your descriptive text will show up in most browsers, not just IE!  If you're more experienced, you can copy the alt tag as a title tag and have both, which is what we do.  You can also add title tags to your hyperlinks, to provide descriptive mouse-over text to them as well (you can see this on our home page).

If you want a caption under a photo, put it in its own 1x1 Table:
(we are slowly doing this to all 1,500 of our photos)

1. Position your cursor where you want the table to be (this must be at a paragraph break).
2. Click and HOLD the cool Insert Table button on the standard toolbar and select the size table you want (probably 1x1).
3. Right click the new table, select Table Properties, and make sure that:
   1. Specify Width and Specify Height are both un-checked (this will make the table hug the photo and caption)
   2. Float is set to Left or Right (not Default) so text will flow around it
   3. Border Size is where you want it - zero will make the table itself invisible (we usually use 1).
4. Insert the photo into your new table
5. Double-click the photo to bring up its properties and make sure it has no "wrapping style".  This will ensure that text appears under the photo, not to the side.
6. Make the table contents centered (select the whole table and click the Center button on the Formatting tool bar)
   1. We usually make our caption a smaller font - this is the time to do that - Font Size, 2 (10 pt)
7. Select the photo and press the right arrow once (so the photo is no longer selected) and
8. Hit shift-enter to generate a line-break (NOT a paragraph break).
9. Type in your caption (often the same as your ALT or TITLE tag).  It should appear centered just under the photo, with the rest of your text flowing around the outside of the table enclosing your photo and caption.
10. If your text is too long, the table itself will expand, making things look goofy.  To correct this, either add more shift-enter line breaks to put your text on successive lines, or go into Table Properties and make your table the same width as your picture.

  The code for our photos usually looks something like this:

<table border="1" id="table2" align="right">
  <tr>
    <td align="center"><font size="2">
      <a href="../images/Jonportrait_M.jpg">
        <img border="0" src="../images/Jonportrait.jpg" width="320" height="240"
          title="Click on the picture to see a larger version"
            alt="Jon Hacking - The grey in the beard is from raising teenagers..."></a><br>
    <b>Jon Hacking</b><br>
    The grey in my beard is from raising teenagers!</font></td>
  </tr>
</table>

Testing your site:

Before you publish, you should test your site to make sure everything works as you expect.  You'll feel really silly if you publish it and then find that it doesn't work the way you expected.  Ideally, you set up your own local web‑server and your own local network and test from a second computer on your network.  However, unless your site uses fancy server‑driven components (hit counters, comment pages, web components, etc.) this isn't really necessary.  Our website is fairly large, but actually doesn't have many fancy do-dads, so we just test on the same computer that we use to develop the site.

The easiest test is to have FrontPage recalculate all the hyperlinks (Tools, Recalculate Hyperlinks...).  This might take a few minutes on a big site.  Then look at the Reports page (View, Reports, Site Summary).  Pay special attention to the Unlinked files and the Broken hyperlinks reports - these should both be zero.  The Slow pages, Component errors and Uncompleted tasks reports should also be reviewed and corrected if necessary.  We also use Windows Explorer (or even FrontPage) to search through all of the HTML files looking for C:\ or D:\.  This may mean that we have an absolute link that refers directly to our hard drive, which is obviously an error.  All links should be relative to the page you're on, so the website will work no matter where it's hosted.

You should test using as many browsers as is practical.  Browsers all use different rendering engines, and so will display your site slightly differently.  We have no Apple or Unix computers on board Ocelot, so we're limited to Windows browsers (although we've made some modifications for Unix users).  However, Apples only account for 7% of our hits, and Unix is under 3%.  Of the Windows browsers, Internet Explorer and FireFox account for by far the most of our traffic, currently at 75% and 15% respectively, so those are what we test with (Netscape is under 1% so we don't bother).

We test all pages that have changed since our last update, with both FireFox and IE, paying special attention to new pages.  We do a copy-edit pass on the text to make sure it's correct.  We check each photo to make sure it has the right mouse-over text and blowup photo when it gets clicked on.  We check the flow of the text and photos (and anything else) as the browser window changes from minimum width (about 800 pixels) to full screen (1,440 pixels at present).  We also check the underlying HTML for formatting and errors like unclosed tags.  There may also be more specialized tests for special situations.

Once we publish, we run many of the same tests again to make sure everything went out OK.  Sometimes the Nav-bars don't publish correctly, but doing a Tools, Recalculate Hyperlinks on the live site usually repairs them.

Finding someone to Host your site:

A good Hosting company usually has lots of computers, power conditioning, air conditioning, maintenance personnel, support personnel, and several redundant connections to the Internet.  They typically charge 0-$200 per year to host a website on one of their computers, and this will usually include some email addresses as well.  They usually have several different plans for you to choose from (Small, Personal, Business, etc.).  You may also need to get a Domain Name (like HackingFamily.com or svOcelot.com).  This typically costs an additional $10/year and the hosting company can help show you how to select a name that's not already being used.

One of the advantages of having your own domain name is that it gives you a certain amount of independence, as you're not tied into a particular hosting company.  If you decide to change hosting companies at a later time, just copy your website to the new company, and they can handle the transition.  Once the Internet routers know your new location (which takes about a day) the old site can be turned off.  The whole operation should be transparent to the end user.

We originally used Parcom.net to host our website, but they've now moved on to other things.  They were a relatively small, family run business near Seattle and we've found them to be very competent, helpful and friendly.  We had a few hiccups over the years, but they're very responsive and always quick to sort the problems out.  I think they charged us ~$60/year, or a bit less if we get our payment in early.  Cheaper places exist, but you generally get what you pay for.

Publishing your Website:

If your hosting server is running some form of Windows (especially if the FrontPage Server Extensions are running) then publishing from FrontPage is extremely easy.  However, FrontPage can also publish to Unix servers, albeit somewhat more slowly.

1. Before you publish, make sure that:
   1. All your pages are saved.
   2. Your website has been thoroughly tested and copy-edited on your local machine.
   3. All of your links are relative.  You don't want to have an absolute link pointing to your own hard drive!
   4. You have no broken links.  Go to View, Reports, Site Summary.  Then go to Tools, Recalculate Hyperlinks (which can take a few minutes).  Make sure that broken hyperlinks is zero.
   5. If you have unverified hyperlinks, you might select that report and let FrontPage verify those links for you.
   6. Your computer is connected to the Internet, preferably over a high-speed connection.
   7. You know the username and password for publishing your site (provided by your Hosting company).
2. From FrontPage, click View, Remote Web Site.
3. If you haven't done this before, you will have to click Remote Website Properties in the upper right.
   1. Select the Remote Web Server Type - usually FrontPage (fast) or FTP (slow)
   2. Type in (or browse to) the Remote Website Location (ie, http://HackingFamily.com)
   3. Click OK to connect to your server.
4. You will usually be prompted for a username and password.  These should have been provided for you by your Hosting company.
5. FrontPage will connect to your Web Server and work out which files have been changed since the last time you published.  For a new website, this will, of course, be all of them.
   Note that this means that your computer's clock should be correct whenever you edit your website locally, as FrontPage uses the time-stamps on the files to determine which files should be updated.
6. Click Local to Remote in the lower right corner, and then Publish!  FrontPage might ask you some questions about deleting files that are no longer being used, but mostly things are fairly straight-forward.  A progress bar will eventually appear to let you know how long it will take.
7. We usually open our remote site in another FrontPage window (there's a special link for this) and then do a Recalculate Hyperlinks on the remote site, as this will also repair some internal links if necessary.
8. Once the publish has completed, open a browser to your remote website and verify that everything looks and acts as it's supposed to.  Congratulations!  You're now live on the web!

Jon's Pages: Up | Pre-History Stories | Contact Us | Brewing Beer | FrontPage 101 | FrontPage FAQs | Radio Email | Resume | Web Archives

Top Level: Home | Destinations | Cruising Info | Underwater | Boat Guests | Ocelot | Sue | Jon | Amanda | Chris | Site Map | Make a Comment

---

Lifetime Commodores of the Seven Seas Cruising Association

If our information is useful, you can help by making a donation

Copyright © 2000‑  Contact: Jon and Sue Hacking -- HackingFamily.com, svOcelot.com.  All rights reserved.