Since individual tweets are no longer being pulled in, I’ve put a list of the most recent tweets down in the footer. Next to that you’ll also find a new list of the week’s most popular posts. Fancy!

It isn’t drastically different from the old one. I’m still keeping it clean and simple, and the base colors are the same.

You might notice the rounded corners on some things. Yeah, that’s right. Web 2.0, here I come! I think rounded corners are only acceptable if accomplished with simple CSS. CSS3 is slated to include the border-radius property to achieve rounded corners. The specifications are not yet finalized, but Mozilla browsers have implemented the property with -moz-border-radius and WebKit browsers with -webkit-border-radius. Those are the properties that I’m using. That means you’ll get rounded corners in browsers like Firefox and Safari. Opera seems to work too. Internet Explorer, not so much. (Come on, IE has a hard enough time complying with current standards. You can’t expect it to look to the future!)

If you notice any bugs or would like to suggest any changes, let me know. After all, the site is really for you, dear user.

(I did briefly look at everything on a Windows box running IE8. It seemed to work — other than the rounded corners, of course — but if you notice any bugs in that particular browser, you know the drill.)

Two of the things that really spurred this design are Readability and Clippable. For about a month now, I’ve been using these bookmarklets while reading longs articles online. They help a lot. But it’s really a problem with the design of some sites that I feel the need to use them. I decided that I wanted to redesign my site with typography in mind.

I’m also now integrating Twitter posts into the blog. We’ll see how that goes. They’re styled differently, so there is a visual distinction between a tweet and a normal post. The idea is that I’m now just using twitter as a back-end to create short posts. If I want to, I can switch to some other microblogging service and you, the user, need never know the difference. (I could even just use WordPress to create short posts! But that might get me kicked off the interwebs…)

Tweets integrated into the blog means tweets in the RSS feed, as well. That makes my RSS mash-up a bit irrelevant. If you currently subscribe to that, I’d recommend changing your subscription back to the normal feed. For those who don’t want to change, I’ve removed the Twitter feed from the mash-up’s input. That way you won’t have to read each of my tweets twice. The mash-up feed will now only include the blog and Flickr stream.

Blueprint

This design is built upon the Blueprint CSS framework. I’ve used it a handful of times before, but never properly. My method was always to link to the three Blueprint CSS files (screen.css, print.css, and ie.css) in the header and then toss in a link to my own stylesheet underneath them. I never used the compressor.

The idea behind the compressor is pretty simple. It allows you to maintain one central instance of Blueprint and use that to generate the CSS needed for each individual project.

The author’s walk through outlines the general idea:

• Keep a core Blueprint folder checked out with Git on your computer
• Create a settings.yml file within the Blueprint folder with all the specifics of each project using Blueprint
• Use the command line to generate CSS for a project on command
  • Incorporating any site-specific attributes
    • Namespace on all Blueprint classes
    • Custom grid template rather than the standard 24 columns / 30px column width / 10px gutter width
  • Compressing any custom CSS and appending to the end of the Blueprint stylesheets
  • Appending custom semantic selectors to the end of the Blueprint stylesheets

When I first head about this, I though that the compression bit was all well and good, but I’ve never been really adamant about optimizing CSS for speed in the first place. I’m more concerned about compliance with standards and readability. Maintaining a central Blueprint instance didn’t appeal to me much, either. What really stood out is the ability to have custom semantic selectors.

CSS frameworks are neat. I’ve used a handful. Like any other tool, they’re not always appropriate. When they are, they have certain advantages and disadvantages. One of the main things that I dislike about them is that they encourage you to clutter your code with framework-specific junk. If you’re using 960.gs you’re going to have elements with classes like “container_x”, “grid_x”, “omega”, and “suffix_x” all over the place. With Grids you’ll have “yui-g”, “yui-b”, “yui-main”, and the like. Readability of code is diminished and you’ll probably end up suffering from a case of div-itis. Not to mention, you can forget about a strict separation of markup and styling. Sure, you could copy the style definitions for the specific framework classes into the classes or IDs of your own elements, but how many folks actually take the time to do all that copying and pasting? I sure don’t! The appeal in a CSS framework is to save time, not make the process of building a site longer. Plus, there’s an appeal in having the framework-related styling separate from the normal site styling. Such a separation makes the framework easy to update.

This is where Blueprint’s semantic classes comes in. It allows you to tell Blueprint to take one of your classes (or IDs) and apply to it the properties of one of Blueprint’s classes. A-mazing.

As an example, the header of this page might look something like this if built on Blueprint without the compressor:

<div id="top" class="span-24 last">
  <ul id="nav" class="span-18 prepend-1">
    <li><a href="#">Blog</a></li>
    <li><a href="#">Who</a></li>
    <li><a href="#">What</a></li>
    <li><a href="#">Connections</a></li>
  </ul>
  <form method="get" id="search" class="span-5 last" action="...">
        <input type="text" id="search-box" value="Search" name="s" />
    </form>
</div>

<h1 id="title" class="span-24 last">pig-monkey.com</h1>
<p id="description" class="span-23 prepend-1 last">Blah blah blah...</p>

<ul id="flickr" class="span-20 append-2 prepend-2 last">
  <li><img src="myawesomephoto.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto2.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto3.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto4.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto5.jpg" alt="My Awesome Photo" /></li>
</ul>

Look at those framework-specific classes all over the place. Nasty. But in the Blueprint compressor settings file, I can define some semantic classes.

"#top, h1#title" : "span-24 last"
"#top #nav" : "span-18 prepend-1"
"#top form#search" : "span-5 last"
"#description" : "span-23 prepend-1 last"
"#flickr" : "span-20 append-2 prepend-1 last"

Now my markup looks like this:

<div id="top">
  <ul id="nav">
    <li><a href="#">Blog</a></li>
    <li><a href="#">Who</a></li>
    <li><a href="#">What</a></li>
    <li><a href="#">Connections</a></li>
  </ul>
  <form method="get" id="search" action="...">
        <input type="text" id="search-box" value="Search" name="s" />
    </form>
</div>

<h1 id="title">pig-monkey.com</h1>
<p id="description">Blah blah blah...</p>

<ul id="flickr">
  <li><img src="myawesomephoto.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto2.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto3.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto4.jpg" alt="My Awesome Photo" /></li>
  <li><img src="myawesomephoto5.jpg" alt="My Awesome Photo" /></li>
</ul>

Clean as a whistle! No useless divs, all elements semantically named, and not dependent on any framework.

As great as the compressor is, I do have a couple problems with it. When using the compressor, Blueprint intends that you only have 3 final (compressed) stylesheets: screen.css, print.css, and ie.css. WordPress, of course, requires a style.css file to define the template. That’s no problem. I just a create a style.css file that has the theme information in it and then toss in a @import url('blueprint/screen.css'). Then in the WordPress header I can put a link to style.css, print.css, and ie.css. Everybody’s happy.

Styling a website basically boils down to making a small change to the stylesheet and refreshing the page to see how that looks. Running the compressor after each change to combine the custom stylesheet with the screen.css file is not productive. So for the development process I tossed a @import url('blueprint/custom.css') into the main style.css file. That works fine.

Then I finish building the theme. I’m ready to compress the stylesheets, so I remove the call to the custom stylesheet in style.css. I tell the compressor where the custom stylesheet is and have it combine it with the screen.css file. I run the compressor, reload the site, and everything explodes.

Just when I thought I was done!

The problem is that in the stylesheet the compressor generates, it puts my custom styles above the semantic classes. Throughout the development process, I was calling the screen.css file (which includes the semantic classes) before the custom stylesheet. As you no doubt know, stylesheets cascade. You can’t just switch up the order of elements without breaking stuff.

Oh well, I thought. At this point I was tired working on the site and didn’t care enough to fight it. I just put the line to call the custom sheet back in style.css after Blueprint’s screen.css file. I still feel like the whole semantic classes bit is enough of a reason to use the compressor, even if I’m not actually compressing my main stylesheet!

When I first decided to add twitter posts to my site, I debated whether I would rather have them integrated into the actual blog posts or separated. Visually, I like to have the separation, but I always thought it would be neat to pull the twitter posts directly into WordPress’ database, and so have them integrated into my RSS feed. Otherwise, for those who wish to follow my twitter posts, but are not on twitter, they have to subscribe to two different feeds — both my blog feed and twitter feed.

Today, I had the idea of keeping the actual separation of twitter and the blog, but simply creating a new RSS feed using some sort of RSS-mash-up-aggregator thingy. I thought Feedburner could do something like that, but apparently not. After searching around for other options and not finding anything that really excited me, I decided to just use Yahoo Pipes. After all, this is pretty much what it was made for.

Combining feeds in Pipes is pretty simple, but after mashing them together, I discovered that twitter’s RSS feed is kinda ugly. Luckily, editing feeds using regular expressions in Pipes is pretty simple, too. After polishing up the twitter feed a bit, I thought Why not toss my Flickr feed into this puppy? But occasionally I’ll upload a large group of photos to Flickr at a single time, and I didn’t want to totally bomb my new RSS feed. Plus, most of the time when I put photos on Flickr, I create an accompanying blog post, so I wasn’t sure that adding the Flickr feed to the mash-up was even necessary. I figured that I’d toss in the Flickr feed for now, but compromise by having Pipes truncate it to the 6 most recent items.

Now I have a pretty new feed.

Then came the problem of what to do with it. I didn’t want to just toss up a link somewhere. I preferred the idea of replacing my normal blog feed with this new super-feed. But I also didn’t want to just edit the WordPress template header. I new Feedburner had a plugin to integrate with WordPress, so I thought about burning the new feed and then using the Feedburner plugin to pull it in, but that seemed a little excessive, particular since I don’t care about any of the click-tracking or monetizing features of Feedburner. Then I found the Feed Locations plugin, which does exactly what I wanted: allow me to specify the location of my feed in the WordPress admin panel.

Now, if you ask WordPress for this site’s RSS feed, you get the new feed. If you’re opposed to all this new fanciness and just want the plain old blog feed, it’s still up at the same location, just not linked to from anywhere.

Let me know what you think about having the Flickr photos in the feed. If it’s redundant, I’ll take them out.

The base template and heavy CSS of the last design made this change relatively simple. This time around, I’m using YUI Reset and YUI Fonts. I started using both of them a month or two ago on a couple other sites. It’s hard to imagine building a site without them now. They take a lot of headaches out of CSS.

This design is not using YUI Grids. I have used it before, but I don’t think it offers any benefit with this kind of design. It’s more suited toward a content intensive site with many nested divisions. Something like Yahoo’s front page.

You’ll also notice a Twitter feed on the top of the index page. I’ve been trying to figure out what the appeal of Twitter is, but so far, it’s escaped me. I figured embedding tweets on the site would provide extra encouragement for me to try it out. I think Twitter may lend itself to my summer on the road, too. So, we’ll see how long that lasts. It seems to be noticeably slow, so I might have to find another way to pull the data.

Another new feature is tags. I started tagging posts a while ago, but haven’t displayed them till now. The majority of posts are not tagged. Maybe someday I’ll go back and tag the 1,300 old posts — but I doubt it.

Some kinks of the design are still being worked out, but if you notice anything strange — whether it be from the redesign, server move, or mail move — let me know.