Website Building - The Making of this Site
See also Site History—The iterations and variations of the site over the years
Creating and Editing Site Pages
Before anything can be uploaded, the webpages need to be created. Some web servers have site-building tools built in, but I won't delve into that here. There are two main ways of creating or editing a webpage before it's online: editing the code directly, or editing the page using a "WYSIWYG" program ("what you see is what you get") or software framework.
Direct Code Editing
I currently edit pages exclusively through the HTML, PHP and CSS code directly, and it's a good way to learn the basics behind a webpage. This method of building a website requires knowledge of the underlying code. The chief advantage of using this method over a WYSIWYG editor is that the resulting code is simpler and more elegant, allowing for easier editing and faster load times. It also allows for combining several languages together to create dynamic pages. However, creating the code for even basic operations such as text formatting or inserting an image can be time-consuming, and errors in the code can produce odd results. The flexibility of manual coding is often offset by time wasted in tracking down minor code errors or attempting to complete simple functions; I don't think I've ever written any code of consequence without having to go back and track down at least one or two errors.
A simple text editor, such as Notepad, is sufficient to edit the page code, but there are other programs (such as Notepad++) that offer syntax highlighting, which is immensely useful. Only the code is visible, without images or fonts, and a browser is necessary to view the page as it would appear online.
WYSIWYG HTML Editing
There are several programs available for WYSIWYG website creating. Until 2009 I used Netscape Composer, which came bundled with Netscape 4.7 and has long been obsolete. Other newer programs are available, and some word processing programs will work as well. The main advantage of this method is that the pages can be edited in a similar fashion to creating a word-processed document, so no knowledge of HTML code is necessary. The disadvantage, however, is that unnecessary "junk" HTML code will often make its way into the page, increasing load times and making it a hassle to edit the code later. MS Word is known to create enormous amounts of redundant code that may make a simple page ten times larger than necessary. Older programs may also insert HTML tags that are now deprecated.
My preferred method of editing the pages up to 2011 was a combination of manual and WYSIWYG editing. Many newer WYSIWYG editors allow instant switching between editing the page visually and editing the code, such as KompoZer (my replacement for Netscape Composer until switching entirely to manual code-editing). I edited the HTML and CSS code directly for tables and page layout, but typed paragraphs and edited headings using the WYSIWYG view.
A software framework refers to the use of ready-made code templates, compilers and libraries to achieve common functions, with the goal of allowing a greater focus on the "big picture" by reducing the time spent on low-level, technical programming details. Frameworks promote a building-block approach with reusable code, and can provide an interface to interact with the code indirectly (such as with WYSIWYG HTML editors). However, the use of frameworks often leads to "bloat" in the code due to the "one size fits all" approach to assembling the code. I don't use any external libraries or templates for this site—the closest I've come is to reuse many parts of my own code for similar functions on different pages.
Programming Languages - Static Pages
The most basic language used for websites is HTML, and it is sufficient for creating an interesting static web page. However, other languages can be used to create interactive and dynamic web pages, or even to reduce code clutter. The World Wide Web Consortium (W3C) has excellent tutorials that define web-based languages in detail.
For the first ten years of this site's existence, the sole language used for its creation was HTML (HyperText Markup Language). The language consists of tags intended to define the structure of pages, and browser interpretations of these tags tend to be very forgiving of errors. However, with the advent of the browser wars of the 1990s, many tags related to presentation and styles (some of them proprietary) made their way into the language. In an effort to separate style from presentation, these tags have since been made deprecated or obsolete, replaced by CSS. This has returned HTML back to its original function of defining only the page structure. Starting in 2009, this site was designed to meet HTML 4.01 Strict guidelines. In early 2013, I started making the few minor changes necessary to upgrade the site to HTML5, which at the time was not an official HTML specification but which was eventually finalized in late 2014.
CSS (Cascading Style Sheets) is a language designed to define the presentation of a web page. The power of CSS lies in its ability to remove the presentation information from the pages themselves, storing it instead in a single external stylesheet. As a result, one stylesheet can control the appearance of an entire website, making for a consistent appearance across all pages and incredibly easy presentation updates. Depending on the characteristics defined in the style sheet, two pages with exactly the same HTML code can have a vastly different appearance. This site has used a CSS style sheet since 2010, meaning that the pages themselves now contain little more than basic HTML code.
Programming Languages - Dynamic Pages
There are two ways of creating dynamic and interactive websites: through the browser (client) and through the server. Client-side languages require support from the browser, but allow for instant changes without reloading, while server-side languages can reliably create dynamic pages independently of the client.
PHP (PHP: Hypertext Preprocessor) was originally conceived for web development as a server-side language, but it has since been adopted as a general-purpose programming language. It follows C-style syntax and is broadly similar to other high level C-style languages, such as C++ and Java. On a web server, some of the functions made possible by PHP include creating HTML code, accessing a database, and inserting content from external files - which means frequently-used sections of code can be created with loops, functions or from external files, instead of being repeated on every page. Because it is processed at the server, it is not possible to read the underlying PHP code when viewing a page in a browser. When used in combination with SQL code designed to access a database, PHP can be used to present the results of a search.
This site makes extensive use of PHP for tasks such as accessing database tables of drawings and photos, printing automatic page update and statistical information, and even creating a rotating series of header images. Because common code sections are in separate external files (headers and menus for instance), the pages themselves contain little more than their own specific content, and maintenance requirements are vastly reduced. While PHP is very widespread, there are other server-side languages that can be used for many of the same tasks.
SQL is a language specifically designed for interacting with a database, and is structured to perform queries that access, insert or modify entries in a database. All the drawings and photos of this site (except for some old 1:55 drawings) are displayed using a database containing basic information about the locomotives or rolling stock (builder, model, dates etc.) and links to the associated images. While some general-purpose programming can be achieved with SQL, it is not well suited to tasks other than working with a database.
Here are a few things I've come across over the years of editing the site.
One of the challenges of writing code manually is ensuring that it is all valid, and different coding languages have different thresholds for errors. HTML tends to be very forgiving; for instance, a missing <tr> tag denoting a row in a table or a redundant </ul> tag closing a list will simply cause the page layout to be shifted slightly. However, PHP is generally intolerant of errors, breaking the page rendering if a single dot or semicolon is missing.
One reason I retain the HTML5 and CSS validation links at the bottom of the page is simply to make sure code updates are valid and older code is not deprecated. I end up correcting small errors revealed by the validation tests quite regularly. I also occasionally have to update bits of PHP code when my server (Bravenet) moves to a newer PHP standard, at which point a particular coding quirk (an error in my code that didn't previously cause an issue) is no longer supported.
When creating an HTML link, the full address of the link is necessary (complete with the "http://") unless the linked file is either in the same directory as the page, or in a subdirectory. I rarely used the full URL for links on this site as files are all contained in either the main directory or a subdirectory, and in 2022 I removed any remaining "http://" links when I added an SSL certificate, which changed the URL by default to "https://".
Some servers are case-senstitive and won't recognize links if only one letter is incorrect. It's a good idea to develop a pattern for filenames, including consistency in the filename extensions.
Bitmap images are not suited to being displayed on a website, as I learned in the very early days of website building. All the images on this site are either GIF, PNG (both for drawings) or JPG (for photos).
Load times can be excessive when many large images are displayed on a single page, regardless of how the image is scaled on the page. Therefore, for displaying thumbnails, separate scaled image files should always be used. The full-size photos on this site are 1,000 to 3,000 KB, compared to 20 to 40 KB for the smaller versions. While some photo sites have automatic thumbnail generation, I've uploaded all my smaller photos as separate files. The amount of time and space they require is trivial, and having them as separate files cuts down on the processing power needed at the server. In the past, I used three sizes of photos (large, medium and thumbnail) but I've since downsized the medium photos to double as thumbnails, which significantly reduced space usage at a slight cost to bandwidth.
I've always tried to follow common conventions in web navigation, such as making all parts of the site accessible from each other, and not having content buried behind too many layers of links. When I converted all the site pages to a PHP format in 2009, it greatly facilitated making a uniform and easily updated navigation system since all the elements of the menus were now contained in single files independent of the pages themselves. I've also cross-referenced various pages, such as linking drawings with locomotive phases or photos with locomotive dimensions. While early versions of the site placed all navigation along the top, the PHP version follows an "F-layout" format with content in the left column and site/contact information along the top.
I've found that the best way to refine a site's navigation is to use it extensively - which I do. The Photos section of this site is actually the easiest way for me to find my own photos for reference for making drawings, and it's through performing countless searches that I've settled on the current interface and search options.
Many websites starting around 2010-2015 developed a "mobile-first" interface, employing a minimalist appearance and large navigation buttons even when viewed on a desktop. By contrast, this site has always followed a desktop-first design, partly because my own web use is almost exclusively on a desktop (on which I find mobile-optimized websites can be very user-unfriendly) and partly because most of the content of this site - wide tables with many links and lots of data - simply cannot be shrunk for smaller screens. Nonetheless, in 2019 I created a responsive page layout that altered the page proportions or relocated the menu links depending on the screen resolution.
Hosting the Website
There are many existing servers available to host web sites. Host packages can either be free or require payment (usually $4 to $10 a month). While there are many good free web hosts out there, there are often serious restrictions, such as banner ads or limitations on file size and bandwidth. I've been hosting Trainiax using a paid account with Bravenet since 2005, and I've been satisfied with their decent hosting terms, prompt communication, solid uptime and rich feature set.
The alternative to signing up for an existing hosting package is to buy or build a personal server. In this case, the major cost is in the initial expense rather than in the monthly or yearly payments with an online hosting package. A purpose-built server can provide greater flexibility than an online hosting package, but (depending on the system) it may not offer the advantage of having files stored off-site.
Trainiax has been designed to conform with the following standards:
I also attempted to reduce load times by testing various pages with the Web Bloat Score Calculator. The score compares the size of the page (including all code and images) compared to the equivalent size of a screenshot of the page. A score greater than 1 suggests the page is potentially "bloated". For what it's worth, with a bit of tinkering I've managed to get most pages on this site below a score of 1 and under 1 MB in size.