Our Story

FYI, the site is doing that weird thing where it won’t rebuild pages. Ugh. Comments will probably not work for a little while.

Update: Okay, I’ve resolved the issue for now. The problem was an apparant issue with the use of the MTRegex tag in one of the PHP Juice comments. I’ve modified the comment, but am going to check with Brad Choate (regular expression Jedi master) to see what the problem actually was. More details later.

Non-Update: Never did quite figure out what happened. Brad had thought that the problem was in the MT Macros code that I have employed on the site rather than the MTRegex code. Whatever it was, a word of wisdom: if your site is taking forever to build, before going through and rebuilding the site from scratch, try to figure out what might have changed recently (added comments, changed markup, new plugin). It might just save you a few hours of downtime.

As Jai noted, I’ve switched the site over to PHP. That’s not the only thing I got done today.

Mark Pilgrim recently wrote another reminder that gzip-compressing web pages can save you some serious bandwidth. Unfortunately, this requires some magic with Apache which I can’t seem to cast. However, Dean Allen pointed out that you can use a PHP function to gzip-compress your site on the fly. Gzip compression is supported by pretty much all modern browsers that matter (ones that don’t support it are given a regular uncompressed web page, anyway) and can reduce your bandwidth by half. Spiff.

Speaking of Dean, his Refer tracker runs on PHP as well. In order for it to track page hits, though, you have to have a PHP tag in each of your documents. This isn’t a big deal with MT templates, but, in order to get it to work with my site, I either had to override my .htaccess file to process HTML files as PHP, or migrate to PHP entirely. I’m not allowed to modify .htaccess files with my web host, so that leaves me with the inevitable choice to migrate. It took about a half-hour to pound out all of the details. The end-result is visible over here.

The new URLs were an inevitable conclusion of moving to PHP. I mean, if I’m going to change my URL structure, may as well go all out, right? In particular, I wanted to future-proof the URL structure from any future changes I might make to the site (like if I ported over ASP.Net or something–gack!). A search for future-proofing URLs in Movable Type brought me to M�r �rlygsson’s helpful tutorial.

Finally, being a good netizen, I wanted to make sure all of my old inbound links still make it to their original content. I mean, not like I have a lot of them, so the ones that I do have I don’t want to disappoint. What I did to solve this is create another Individual Archive simply called “Boing.” It uses the old URL structure (<$MTEntryID pad="1"$>.shtml) to create a page which then redirects the user to the new page with this meta tag:

<meta http-equiv="Refresh" content="0; URL=/archives/<$MTArchiveDate format="%Y/%m/%d"$>/<$MTEntryTitle dirify="1"$>/">

I thought about making this a temporary fix, removing it after about a year or so, but it’s relatively harmless in terms of disk space and just maintains itself. I mean, a couple hundred bytes of data per entry and it keeps Our Story from massive link rot.

All that being said, though, a big part of the reason I switched to PHP was that I want to get back into some sort of development again. Web sites and databases are pretty much all I get to work with these days, so I thought, “why not?” Make Our Story PHP-based and mess around and have fun. Who knows? Maybe I might even end up coding the Ironworks web portal by hand.

In part because they’ll make a great backup the next time I accidentally overwrite my Individual Archive Template with my Default Search Template in the middle of the night, but mostly because I’m all about open source: the index and archive templates that power Our Story can now be found here.

Okay, as far as I can figure out from this, any time you have an position: relative; outer element that wraps a position: absolute; inner element, then that inner element should find its offset relative to the outer element. Or something.

The outer element looks like this:

#content {
   position: relative;
   clear: both;
   border-left: 1px solid gray;
   border-right: 1px solid gray;
   margin: 0px 35px;
   padding: 0px;
}

Again, the idea is that when I wrap this around an inner element that is positioned absolutely, any offset I use for the inner element should happen relative to the outer element. So, if I set top: 0px; in the inner element, it should position itself at the top of the outer element rather than the page itself. This works in all the browsers I’ve tested.

What doesn’t work is when I set right: 0px; in the inner element. Opera and Mozilla think that should be relative to the outer element. IE thinks it should relative to the page. I’m guessing by a vote of 2-to-1 that IE is wrong.

I tried to think hard of how to do this without using CSS hacks, but came to the inevitable conclusion that I had to hack the stylesheet. After consulting this page, I came up with this code for the inner element:

#right-column {
   position: absolute;
   top: 0px;
   margin: 10px 0px 0px 0px;
   padding: 10px 5px 5px 5px;
   width: 220px;
   right: 36px; /* IE5 off-by-one to the R */
   voice-family: ""}""; /* Hide from IE5 */
   voice-family:inherit;
   right: 35px;
   right /**/: 0px; /* Hide from IE6 and correct margin */
}

The first hack, voice-family: ""}""; hides anything after that from IE5. Not surprisingly, the IE5 representation actually suffers from two bugs: the right margin thing as well as an off-by-one pixel error. Whee. So, I had to set another margin: 35px; after that to make it look right in IE6. After that was all said and done, I could finally set the margin back to what it was supposed to be and hide it from IE6 with right /**/: 0px;. As many have said before me, this CSS stuff is hard.

IE5 is still acting up quite a bit with my new menu on the top right of the screen, so more bug fixes will be forthcoming.

Good News: I was able to create a site menu using an unordered list with the great help of this column at A List Apart. Right now there’s a whopping two items, but plenty of room for expansion.

Bad News: IE6 doesn’t like my layout. If you’re looking at the site in IE, you’ll notice that the sidebar is conspicuously hugging the right side of the screen. This is because IE does not correctly interpret a right: 0px; inside of a div with position: relative; margin: 0px 35px;. The reason this sucks is that I want to have a gray line that traces from the menu all the way down to the footer–like it does on the left side of the page. But, since Explorer doesn’t interpret the CSS correctly, the sidebar ends up overlapping any line I try to put over there. Any feedback is appreciated.

Kalsey Consulting Group: SimpleComments.

TrackBacks are comments. They are comments left on someone else�s site rather than your own, but they are comments nonetheless. Movable Type makes a distinction between entry comments and TrackBacks that seems artificial, and it made more sense to me to have TrackBack ping data appear within the comments portion of a Movable Type site.

SimpleComments is a new plugin that will let you do just this. Comments and Trackbacks are merged into a single list. Comment counts include the number of TrackBack pings, and best of all, you don�t need to learn new MT tags in order to do this.

Free your mind.

Design cues by Dave and Doug have helped make this site a bit easier to read. I know a lot of you had to sort of squint at the three-column layout in 800×600 (Mom, Mom-in-law, Jaime-at-work, to name a few…)–especially when I prattle on and on without using extended entry. Hopefully the new two-column thing will help!

Also, just in time to answer my questions about sub-site design, Mark Pilgrim posts more of his Movable Type templates. Sweet.

Incidentally, I’ve been finding that the site-evolution (rather than site rewrites) are a much more efficient way to go with redesign. Incremental steps are far easier to accomplish with my limited design time (and abilities). They also allow for more subtle tweaks and enhancements.

More subtle tweaks and enhancements coming soon.

The redesign continues.

The update is going well, and I’m back to the serif font. What I’m doing now is removing all of these extra tags that are still hanging around from the original Movable Type template. I had originally tried stripping them en masse from my templates, but it resulted in too radical a change–overhauling my Main Index meant that the Category, Date, and Individual Archives as well as my Search Template would all require a redesign before I could publish the site…too much, too quickly.

Current influences include: Mark, Jeffrey, Dave, Sherif, Dean, Heather, Rachelle, and Doug (if you look at any of those sites, don’t miss Doug’s–there’s so much understated style there). I’m kicking around the idea of finding a design “metaphor” to stick with. Not having one and wanting to pile as much content onto the homepage as possible caused me to design this site to look like a spreadsheet. Removing the calendar from the navigation (who was using it, anyway?) helped, but I would like to use white space more effectively.

Also, does anyone have any suggestions on managing more “static” web content? If you look at any of those examples above, you’ll see that they all have “sections” of their sites: photos, links, bios, etc. I’d like to do this as well, but am having a hard time trying to figure out how to manage them with my CMS (Movable Type). Suggestions to that effect would also be much appreciated.

Additionally: I opened the site in IE6 and have a horizontal scrollbar at the bottom. Mozilla doesn’t have this problem, nor does Opera 7. Can anyone offer some insight?

Oh, and–just in passing–it looks like my birthday came early this year.

Template edits in progress–if the site looks too garrish, try refresh.

If it looks like the presentation of Our Story has been completely mangled in your browser, well, it’s my fault. I started some site tweaking that got a little out of control. But, don’t worry, it’ll be fixed soon.

Update: Realizing that every blog I read uses a sans serif rather than a serif font. Good reading on the subject here. I actually dig the serif font, but there’s just too many “artifacts” (I think that’s what graphic design gearheads call them) on serif fonts on a computer screen–they make it harder to read the content. Hmm.

Okay, I don’t know what I did with my template to make it break MT Macros, but, what’s done is done. Our Story will not be featuring this decidedly wicked cool MT plugin until the increasingly desirable redesign rolls out. In the meantime, I leave you without auto-generated graphic smileys or acronyms.