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:
|Planning your site||A somewhat Faster way to Add a New Page|
|Understanding Hierarchical Pages||Some miscellaneous Notes|
|Graphic (vs. Text) Buttons||Thoughts on adding Photos and Graphic files|
|Some General Rules to look out for||Adding Mouse-over Text to your Pictures|
|Non-Breaking Characters||Adding Captions under photos|
|Do you want a fixed or flowing Page Width||Testing your website|
|Starting a New Website||Finding a Web Hosting company|
|Adding a New Page to an existing website||Publishing your finished website|
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!
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
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
|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.|
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.
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.
To build a fixed-width site with text like this paragraph, just enclose all your content in a table with the width set to some number of pixels. If you make your table have zero width borders, then the table itself will be invisible. The code for this is easy:
Simple, and your visitors will always see the same thing you do, as long as their window is wider than your width= parameter. But there's a lot of wasted space on the sides, and your pages end up being long and skinny.
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):
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):
A somewhat faster way to add a page, for the more experienced:
|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:
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.
To turn the ALT tag you just created into a TITLE tag, FrontPage makes you edit the HTML (don't be scared here).
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)
The code for our photos usually looks something like this:
<table border="1" id="table2" align="right">
<td align="center"><font size="2">
<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>
The grey in my beard is from raising teenagers!</font></td>
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.
Top Level: Home | Destinations | Cruising Info | Underwater | Boat Guests | Ocelot | Sue | Jon | Amanda | Chris | Site Map | Make a Comment
|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.