Building the Site


The Sumida Crossing website was originally (2009) built using iWeb and Apple's Mobile Me service. In 2011, after several years of minimal enhancement to the software, Apple declared iWeb obsolete and announced its intention to shut down their hosting service in 2012. I went looking for new software, as well as a new hosting provider. The result is the site you see today.

I've tested this site with Firefox and Safari on a Mac, Safari on an iPad, and IE8 running on Windows XP SP3. I mostly use Firefox, so that's had the most checking. Also, IE7 and IE6 are both obsolete and known to have problems with modern website design. If you use a PC, you really owe it to yourself to use something better. I make no attempt to be compatible with IE versions prior to IE8, in part because that's the oldest version I have now. Buf if you encounter problems viewing it with any browser, drop me an email using the address on the About This Site page.

I haven’t tested the site on small-screen mobile devices, and it isn’t really intended for viewing on a small screen so it probably won’t work very well there. Something with zoom capability like an iPhone might be usable (and since the iPad works, the iPhone likely will, too).


Design Philosophy


I'm not a web designer. My goal here is to present information about my model railroad, and to collect information about the prototype trains that I can use as a reference, as well as to keep notes about other things I've done related to the model railroad, such as evaluations of model train motor designs or the kinds of track arrangements possible with Kato Unitrack.

The website is a tool for that, and its objective is simply to present information in a readable format, where there is an obvious organization that makes it easy to find things (that's the aspect I fall down on most often). And to do that without taking copious amounts of my time. I'm striving for a Zen simplicity here, which is appropriate given the subject country. Functional minimalism, in a nutshell.

Life rarely cooperates with what we want, and the site is no exception. I spent considerably more time on the nuts-and-bolts details than I wanted when moving off iWeb, although after about six months things settled down. The plus side is that the site more accurately reflects what I wanted to provide in the first place. The negative side is that time spent on it was time not spent modeling. Still, I can’t say it was time badly spent since I got something I wanted out of it. And it has worked reliably and without significant intervention for more than five years now. I’ll share here some of those nuts and bolts, and lessons learned, in case you’re considering something similar.


Sumida Crossing 2.0


What I liked about iWeb was that it was a true What You See Is What You Get (WYSIWYG) editor, and working on web pages was nearly as easy as writing a document in a word processor. It was also as stable and easy to use as is most Apple software. What I didn't like about it was that, due to its focus on being easy to use and obvious, and Apple's mania for controlling and simplifying the user experience, when you ran into one of its limits, there wasn't much you could do. And limits it had: make a page too big, and the editor slowed to a glacial pace. Want to link to a photo in an album? Nearly impossible and easily broken. Want to link to the middle of a page? Possible, but extremely awkward. Want an RSS feed for something other than the blog or photo album? Not supported. Want to customize a template so you didn't have to change the font on every page? Very, very, hard to do.

So when it came time to look for a replacement, I wasn't exactly heartbroken to leave iWeb behind. I did want to keep as much of the ease-of-use that I could, but at the same time I wanted an extensible, flexible, tool. And I found it, I think, in RapidWeaver (I've hit a few rough patches, but worked through most of them).

RapidWeaver isn't really WYSIWYG, as you enter and edit simple text, and then switch to a preview mode to see how it looks when the formatting applies (and sometimes that's not at all as expected). But it's close. One big flaw is that it's lacking in page-layout capabilities, something they expect you to use third-party tools for.

There’s a particularly rich set of these called "Stacks" (from YourHead.com) that work as a page type; just create your pages as "Stacks" pages, then build blocks of text, images, tables, and other things by dragging and dropping individual page components into place. You have to buy the core "Stacks" extension, and then pay for additional plug-ins (generically called "stacks", confusingly enough) although there are a number of free ones (I used some from ThemeFlood and philwarrnder.com). However, in practice Stacks turned out to be unsuitable, and I converted all my Stacks pages back to standard RapidWeaver “Styled Text” pages (which was far too much work). For details see the section on it further down the page.

I'm also using YourHead's Collage2 for the photo albums. It hasn’t caused me any problems aside from being glacially slow to export, so I used it for many years. It allows more control over the size of stored and downloadable images (which I limit to 800 pixels in the longest dimension for page-formatting reasons). However, it is very limited in some ways, and as mentioned is incredibly slow to export, taking over 20 minutes with my current set of albums, and very inefficient of file space. So I’m gradually moving off of it to a simplified format using basic HTML/CSS that allows posting larger images, but lacks the neat slide-show capability.

With RapidWeaver the site appearance is highly customizable. You can buy "themes" that set the general appearance of pages, and there are a number of free ones. Or, if you want to get your hands dirty with HTML and CSS, you can easily customize one of the free themes to get what you want, which is what I did (I started with a theme called "Delta", but there isn't much left of it at this point).

Note: Some parts of RapidWeaver appear to depend on Javascript (not Java) which is a simple language used for programs that execute within the user's browser, and are generally limited to manipulating things within the browser. I’m also using this to format the menu on the left side of the page. Javascript-using pages are pretty common across the Web, but because there's the potential for bugs in Javascript to permit access to things they shouldn't (and there have been such in the past), some people like to turn off Javascript. That can break a lot of websites, and mine won't display correctly without it, although most of it should work as I’ve tried to make the parts I can control fail-safe (I’m doubtful of the Collage2 photo albums). Just so you know.


Issues with Stacks


Note: this description pertains to Stacks as of 2010. I haven’t used it since then, and can’t comment on later changes.

Stacks is a very nice add-on to RapidWeaver. If you want to do page layout, it gives you great flexibility for that, and it's extensible in all sorts of useful ways. Unfortunately it's a flawed implementation, and for me the flaws are fatal. Attempting to use it created a RapidWeaver site that was too large for the 32-bit memory space that RW is limited to, causing all sorts of instability. If RW is ever converted to a 64-bit application, or if Stacks is cleaned up, I'd love to use it. But as it stands I ended up converting my Stacks pages back to the standard Styled Text format, which works a whole lot better.

The fundamental problem appears to be a memory leak when the site is exported, causing memory in use to grow until it hits the limit, at which point crashes result. With about 100 MB of exported website, I hit the limit and even one export was right on the border. Various band-aids to limit the problem were applied at that point, while I looked into the solution. Testing with a dummy site showed that the problem didn’t exist if I put content on a normal Styled Text page, but did if I used Stacks, thus it’s not a general RW bug, but a Stacks bug. And from one of their blog postings, they’re aware of the size issue (the guidance provided amounts to “your site shouldn’t be that big” or “do workarounds”, so I don’t think they’re in a hurry to fix it).

Part of the issue appears to be the inefficient way it stores images. A page of 14 images that published occupies 487 KB requires 14.3 MB (yes thirty times the space) in the master copy. Converting that page to Styled Text drops the space requirement to 4.8 MB, and using Normalize Images on that (which only works on Styled Text) drops the requirement to 651 KB.

It's storing images as encoded data in the page source. This is what RW does too; and that's an odd thing to do because both actually export them to separate files in the published site; this is probably done to allow the inline image manipulation, but it means that the whole image needs to be re-processed when it's published, which is hugely inefficient and one reason export of a large site is so slow. They should at least have cached a post-processed "content" section, so they didn't need to reprocess the whole page just because the navigation sidebar changed.

As it stands today (2010), Stacks isn't a good choice for a website with lots of inline image use (i.e., for the tutorials and multimedia reference pages that make up most of my site).

Another problem is that Stacks has an enhanced form of a bug that also affects RW. Both are easily confused if you paste in formatted text. You really need to paste everything using the "Paste as Plain Text" command, but that's not the default for Command-V, which makes it a nuisance to remember. This was particularly problematic in the conversion from iWeb, where I had to paste the contents of over 100 pages, often one paragraph at a time. Both also, for reasons that aren't clear, get confused if you paste in non-roman characters (like Japanese) even as plain text. It displays the character right, but then changes to a courier-like font for the remainder of the pasted text. In RW it fixes the problem at the next sentence break. But in stacks, it affects the whole section of text (up to a stack end).

However if you paste all text other than Japanese as plain text, then paste the individual Japanese words into the middle of the existing text (also done as plain text) it displays just fine. Really odd. I could work around this one, and did until I hit the memory problem.

Stacks also has a problem with bulleted lists, for some reason indenting the second and subsequent bullets relative to the first one, unless a non-bulleted line was placed between them. RW has some issues here too, but you can work around those by converting text to non-bulleted and back when they occur, which you can’t do with Stacks.


Hosting


For the curious, I'm presently hosting this site on Little Oak, a small but apparently well-regarded hosting company located in California. They use Apache on a linux host, which is what I was looking for (if you hadn't guessed, I'm a fan of Unix/Linux and open-source in addition to liking Apple). I'd looked at several other providers, but each had one thing or another that I didn't like about them. So far I'm fairly pleased. Their documentation is rather poor, but the one initial problem I had was solved in real time with a live chat to their support group. And they have been incredibly reliable.

I’ve now been using them for five years (as of 2016), and things have been exactly as I hoped. Their servers just work. Outages have been few and far between. So far, I’m a very, very satisfied customer.


Image Processing


My photos of the model railroad were taken with a digital camera (several different models over the years) in RAW mode and processed using software (originally Aperture, now Capture One Pro) to adjust exposure and "white balance" (correcting colors for the lighting used). Software is also used to straighten and crop photos or otherwise modify as needed. JPEGs were then exported for use in RapidWeaver. In some cases, Adobe Photoshop Elements was just for further editing. RapidWeaver does its own processing to shrink these full-size images down to the size used on the website. One downside to the Collage2 photo albums is that you can't save a larger image than is displayed in the pop-up, which I've set to 800 pixels to fit my intended minimum page width of 1000 pixels. The new-format photo albums will correct this, and allow larger photos to be displayed.

One thing I've discovered is that it's a bad idea to use an image much larger than needed with RapidWeaver as it just burns memory. Rather than predict exactly the size though, I just created an export profile limiting the image size to a bit larger than needed (my largest images on most pages are around 650 pixels wide, aside from the 800 pixel images used in photo albums). When creating a new page I use those images until I've got everything on that page done and sized the way I want, then I then use RW’s Normalize Images function to remove unnecessary bits from the master database. I keep a file copy of the image outside RW, so if I want a larger one I can always reload it manually. And the master image remains in my photo library should I ever need a really big copy.

Images processed through RW also have all of their metadata stripped. That really annoys me, as at least the basic Exif data ought to be left intact when resizing an image (as should IPTC data such as the photographer name, copyright notice, etc).

Third-party images I include are similarly resized (and have any metadata they might have had removed by RW before you see them; this annoys me). One reason I make those images clickable is so that you can get the original if you want a pristine copy with the full size and metadata intact. That only works, of course, as long as the original source leaves the image online. Once they remove theirs, all I have is the stripped-down and resized copy (well, I keep a full copy for future editing, but not online).


Characters


I mentioned Japanese text earlier. I can include that because this site uses UTF8 character encoding. That’s a method for encoding Unicode characters in multiple bytes, and Unicode can include Japanese (and, in theory, characters for every other language on earth, assuming your computer has the information needed to display them). UTF8 is something of a baseline standard for the Internet now, replacing (and including) the older 7-bit ASCII characters for Roman languages (the first 127 characters of UTF8 are identical to the ASCII set). Every page output identifies itself as UTF8, so every modern browser should display this correctly if your computer is capable of it. If you don’t have the right fonts installed, however, the character codes won’t be displayed properly.

There are a number of other character encodings in use for Japanese web pages which pre-date UTF8. In theory this shouldn’t present a problem for readers regardless of their browser, as they should all recognize and honor the UTF8 encoding when displaying my pages. But I don’t have a Japanese computer to test with, so I don’t know what the site looks like (I do seem to have some Japanese readers, so it’s at least partially legible for some).

This, by the way, is one reason Western browsers displaying Japanese sites often don’t display the characters there correctly. Many Japanese websites don’t identify their encoding, and assume the viewer is using the Japanese version of the IE browser, which will default to one of the historic Japanese character encodings. Western browsers will either default to a national character set, or to UTF8, neither of which is going to be right for a Japanese encoding. It’s a shortcut that may well cause problems even for Japanese users, but certainly does for the rest of us.


RSS Feeds


The RSS feed for the blog is created automatically by RW. But I also wanted a feed describing changes to other parts of the site. iWeb had one for the photo albums, but not a general one. RW doesn’t provide for other feeds either, so I ended up turning to a third-party tool. There are a number of scripts out there that will generate feeds on the fly, but that’s a lot of unnecessary server-side processing in my view (I’m big on efficiency and speed). And I didn’t want pages showing up in the feed each time I fixed a spelling error or similar, but only when I really made a significant change. So I went with a tool that creates an RSS feed file manually. I tell it what title, URL, and any classification tags, and enter some text, then save the file and FTP it to my website. The tool I’m using is a commercial program for the Mac called Feeder, by Reinvented Software. It’s pricy for what you get (and I don’t use all of its features), but it seems to work pretty well.


Blog Comments


When I switched from iWeb I didn’t have a blog comments system. So I wrote my own. I thought it would be easy (how hard can a list of comments be?), but it took six months. That was the last major investment of my time in the website, as opposed to the content of the website. I do think it was worthwhile, although if I’d known it would be that much work, I’d have done something else.

The problem was that RW did not provide a built-in comments system with its default blog page style, but only integration with three comment services. And two of the three were owned by one company, which had eliminated its free service (something I could live with if it worked well), and didn’t have a reputation for providing good service or support, while the third seems intent on a business model based on using the comments as part of a larger social-networking environment. And they force people to “opt in” to their data-collection and tracking policies (how is it “opt in” if they cancel your account if you don’t?). I was having no part of that.

I could have used a WordPress install (native WordPress, not the WordPress service) as my blog section to provide both pages and comments, but that seemed to be swatting flies with a hammer for what my blog needs to do. I’ll admit, if I had it all to do over, that’s probably the route I’d take. But it took me the better part of two months to convert all the old iWeb blog posts to RW, I’m not about to spend a similar amount of time converting them to WP now.

So I was left with having to roll my own. My hosting provider provides pre-installed PHP and MySQL, so all I needed were some PHP scripts to create and display posts using a MySQL database. There are a number of those floating around the web, with varying degrees of completeness, complexity and support. At first I thought I’d use one of those, perhaps with some customization. But a little examination showed that these were a bit too simplistic, and among other things didn’t do a good job of handling multi-byte characters (and a UTF8-encoded site that doesn’t account for multibyte characters is at risk of certain kinds of attacks). And besides, there’s likely going to be good reason for someone to paste a Japanese name or phrase into my comments, so I need to support that. In the end, I wrote my own, in far too much PHP, with a MySQL database for the actual comments, which turned out to be a lot more work than I anticipated. Using WordPress would have been much less work. But it works, and that’s all that really matters.