Construction Notes for gilbertmunger.org
Introduction
This website, devoted to Gilbert Munger and his paintings, went on-line in September of 1999. It was presented by the Tweed Museum of Art at the University of Minnesota Duluth. The Tweed owns the largest collection of Munger pictures. Gilbert Munger's brother Roger was of one of the founders of Duluth and there has always been interest in his artist brother there.
In November 2020 the site moved to its own URL: https://gilbertmunger.org. That URL has existed since 1999, but had been forwarded to the Tweed Museum site. Now the forwarding is reversed.
At its inception the website contained 170 pictures. Now it contains over 330. In addition, the amount of reference material has grown considerably, now including an archive of period documentation totaling more than 60,000 words.
The Plan
A primary consideration in the website's organization at the tools, code, and files level was ease of maintenance and additions. In 1998 I decided to use a database primarily to ease the burden of keeping the site up-to-date. My ideas was that just by adding the data associated with a new picture to the database, the necessary site updates could all be generated at the push of a button. This proved naive. In addition, I seriously underestimated the amount of work involved in entering the period documentation, which mostly end up being done by me typing them in from faded copies of old materials.
Sources of Information
The primary objective for the site is to collect as much information about Munger and his pictures as possible. The sources of information are:
- Searching the web -- There is an amazing amount of information there, that only needs to be collected and combined. Especially useful are the archives of period newspapers and periodicals, whose volume is growing by leaps and bounds as time goes by.
- Auction notification services -- Registering with various services notifies me of Munger paintings coming up for auction world-wide.
- The website itself -- People who have or discover Munger painting do a web search on "Gilbert Munger" and find this website. They email me and we exchange information.
- Old auction catalogs -- The folks at the auction houses are very helpful in providing copies of pages from old catalogs.
- Dealers, libraries, and historical societies -- They mostly are happy to help when you ask nicely. If it is a non-profit, be sure to offer a donation.
- Everyone listed in the Acknowledgments page and the Sources page.
Website Development Tools Used
| Windows 10 w/ big display | Development environment |
| Microsoft OneDrive | Cloud storage for the website under development |
| FreeFileSync | Application for mirroring the OneDive folders to a local backup file system |
| WinSCP | Application for synchronizing the development site to the production web server. |
| Photoshop | Application for image preparation |
| FileMakerPro | Database for recording the descriptions for the individual pictures in the catalog. Used to automatically generate the web page for each picture, the guide pages of thumbnail images for each locale, and the two indexes. Many of these will change when a new picture is added to the catalog. |
| EditPadPro & Notepad++ | Text editors for hand coding the other HTML pages and running editor macros over many pages. |
| Visual Studio Code | Developer workspace management tool, used for checking the validity of HTML code. |
Writing HTML files from FileMakerPro
The more than 300 ".html" files describing and indexing the individual pictures in the catalog are generated by FileMakerPro (FMP) scripts. The database contains a record for each picture in the catalog. The fields of each record describe the picture. An FMP script constructs an ".html" page from the record by concatenating values from record fields and various canned text strings into a single text field using the "InsertText" or "InsertCalculatedResult" script steps. The script then writes this constructed field to a file using the "ExportFieldContents" script step.
All versions of FMP write out text files using UTF-16 character encoding and a carriage return (CR) character for end-of-line (EOL). The Munger website uses UTF-8 encoding and uses CR followed by line feed (CR+LF) for EOL. Before version 16 there was no way to make FMP use a different encoding and EOL convention. The conversion needed to be done on each exported ".html" file with a text editor, an annoying extra step. Starting with version 16 of FMP, a new "Text Encode" function was included. It can be used in a script to convert to a text string to UTF-8 and CR+LF. Here is the script segment that creates the ".html" file for a picture from the constructed text field. The parameter "3" in "TextEncode" means use CR+LF.
UTF-8 Write ID Page to HTML File
Set Variable [
$filename; Value:"ID" &
Munger Database::Record ID &
".html"
]
Set Field [
Munger Database::PageContainer;
TextEncode (Munger Database::CSSWebPage ;
"UTF-8" ; 3)
]
Export Field Contents [
Munger Database::PageContainer;
“file:../MungerSite/Pages/$Filename”;
Create folders:No
]
A URL Surprise
I started developing this website 20 years ago. It wasn't until early 2019 that I learned URLs on **NIX web servers are case sensitive. Unfortunately, I used a lot of upper case in the folder and file names for this site. So when a user types a Munger Site URL into the address bar of a browser, they have to get the case of each letter in the URL correct, or the page will appear to be missing. I suppose that I could fix this with a week of work. There are a lot of Address Tags to fix, plus various scripts that generate web pages in FileMaker. That course also has the disadvantage that all the search results in search engine databases will stop working. It would take a while for the search engines to find the site elements under the new names.
It surprises me that there were not more prominent warning about this issue in 1999, or even today. Fortunately, the website is structured in a way that users almost never need to type in URLs. The developer and the Web Master, however, do need to be careful.
Getting Rid of HTML Frames.
The first edition of this website opened in 1999, several versions of HTML ago. The layout of the website is very simple: the constant-width "menu" box appears in column 1; the variable-width "content" box appears in column 2. The "menu" box is fixed into the upper left-hand corner of the website body and stays put as the "content" box is scrolled vertically or the loads different pages. For this simple layout, HTML Frames were the obvious method to use in 1999. But, HTML Frames turned out to have a lot of difficulties associated with them, as is explained at many places on the web.
With the introduction of HTML5/CSS, HTML Frames were deprecated, which means that support for them may disappear from web browsers in the future. So, as part of updating the Munger Site to modern HTML5/CSS, I decided to ditch the HTML Frames and use the new features of HTML5/CSS instead. Thus began my saga of many months.
HTML5/CSS has a lot of new functionally, in the form of "styles" and their attributes, that address layout and appearance. HTML Frames are replaced with "div"s (rectangular areas that enclose content) or related structures, and associated "style" code that describes how the "div"s function and relate. When used properly these new features eliminate most (all?) of the problems associated with HTML Frames.
- The menu and content boxes are the full height of the website body and collapse and expand vertically with the website body.
- The two boxes scroll independently if the website body is too short. There is never a scroll bar at the edge of the website body.
- The menu box has a fixed width and the content box has a maximum width (to preserve readability).
- The content box can be compressed a certain amount in width by making the website body narrower, i.e., by draging the right boundary of the browser window..
- The boxes have top and bottom padding so there is space above and below the displayed material.
- The "content" box retains its width when a new page is loaded into it, even if the new page renders naturally in less width.
The web is full of advice on how to achieve these effects, but most of them leave out one of the required properties or require the use of Java Script, which I didn't want. In many cases the suggested solution just didn't work as advertised. The essential problem is that the various CSS attributes controlling appearance and function of the two box interact in unexpected (and hard to learn about) ways. Here is the CSS/HTML that finally achieved these properties:
CSS styles
div.wrapper {
padding-top:20px;
padding-bottom:10px;
}
div.main{
font-size:120%;
max-width:1050px;
height:100vh;
background-color:#faefaa;
padding-left:30px;
padding-right:30px;
overflow-y:auto;
scrollbar-gutter:stable both-edges;
}
div.sidenav{
font-size:110%;
width:180px;
height:100vh;
float:left;
background-color:lightblue;
overflow-y:auto;
padding-left:10px;
padding-right:10px;
scrollbar-gutter:stable both-edges;
}
HTML for a website page
<html>
<body>
<div class="sidenav">
<div class="wrapper">
<!--html for the menu box -->
</div>
</div>
<div class="main">
<div class="wrapper">
<!--html for the content box -->
</div>
</div>
</body>
</html>
In these CSS style declarations div.sidenav is the menu box; div.main is the content box. They are both contained in the website body. Because of the "float:left" on div.sidenav it appears at the left edge of the viewport, and the div.main appears to its right. Because of the overflow-y properties, each div scrolls independently when needed. The div.wrapper is needed to make the scroll bars track properly when the top and bottom padding is added. The height property, rather than a min-height, is required to get the scrollbar attached to div.main rather than to the right edge of the browser window.
That leaves unsolved issue 6 from the list above. I could not find style attributes that addressed this that did not break the solutions to issues 1 through 5. The solution I found is to make sure every page to be displayed in the div.main has an in-line element, e.g., a paragraph, that can use the full max-width (or more). This element can and will wrap if it is too long for the current div.main width. Fortunately, in-line elements wider than div.main do not force it to widen when it has bee narrowed by the user.
You can see/try all these features on the page you are looking at now.
Getting rid of HTML Tables
The pages of the original version of this website were largely laid out using HTML Tables.
With HTML5/CSS, use of Tables for general formatting is advised against. Tables should be
used only for naturally tabular presentations (think spreadsheets). It has taken a while,
but the HTML Tables are pretty much now gone from this website.
Using <div>, <p>, <span> float, text-align, clear, etc, one
can obtain the same or better results. A good example is the More Artists "Munger"
page. Use 'View Source' in the browser to inspect the HTML.
The hardest conversion was the Document Archive page, which was laid out as a giant Table with dates in the left column and the entry texts in the right column. This wasted horizontal space and required a lot of superfluous HTML tags. I switched to using a "hanging indent" paragraph layout, in which line one that starts with the date for an entry is un-indented. This can be accomplished using negative indention as shown here:
CSS styles
div.period{
padding-left:30px;
}
p.item{
text-indent:-30px;
}
span.date{
font-weight:bold;
}
HTML for a period, item, date, and entry
<div class="period">
<p class="item">
<span class="date">1866 Aug 20 -- </span>
Munger resigns his army commission and
moves to New York City. ...
...
</p>
<p class="item">
...
</p>
</div>
Check out the result at the Document Archive page.
More to follow ...
Prev Next