New Look, Same Great Taste

I spent some of January rebuilding NeilAndGinger.com.  Seems a trivial task for a professional web developer to ‘redo’ a web site, but there was surprisingly a lot going on, so it took some time.  Here are some of the issues addressed and resolved:

Design

The old design just grew kinda ugly to me after all these years.  It had been the same since I originally built it in 2002, before we even got married.  It was too harsh and dark with the dark blue background, the bordering around the tables was kind of messy, the font was too small,  and the main content area was just too narrow.

I’m not a designer, so everything I do design-wise needs to be quite minimal or I’ll be in over my head in no time.  Fortunately it didn’t take too long for me to arrive at something I think looks decent, and I didn’t want to spend too much time fiddling with the look because I’d end up undoing what I did.  So now the design is (in my opinion) much cleaner with softer colors and a little more spread out without being too condensed.  Seems like the majority of people even with notebooks nowadays have displays wider than 1024px, so things can be spread out more and typically look better that way.

The whole design aspect of the project was an exercise in CSS.  I have a big style sheet that defines the styles of a slew of elements, both aesthetics and placement.  I became a big fan of nested tables many years ago and used to make everything with nested pages.  But now knowing about and gaining experience in using margin, padding, float, and display (among others) properties of the CSS definitions, it seems a better way to let the CSS place things rather than using a bunch of tables.  I can say that now that most browsers’ implementations treat the newer generations of HTML and JavaScript and CSS mostly the same way, so it’s not an insurmountable task to make a site look (almost) the same in all graphic user agents (browsers) and on all platforms.  As I got into it, I made it a personal challenge to do the whole site without using a single table.  And I did it!  If you find a table on neilandginger.com, I’ll give you $500.  No, not really.

Technology

I started by building a small template index.php file that just called functions that built the header, navigation, main content, footer, and other areas; these functions spit out snippets of HTML code that are mostly simple <div>s that are rendered as specified by the main referenced .css style sheet file.  When the basic look and feel was put together, I dumped in slightly-edited versions of the functions I already had from the old site – stuff that would suck out and display main page content and the news and contact sections from the already-existing MySQL database.

Pretty URLs

WordPress got me started thinking about the ‘best’ way for URLs to be presented.  There are several advantages to having the URL www.neilandginger.com/travel rather than www.neilandginger.com/?page=travel.  This was no trivial matter.  For a couple days, I read article after article about .htaccess and mod_rewrite, but nothing actually ended up working right till that one night I stayed up late and dreamt up a new plan.  It hit me what (I thought) actually goes on in WordPress’ URL rewriting mechanism – and I was right.  Being a programmer myself, I didn’t have to hack the WordPress include files to see how to do it – it was easy as pie once I confirmed what I was suspecting.  Mod-rewrite and .htaccess actually has very little to do with it: the only rewrite rules were that if the URL requested was neither a file nor a directory, one single control file was loaded (in my case, /index.php).  From there, index.php does all the work.  It takes a URL like “travel” and breaks it down into pieces separated by “?” – everything before the first “?” is the URL, and the rest starting with “?” is discarded.  Then what’s left is broken down into pieces separated by “/” – everything before the first “/” is the “page name” that it deals with, and the rest is discarded.  So it just looks up what’s in the database having this page name and displays the content (or some ‘not found’ stuff is there’s no such page name). A final nice touch is to force the “www” in case the user omitted it.

Photo Galleries

This took the most time.  I had developed a clunky photo gallery viewer years ago, which was a PHP script that I made pop up in its own browser window: JavaScript resized the browser window to a a size specified in height and width parameters, and PHP identified how many images there are in the directory specified by another parameter, displaying one of the images (specified in another parameter, or the first one if not specified), having little links to click on to display an image by number or previous, next, first, or last.  Also, a photo caption was read from a .txt file of the same base name in the same directory, is it existed.  The image was scaled down to a small size, not actually resampled to a thumbnail size, so the small image actually takes a little while to load.  Clicking on the small image would launch the full-sized image in another new window.  It was too easy to have a bunch of windows opened up, hidden behind other windows.  Like I said, “clunky”.

I had previously stumbled upon Lightbox and similar scripts to make image galleries pretty, so I figured I’d try out Lightbox.  Install and setup was surprisingly straightforward, quick, and painless.  But alas, there were some tweaks I really wanted to do, which proved to be quite the task.

I got some unsolicited but welcome feedback from someone who previewed it: “how am I supposed to know that I’m supposed to put my mouse over there to click to see the next picture?”  Yeah, I could see that someone looking at a Lightbox gallery with no experience would just see a pretty picture but then want to get rid of it without knowing what to do next.  So I wanted to make the Prev and Next always show up.  But that presented another problem: I didn’t want the Prev and Next to cover up part of the image, so I wanted them moved above or below the image.  Not only this, but when viewing an image more than about 800px tall gave me problems: it would be too tall to fit within my browser widow — my 1680×1050 resolution isn’t abnormally big, so I figured a lot of people would have the same problem.

All these issues taken together made me want to move the lightbox up to the top of the browser window and place the caption and Prev/Next all up at the top, so that in the case that an image was too tall, the user wouldn’t have to scroll down to get to the navigation.  The forums were somewhat helpful, guiding me toward solving a couple problems and giving me good info about the coding that was useful for figuring out some other stuff.  I had to make some trivial and non-trivial edits to the CSS and several spots in the lightbox.js file to accomplish all of this.  As with most projects of this sort, the reading and figuring out took more time than the actual edits.

I already had many directories of photos, having had assembled galleries from events and trips over the last few years.  And I would like to be able to build new galleries in the future simply by uploading photos and their caption files to a directory and pointing a script at this directory to build the gallery automatically.  So in my PHP file I wrote a couple of slick functions to take apart my proprietary <lightboxgallery> tag and build the gallery.  This way in my page content, I could just specify a tag like this:

<lightboxgallery dir="/photos/europe2006/8x6/2006-09-14" group="1" linktext="Photos from 14 Sep 2006"></lightboxgallery>

The functions read the directory and make a lightbox gallery grouping consisting of all of the images and caption files, making the link text the clickable link to view the gallery.  The stuff in the <lightboxgallery></lightboxgallery> tag is replaced by the HTML code that the functions generate, resulting in:

<a href="/photos/europe2006/8x6/2006-09-14/IMG_6157.JPG" rel="lightbox[1]" title="Caf&eacute; from which we got breakfast or a quick sandwich a few times.">View Photos from September 14</a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6158.JPG" rel="lightbox[1]" title="The bus to take us on our first castle tour in Bavaria (southern Germany)."></a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6159.JPG" rel="lightbox[1]" title=""></a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6160.JPG" rel="lightbox[1]" title="View of the Hauptbahnhof from the bus pick-up."></a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6161.JPG" rel="lightbox[1]" title="In the bus."></a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6163.JPG" rel="lightbox[1]" title="Munich traffic on the way out of town."></a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6164.JPG" rel="lightbox[1]" title="Some of the countryside as seen from the bus."></a>
<a href="/photos/europe2006/8x6/2006-09-14/IMG_6165.JPG" rel="lightbox[1]" title="Out on the autobahn."></a>
...

A little work up front to get this stuff in place one time will save hours of tedious link-making in the future!  All I have to do to make a gallery in the future is upload the photos to a directory, and make a <lightboxgallery> tag that points there.

More Image Stuff

I wanted to keep the scheme on our vacation pages of having thumbnail-ish images on the right side of the page instead of the common news and contact navigation.  So I spent a large amount of time (several two- or three- hour stretches) cropping and resizing photos, renaming, uploading, and editing the PHP functions that read them.

The Little Things

A lot of people do the big things right.  Sure, that’s OK, but the little things are often what separates the ordinary from the top-notch.  Here are little things that don’t make much difference to a site visitor but are just a little extra-special:

• I made a favicon.  Web sites are just better with favicons.
• The navigation links across the top of the page are actual anchor tags now.  Used to be, they were styled table cells where JavaScript gave them different colors via onMouseOver() and onMouseOut(), and the OnClick() fired a javascript:location to get the user to a new page.  It’s very unlikely that search engines will index a “link” like this.  Yes, I was ashamed of myself and eventually did it the right way.
• I am redirecting the old-style URLs to the new-style ones.  So if anyone happens upon an old-style URL like “neilandginger.com/?page=travel”, that’s redirected to “neilandginger.com/travel” (A 301 redirect, which tells the user agent that the content has moved permanently).  What difference does it make?  Not a whole lot on my litttle personal site, but search engines will update their indexes to the new URL (when they get around to it) – so it’s good to know for companies that want search results to index the proper pages as stuff gets moved around.
• If you go to “neilandginger.com” without the “www”, it will redirect sticking the “www” in there.  What difference does it make?  Not a whole lot on my litttle personal site,but some search engines are known to regard “neilandginger.com/europe2006” and “www.neilandginger.com/europe2006” as separate pages; if you’re a company concerned about search engine rankings, you may get penalized in this case for having “duplicate content”.
• Page titles are personalized by page.  So in your browser’s title bar of the home page, you see “Neil And Ginger »  Europe2006”, whereas on the Dogs page you see “Neil And Ginger » Throckmorton & Abby”.  Again, seems like a small deal for a personal site, but search engines like title tags that are relevant to the page content.
• The Contact Us page now has a little image with numbers in it (a “Captcha” type image), designed to ensure that a human is typing in the form rather than a bot submitting it.  The idea here is that a human can interpret the picture as having a number on a splotchy background, but a computer can’t.  This is not for your benefit – it’s for mine; since I kept getting spam posts, I thought I’d block them, even if it means a little extra typing for you.