Terry's Second Site Tips

Proofing Your Site

This page created 9 Nov 2014

Version note: Applies to Second Site 6 & 7

This article describes some techniques for easing the process of building, reviewing and editing your site. While building a basic site is simple, many users find they then want to spend some time either refining the appearance of their site, or modifying or correcting the data entered in TMG to produce the output that they desire.

Editing your site to produce the output you have in mind can require a lot of trial builds, depending on how fussy you are about the appearance of the site itself, how many people are included and how much data you are including about each, how particular you are about how that data is presented, and the extent of custom pages you are including. The following sections describe techniques I've found helpful to make this process go more quickly.

Refining the “Look” of the Site

Second Site includes a large number of options that allow you to modify the appearance of the site you create, and features that provide supplemental pages to add navigation tools such as indexes, charts, and search, and additional content, such as images and maps. Other articles in my Second Site Section cover various topics about using these features. Getting these tools set to produce exactly the site you envision may take a considerable number of trial runs, depending on how particular you are about the results. For each trial you use the Make Site command to build a new version of the site, review the results, and make adjustments to various settings to get exactly the result you desire. If your site includes a large number of people, or a large number of Exhibits or Images, the Make Site process can take more time than you would like.

The tips below can reduce the time it takes to make the trial runs for review after changing settings in Second Site. The techniques available depend on which aspect of the site you are working with:

• Changes to Styles Only – when you make changes to the Stylesheets section of Second Site to modify how particular aspects of your site appear, you can update the styles without re-making the entire site. Instead of using the Make Site command or button, press F2 to update just the styles. Then refresh the page in your browser to see the results. If you have made changes that will not be updated by pressing F2 the program will warn you that some changes will not be displayed.
• Editing Main Page and Custom Pages – when you are working with the content of the Main Page, or creating or modifying custom pages, you can tell Second Site to omit the Person Pages in your trial run by holding the Shift key while clicking the Make Site toolbar button or using the Make Site command. The site will be created with all pages except for the Person Pages. Note that some custom pages, such as charts or indexes, which include data for the people in the site, will either be empty or will not be created, so this technique does not work when working with those pages.
• Changes to the Person Pages – when you are testing features that require that the People Pages be created, such as changes to the Format or other parts of the Person Entry section, or those custom pages that require people be included, there are some techniques you can use to speed up the Make Site process:

• Include fewer people. Temporarily reduce the number of people in the site by use of a Flag. You may have a Flag in your Project that can be used to create a smaller test universe, or you could create a custom one. See my article on Controlling Who is Included for details on how to do this.
• If your site includes a large number of Exhibits that can considerably extend the Make Site process time, especially if they are large file. Temporarily disabling them in the Data > Exhibits section during the testing can help if you need to make a large number of test builds.

The following sections describe techniques that can help with the proofing of the data in the Person Pages.

Proofing the Person Pages

Most Second Site users quickly find that publishing their data in a website uncovers a variety of issues with their TMG data. These may include typing errors, data entered in the wrong places, inconsistencies in entering data, Sentences that don't produce the desired result, and many other issues. Correcting these issues requires reviewing a test build, editing the data in TMG, re-making the site with the corrected data, and reviewing the result. Depending on the data formats you are using, the extent of data recorded for each person, and your own standards, this can require a large number of build - edit - re-build cycles. The techniques described in this section can make that process go more quickly.

I have found two techniques that can speed up this process: 1) better coordinating the use of the Project files between TMG and Second Site, and 2) reducing the number of people in the site during proofing. They are discussed next.

Coordinating Use of the Project Files – We should first review the “rules” for how TMG and Second Site work together with the data files that make up your TMG Project. Each program must have exclusive access to the data files while it is actually working with those files. But that does not mean that only one of the two programs can be open at any one time. The requirements are:

• The Project must be closed in TMG when you open a site definition file (SDF) in Second Site.
• The Project must be closed in TMG when you specify or change the Database in the Data > Database section of Second Site.
• The Project must be closed in TMG when you use the “person” icons in Second Site to select a person, for example when choosing the subject person for a chart.
• The Project must be closed in TMG when you ask Second Site to Make Site, and cannot be opened in TMG until you click one of the three buttons at the bottom of the dialog that Second Site opens when the process is complete:

In short, one should close the Project in TMG, or TMG itself, when opening Second Site and when making adjustments to the overall site or to most custom pages.

However, when reviewing and editing the content of the TMG data as displayed on the Person Pages, much time can be saved by leaving TMG open. When reviewing the content of the Person Pages the Project can be open in TMG at any time except the Make Site process is actually running.

Note that in this discussion I said the Project must be closed. That does not generally mean that TMG itself has to be closed, but just the Project. Thus you do not generally have to wait for TMG to re-open to edit the data after reviewing a section of your site.

You can close and open your Project in TMG by use of the commands on the File menu, but I find it helpful to add buttons to my custom toolbar for that purpose. For a description of how to do that seem my Using Toolbars article. Specifically, I add two buttons:

• Close Project – a standard button found near the top of the “Unused buttons” list in the Custom Toolbar Manager. There is a custom button image that I use for this button available near the bottom of the article mentioned above.
• Load a Specific Project – is found near the bottom of the “Unused buttons” list in the Custom Toolbar Manager. When you create this button you have to specify the specific Project it is to open in the lower half of the Custom Toolbar Manager screen. There are standard button images for this button.

With these two buttons closing and then re-opening the Project in TMG each requires only a single click.

Reducing the Number of People – When a site has a small number people the Make Site process completes quite quickly, but as the number of people increase the process can take longer than seems convenient. Limiting the number of people in the site during proofing makes the build - edit - re-build cycle go more quickly. This can be done by using a Flag to temporarily limit the site to a small group you are editing. Just remember to reset the Flag setting before you build the final version.

My narrative site, as described in my article on Virtual Sub-Sites, uses custom Flags to define each family group. I find it works best for me to add a few people to the site at a time and proof their Person Pages. I do this by manually setting the family Flag for that group. During proofing I limit the site to people marked with that Flag. If you don't use such a Flag for your site you could accomplish the same thing with a temporary Flag you create for that purpose.

Keeping Track

If your site includes very many people it can be difficult to keep track of which people you have proofed. I have tested various methods of creating a checklist and have found a Descendant Indented Chart created in TMG to work best for me. For each group of people I want to add to my site I create a chart, as a word processor file. I then open it in my word processor and as I review each person listed I use the colored highlight feature in that program to mark those I decide to exclude (in red), those completed (in green) and those provisionally completed but needing more review (in yellow). Those not yet examined are left un-colored. An example is shown below:

I often include parents of spouses of descendants in my site, which are not included in the Descendant Indented Chart created by TMG. So I add them to the checklist manually.

For me it works best to add a small group of people to the site and review them, using the checklist as a guide. After proofing the text of the Person Page entry for a person I copy and paste it into my word processor to take advantage of its spelling and grammar checker to look for errors before marking the person's section complete on the checklist. After “approving” everyone in the small group I publish an update, as discussed next.

Publishing the Site

If you publish your site on the Internet you need to upload a new version after each update has been completed. In addition, since I am generally in the process of adding new people to my site, the copy currently in the '-o" folder is not the same as the version publicly available. I like to always have a copy of my published version available on my own computer, both so I can view it without going online and as a backup should something happen to the version on my web host's site.

Thus “publishing” an update requires updating both the version on my host and my local file copy. I've found ways to make that process very simple, as described below. As a result I find I post updates to my public website much more frequently than I did before.

Publishing Online – Updating the version on your web host requires uploading all the updated files, which can be numerous, to your host's server. That process is described in my article on Publishing Your Site. Since I've moved my site to John Cardinal's Family History Hosting service I have been able to use the Publish function in Second Site, which requires only a couple of mouse clicks to upload an updated version. I highly recommend John's service for those wishing to publish their sites online.

Creating a Local Copy – Copying all the files for your site to a separate location on your computer's hard drive isn't all that difficult. But after being able to use Second Site's two-click Publishing feature, the several steps required seemed comparatively complex, so I sought a simpler method. I've now developed the one described here, with aid from John Cardinal – thanks John. It involves the use of a “batch file,” which those who remember DOS computing may remember, and a little-noticed feature of Second Site to activate it within Second Site.

The batch file is pretty simple:

To create such a file, copy the text above into Notepad, edit the parts in red, and save the file with a convenient name and the extension “.bat” for “batch file.” The four parts you would want to edit, in the order they appear in red above, are:

1. The title that will appear in the title bar at the top of the window that opens when the batch file is used, as seen in the screenshot below. The text you use is unimportant – change it to anything that is meaningful to you.
2. The text of the “are you sure?” prompt, also visible in the screenshot below. You probably what to change “RR Narrative” to something that describes your site.
3. The folder where Second Site stores your output files, that is your “-o” folder. Change that to the correct path for your system.
4. The folder where you want your file copy kept. Change that to whatever location you want to use.

When run, the batch file first provides an “are you sure?” prompt:

To complete the copy operation type “y” and press enter. The copy operation will then run, copying any files that are newer than those in the destination folder. When done the window remains open until you press any key to close it.

By default the widow will have a black background with white text. You can set the colors, font, and window size by clicking on the icon at the upper left corner of the screen and selecting Properties.

The batch file could be just placed on the desktop or other convenient place and started by double-clicking on it. But it seems more convenient to have it associated with Second Site since that's what I use to publish my site to my host, and Second Site offers a tool to do that. I placed it in the External Commands section of the Utilities menu in Second Site:

Since I have two websites, a “narrative” one and an “outline” one, I created a batch file for each, and either can now be started from the Utilities menu in Second site.

The batch files, or any other executable program, are added to that menu by adding them to a 2ndsite.ini file, which must be located in your User Data File folder, or UDF. That folder is defined from the File > Preferences > Set user data folder menu. It is the folder in which “-i” and “-o” folders appear if you have defined a UDF. You can create the 2ndsite.ini file in Notepad, with text similar to this:

On the “Name” line(s) you would enter the text you want to appear on the menu.

On the “Doc” line(s) you would enter the name of your batch file. With no path included with the file name, as shown here, the batch file must be placed in the User Data Folder as well.

If you have previously created a 2ndsite.ini file for some other purpose, simply add this text to it.

With this addition, “publishing” a local file copy is as simple as publishing an update to my web host.

Copyright 2000- by Terry Reigel