| 1 | How do you plan for future expansion to keep things from being difficult, when you're not sure what you're doing, or exactly where you think you'll go with your site? I have some ideas, but things always change. |
| A | Yes, planning for future expansion is difficult. The trick is
when you want to start a new page (or even a new area) ask if this might
expand in the future, and if so, how. I started brewing beer in
Brisbane and decided to put up a page on it, but then I realized it
could grow so I put the new page in its own folder (which now has
several pages in it). With a bit of planning, you'll do better
than us. As of 2007 have 625 active pages and another 150 redirect
pages that we had to put in when we had to move things. See
FrontPage 101 for
more on this. |
| 2 | How do you make a hierarchy chart? |
| A | Page hierarchy is very important (IMHO) but pretty easy. You
do it under View, Navigation. There you can drag and
drop existing pages into your hierarchy, or even create new pages.
FrontPage will draw the chart for you, graphically. Note that new
pages are created in the root directory, so you'll probably want to move
them to more appropriate folders. You can also put pages in the hierarchy but keep them from showing up in Nav-bars (there's a button in the upper right corner, or you can right-click on the file). We put all our pages into the hierarchy somewhere but some of our maps don't show up on Nav-bars. Say, for example, you want to publish Newsletters. Put the parent page in a Newsletters folder. Folders under that can be date-based or location based (we use location). But pages put in those folders don't automatically show up in the hierarchy - they have to be placed correctly in the Navigation view. We started doing this, but after a while realized that our hierarchy was getting too flat (too many pages directly under Newsletters) which made our nav-bar too long. So we stuck in an extra layer of which Ocean we were in. This involved adding just 2 pages: Pacific Ocean Newsletters and Indian Ocean Newsletters (which reside in our Newsletters folder, alongside their parent Newsletters page). Our existing pages stayed in their folders - we just went to the Navigation view, added the 2 new Ocean pages, and rearranged all our existing pages into the new hierarchy under the Ocean pages as appropriate. See also: Hierarchical Pages. |
| 3 | Do you set your page size from the view menu or do you use a table width with percentage rather than fixed? I was thinking of using a table to constrain the page size to, say, 1,024 pixels and then using layers and CSS to work within that boundary. What is your opinion of that and/or how do you do it? What page size do you use? |
| A | We have decided not to set a page width. This
makes our life harder but we think it gives our viewers a better
experience. It means we have to adapt to (and test) all potential
screen (and window) sizes, which we obviously can't. We assume our
clients are using at least 800x600 displays, and we try to make our
pages look OK at up to about 1500 pixels wide. Wider than that and
some pictures will "catch" on others, making a bit of a mess (but all
data should still be displayed). We can do a fair amount by
enclosing both text and pictures in tables with
border="0"
width="100%".
Setting width to, say, 1024 will annoy folks with smaller windows
(they'll have to use the scroll bar at the bottom) as well as folks with
huge screens (because of the empty space on the sides) but will make
sure that your site will display correctly. This is a big subject,
so see also Page Width. |
| 4 | Is there a certain order of doing things that you would follow when building a site? |
| A | Another big question. Sometimes we write first and then look
for photos to illustrate, and sometimes we look for photos first and
write to expand or explain the photos. We usually copy an existing
page, rename and retitle it, include it in the navigation structure, and
then strip out the old stuff and start putting in the new. This
makes sure that the boiler-plate is all included (theme, headers,
footers, nav-bars, meta-tags, ICRA tags, etc) but it only works when you
have an existing good page to copy. |
| 5 | What page settings should I have enabled or not in all of the tabs? |
| A | We've generally gone with the defaults, but I don't like DIV tags so
we've taken them out. We don't use the auto-thumbnail feature (but
it would probably save time). Most of the site is in a Verdana or
Arial font, but that's decided by the Theme. Our server uses the
FrontPage Server Extensions so we get all that cruft. I've
programmed in some code snippets to make life easier (creating a parent,
sibling, or child nav-bar, and the
title="Click
on the picture to see a larger version" that goes on all our
photos). |
| 6 | I'm a little confused with the folder structure of parent and children pages. Do you consider any page that has children under it to be a parent page, so that you have many parent pages which end up being children under your Jon.htm page? |
| A | It's not what I consider. FrontPage considers
any page with children to be a parent of those children.
It may also be a sibling and/or a child of other pages. Look at it
from the page's perspective - below you've got your children, to the
sides you have your siblings, and above you have your parent.
Only the very bottom pages aren't parents.
However, this has nothing to do with folder structure
(although there's usually a casual relationship, more for our
benefit than for FrontPage). My
Brewing Beer page is the parent
of all of my beer-making pages, but it's in the ...\Jon\Brewing folder
just like its children. The
Fiji parent page is in the same
Fiji folder with all its children. But it doesn't have to
be. All those pages could be sprinkled in a dozen folders and made into
parents, siblings, and/or children in the Navigation view. But that would
be difficult to maintain, so we put related files together. See
also hierarchical pages. |
| 7 | Can you change the names of websites, files, and folders before and after you publish them? |
| A | You can certainly change whatever you want before you
publish. However, you should not change names of
anything after you publish. Even changing photo names (as we do
when we crop existing photos) can be a problem. Google and all the
other search engines will already have scooped them up and will send
folks to those old pages and photos. If you move or rename them,
the user will get 404 (page not found) errors and your site will get a bad
reputation. Over half of our visitors come from Google and the
other search engines, so this is a big deal. Those (150) times
we've had to move a page (mostly because we accidentally put a space
in the file or folder name) we've put a redirect page in the old
location that takes folks to the new location. See the
example on my
FrontPage 101 page. |
| 8 | How do you do folder lists or are they generated automatically as you create new ones? |
| A | We don't need folder lists. The user does not
know, nor need to know, where our files are located. The Nav-bars
(link-bars) that we have all over the site (left side and bottom of each
page) are based on page hierarchy in FrontPage,
not on folders or file location. Those Nav-bars are
auto generated by FrontPage: position your cursor where you want the Nav-bar
to appear and then do Insert, Navigation..., Link Bars,
Bar based on Navigation structure. This will bring up a wizard
allowing you to select the style, orientation (vertical or
horizontal), type (top, parent, sibling, children, etc) and other
attributes for those bars. We tend to enclose our vertical Nav-bars
in a table, and to shrink the font-size of our horizontal nav-bars. |
| 9 | Do you have to list and link all areas or headings before doing text? |
| A | Not at all. You can write text first and then add Nav-bars and
whatever other stuff you want. However, if you try to add a Nav-bar
(link-bar) that's based on Navigation structure before you position the
page in the Navigation hierarchy, FrontPage will complain. But you
certainly don't have to plan out your entire site before you start.
It's a good idea to give some serious thought to the
site structure, but
you can start writing pages one at a time if you want. |
| 10 | The book says to name a topic folder with the server's default home page. How do you find out what the servers default home page is, and is that what you do? |
| A | Your hosting company
will tell you what default home page name to use. Different
web servers use different default home page names, but it's programmable
so they can change it. When you go to
http://HackingFamily.com,
the server says to itself "this guy isn't
allowed to view the folder structure, which is really what he's asking
for, so I'll give him the default page for that location" which is named
index.htm for various historical reasons. Home.htm
(or *.html) is also common. But if you typed in
http://HackingFamily.com/Jon
it would look in the Jon folder and not find a "default" page, so
it would probably say something rude to you. Perhaps I should have
named Jon.htm "index.htm" and put it in the Jon folder
to solve this "problem" but I don't think many folks make that mistake.
The advice is probably good, but not really necessary for any except the
real home page. Go with index.htm and if the hosting
company you eventually go with wants it named something else, rename it
later (in FrontPage, so it will correct all the links!). |
| 11 | Do you use an editor and if so, which one, why, and how? |
| A | For the html we just use the editor built into FrontPage. For our
photos, we edit with a delightful bit of freeware called
IrfanView.
It crops, tilts, re-sizes, and adjusts colors and compression (file
size) quickly and easily, but can't edit just a section of a photo.
It's much faster than the big photo-editors, the learning
curve is much better than, say, PhotoShop, and it's free for
non-commercial use. Highly recommended. |
| 12 | Are you free to change pages in any way at a later time? |
| A | Yes, we are constantly changing old pages. We recently got rid
of many of the graphic buttons in favor of text nav-bars (to
improve performance). We also went through old pages cropping the
photos better and adding captions and larger photos that come up when
you click on the thumbnail. We always have an image of the website
on our local computer. We edit the pages on our computer and
FrontPage works out which pages have changed and just
uploads the
changed pages. Just don't change the name of any
files. |
| 13 | Does your website contain a blog or other website? It seems like that is done occasionally, and in fact we used to have a blog in ours but we didn't continue with it. Do you have any thoughts or ideas on that? I just don't know what is or isn't possible. What are some reasons for possibly having blogs or other websites within a website? I want to change what's on our blog a little also. Do you think that might be possible? |
| A | No, our Newsletters and Sue's logs are about as bloggish as we get. We can't upload very often, so blogs aren't very practical for us (or anyone cruising on a boat) but some boats try. Blogs weren't very popular when we left civilization in 2001, so we don't tend to think of them. You're right, if you have one, you need to continue with it, which can be difficult. If your old website is still active, FrontPage can suck it down to get the original text, or you can just copy it out of a browser. Changing old stuff is easy, especially if you're changing servers. Creating a blog in FrontPage is easy - just edit the blog page, putting your new stuff on top, and republish it. FrontPage gives you much more control than the automated blog sites. Since you're republishing the whole page, you can even go back and change previous postings, which you can't do very easily with most automated sites. But you're right, in any new programming endeavor, it's difficult to know what's possible. My advice: don't worry about it. Do what you can now and improve stuff as you learn. If you go back through our archives you'll see how primitive some of our early home pages were. Do you know enough to start doing what you want? If not, learn what you need to and then go for it. You'll make mistakes and the site will improve as you learn, but at least you'll have a framework to expand upon. |
| 14 | Do you test pages on your computer or an outside server? Can you explain what you use and why and how? |
| A | Yes, I'm a Software and Web Test (and Development) Engineer
(among other things) so I test our site
a lot. For less sophisticated websites, this can
usually be done right on your development computer without using a
server, but if you can then using a local server is better. Not using a
web-server means that server controls like hit counters,
comment pages, and some web components
won't work. We have no Apple(7%) or Unix(3%) computers and
Netscape(0.7%) isn't used much anymore, so we usually test with
Internet Explorer(75%) and FireFox(15%), which covers 90% of our hits. All browsers, including FireFox and IE, use slightly different rendering engines so they display web pages slightly differently. For instance, IE will display the text of an alt="blah" tag on mouse-over, but no other browser will. All browsers display the contents of a title="whatever" tag on mouse-over, but FrontPage makes you put a title tag in manually. We check all pages at minimum (800 pixel) and maximum (1440 pixel) width to see how the text and photos flow. We copy-edit the text and check the html to make sure it's OK (formatting, mostly, and checking that tags are closed). Doing Tools, Recalculate Hyperlinks and then checking all the Reports is essential before publishing. We also do a quick check of the live website immediately after publishing. See more on Testing on the FrontPage 101 page. |
| 15 | I don't understand the remote website feature. |
| A | The Remote Website view (View, Remote Website) is what
you use to publish your site. FrontPage will then attach to the
computer that's hosting your website but with write-permissions enabled,
so you can write to the server. This will require a user-name and
password, which your hosting
company will supply. FrontPage will communicate with
your server to determine which files have changed, so only those files
will be updated. Note that this means that your
computer's clock must be correct whenever you're editing your
website. You can also tweak your site from this view, but I don't
recommend that, as it means that the files on the server and the files
on your local computer will be out of sync. See
more on this on the
FrontPage 101 page. |
| 16 | Is the copyright notice that people put on their sites something official you have to apply for, or does everyone just put it there, and is it legal? |
| A | No, the copyright notice doesn't have to be applied for, but it is legal.
Just declaring that the site is copyrighted is usually enough these days. |
Jon's Pages:
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.
