• More attractive filmstrip and panel navigation
• Better handling of overflow in both panels and filmstrip frames
• Pre-loading of panel and filmstrip images
• Transferring CSS to external stylesheet for greater customization
• Option to disable circular filmstrip navigation
• Multiple galleries one one page
• Allow for run-time addition/subtraction of panels via AJAX

If you’ve got an idea that I haven’t mentioned, feel free to leave a comment with your thoughts and I’ll see what I can do.

Out With the Old, In With the New

If you are building your own WordPress theme, or are using a simple pre-built theme, your index.php will utilize The Loop, WordPress’s method of iterating through your posts. By default, it should look something like this:

<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
    ...output your post data...
<?php endwhile; else: ?>
    <p><?php _e('Sorry, no posts matched your criteria.'); ?></p>
<?php endif; ?>

A few things are occuring here. First, have_posts() is executed to see if there are any posts to display. If there are, a while loop is entered which continues running as long as have_posts() returns true. For each post, the_post() is executed, which populates various WordPress functions such as the_content(), the_tags() and the_permalink(). If there are no posts to display, a message is written indicating the fact. If we want to differentiate how we handle the latest post and posts after that, we need to create two loops. Luckily, the WordPress function query_posts() makes this feat easy.

The query_posts() function allows us to refine what posts are pulled into the have_posts() function. The function accepts a list of parameters to filter the posts you want to see. While there are many options available to you, we only need two: showposts and offset. To get only the most recent post, we need to add an additional line of PHP just before the start of our loop:

<?php query_posts('showposts=1'); ?>

Easy, right? Now we need to get our other recent posts, but showposts alone won’t do the job because each call to query_posts() starts from the first post. We need to use another parameter, like so:

<?php query_posts('showposts=10&offset=1'); ?>

With these two functions, your code should now resemble:

<?php query_posts('showposts=1'); ?>
<?php if(have_posts()) : while (have_posts()) : the_post(); ?>
    ...do something with your latest post...
<?php endwhile; else  >
    ...display error message
<?php endif; ?>
<?php query_posts('showposts=10&offset=1'); ?>
<?php while (have_posts()) : the_post(); ?>
    ...do something with your recent posts...
<?php endwhile; ?>

You’ll notice I don’t use if (have_posts()) in the second loop. If there isn’t a first post, an error message will be displayed, so there’s no reason to display another one when there isn’t a second post either. Likewise, if there is only one post, we don’t want to display a post and then display an error saying there aren’t any posts.

So now that I’ve got two separate loops set up, how best to display the post(s) in each loop? I decided that for the latest post, it was best to display the first paragraph or two using the <!--more--> HTML comment utilized by WordPress. Inserting this comment into your post indicates to WordPress that only the content before it should be displayed on the homepage with a link to ‘read more’. All content after this comment is only available by viewing the specific post page.

For my other recent posts, I decided that it was enough to simply provide a brief overview of the post’s contents, and therefore chose to utilize the ‘excerpt’ feature of WordPress posts. To display a post’s excerpt instead of the content itself, we swap out the_content() for the_excerpt(). Easy peasy.

Next Time, On Space for a Name

For returning readers (or anyone who’s visited Space for a Name’s evolution gallery, you’ll notice I’ve made a number of changes other than just editing my WordPress homepage. I’ve added a navigation menu, created a logotype, and added a background. I feel these changes constitute their own topic, so I’ll leave them for another day.

Wouldn’t it be interesting if there were only one typeface in the world? Designers would really have to think about the idea behind their designs instead of covering it up with fancy typefaces. One, universal typeface would really strip away all the flashy emptiness in design. And, of course, that one typeface would have to be Helvetica. ~ Erik Kessels

I wanted to make this next article about true CSS typography, but it is proving to be a tougher nut to crack than I originally expected. It’s one thing to pick out a few font faces, set your colors, font sizes and line heights. It’s quite another to manage the plethora of available analphabetic symbols, fine-tune kerning and perfect vertical rhythm between elements.

My goal is to eventually write a jQuery plugin that does many of those tasks at run-time, letting anyone enhance their website’s copy without having to read The Elements of Typographic Style. But that’s a topic for another day. Instead, I’ve decided to start with the basics and implement the typography stylesheet provided by Blueprint CSS.

As mentioned previously, I chose Blueprint as my CSS framework because it included a typography stylesheet that has what I feel is a good foundation for building attractive copy. Even if you do not plan on using any CSS framework, there are some important tips one can take away from the stylesheet. A default font size is set as a percentage for the <body> tag and all other font sizes are set in ems. This allows you to easily alter the relative font sizes of all elements by changing a single rule. No top margins are set for headers or paragraphs to avoid a few browser discrepancies in how margins overlap each other. Blueprint also includes a number of “helper” classes, which can be used on any element to make common adjustments.

.small      { font-size: .8em; margin-bottom: 1.875em; line-height: 1.875em; }
.large      { font-size: 1.2em; line-height: 2.5em; margin-bottom: 1.25em; }
.hide       { display: none; }
.quiet      { color: #666; }
.loud       { color: #000; }
.highlight  { background:#ff0; }
.added      { background:#060; color: #fff; }
.removed    { background:#900; color: #fff; }
.first      { margin-left:0; padding-left:0; }
.last       { margin-right:0; padding-right:0; }
.top        { margin-top:0; padding-top:0; }
.bottom     { margin-bottom:0; padding-bottom:0; }

In addition to the basic typography stylesheet, Blueprint has also included a “fancy-type” stylesheet, which makes some headway toward implementing more advanced typographic styles. As you can see on this site now, successive paragraphs are set without any top margin and are indented to give the text more of a print feel. An alt class is also provided, which sets the specified element in a fancier font face and alters the style and color. A class is provided to shift opening quotes left so that a line of text that begins with a quotation mark will still sit flush with successive lines. Finally, a class is provided to make abbreviations or other words set in caps more attractive, altering letter spacing, padding and font size.

So, both stylesheets have been implemented, and with a little extra CSS magic, you can see what a change some simple text alterations can make to a website. If this is your first time visiting my website, you can see what the site used to look like by checking out the evolution gallery.

Overall, a pretty effective design that makes good use of varying font faces and iconic graphics. Just the other day, I was wandering back to my car at the mall, when I passed a display in Macy’s for Jumpman, Michael Jordan’s Nike offshoot brand. A particular shirt caught my attention.

Many (all?) of Jordan’s career accomplishments crammed into a rectangle on the front of a shirt. Red/white graphics on a black shirt. To me at least, the connection was instantaneous. I saw this shirt, I immediately thought of Spoilt. So, honest coincidence, or did some designer over at Jumpman just get lazy?  What are your thoughts?

It didn’t take long to settle on WordPress.  I’ll admit, however, that not much research went into that decision.  At a glance, Wordpress seemed to offer the level of customization and control over markup that I desired, and my web host provided it as a one-step installation.  So, ease won out over rigorous investigation.

I could have installed WordPress right out of the gate, but I wanted to start from scratch, and wasn’t immediately sure how I’d be able to do that.  I didn’t want to use the default theme, and I definitely didn’t want to use a pre-made theme…that would kind of defeat the purpose of this entire website.  I also didn’t want to waste a week studying an existing theme just to deconstruct it so I could start with a blank slate.

That’s where Whiteboard comes in.  Whiteboard is a WordPress theme with no CSS and no design.  Just data and basic HTML markup.  Just what I needed…almost.  The markup is simple, but not quite as semantic as I would have liked. The blog tagline was a <p> instead of a heading of some sort.  The same holds for post bylines.  It is also lacking some blocking markup to allow for effective styling.  However, it was quite easy to get it up and running with my existing CSS.  I simply moved a copy of the Blueprint directory (see my post on site layouts) into the wp-content/themes/whiteboard/ directory and added the following lines to the top of style.css:

@import url('blueprint/grid.css');
@import url('blueprint/forms.css');

Over the next few days I’ll be working on marking up the various templates as needed (initially simply defining my CSS grid), but I didn’t want to wait that long to replace my single-page website with a fully-fleged (albeit bare) WordPress installation.

BONUS

The other reason I wanted to get WordPress installed early was to give you, the reader, a voice.  You’ve been silent this past week (all 3 of you), and this site won’t survive without your input.  So please, comment away!

You just don’t know what you got ’til it’s gone some Nigerian ex oil minister offers it to you for assisting him in his escape from an oppressive regime.

Wow, sometimes I can be a real moron. What was I thinking, putting my email on a website? How could I be so naïve as to want to provide a way for my readers to communicate with me?

Needless to say, the spam has begun arriving at my virtual doorstep. I quickly took down the links, but for all I know, it’s already too late. Regardless, I did some quick reading on how to limit one’s exposure to email harvesters. While there are plenty of links out there, I think Nadeau Software Consulting did it best with their article on Effective Methods to Protect Email Addresses From Spammers. They even include a handy table that shows each method’s effectiveness (as of 2007, anyway), usability, browser support and accessibility.

I decided to go with the Javascript method, as simply replacing letters with character codes is something most email bots can get around, it seems. My script is dead simple:

function writeEmail() {
	var n = "jack";
	var d = "spaceforaname";
	var e = "com";
	document.getElementById('email').innerHTML = '<a href="mai'+''+'lto:'+
	n+'@'+d+'.'+e+'">Send me an email</a>';
}

I broke up the email address into three separate variables and even split ‘mailto’ into two parts separated by an empty string, just to play it safe. I also took an idea from this article by Tauros Marketing and made sure to accomdate folks without javascript. To do so, the default html of my ‘email’ element is my email address written out in plain text, with the ‘@’ and ‘.’ replaced by images. The alt and title attributes have also been set to accomdate those without the ability to display images. The HTML looks like:

<span id="email">
  jack
  <img src="img/shift-2.gif" alt="-at-" title="-at-" />
  spaceforaname
  <img src="img/dot.gif" alt="-dot-" title="-dot-" />
  com
  <script type="text/javascript">writeEmail()</script>
</span>

So, as long as email harvesters haven’t been upgraded to execute javascript code or decipher image alt tags, I should be safe. Well, safer. I kinda feel like it’s only a matter of time before even these methods become useless. All we can hope for is that the people (if they really are human, that is) who write email harvesters are lazy and won’t bother upgrading their code as long as the easily attainable email addresses keep flowing in.

Assuredly, each website brings with it unique considerations, but I tend to fall back to a handful of fairly standard conventions. Primary navigation menus consisting of 3-5 items live quite comfortably in a horizontal menu adjacent to the website’s header. Longer lists of 6-9 main buttons are also a good fit for horizontal menus, but require a bit more room and are thus better placed above or below the website’s header. If your primary navigation conists of multiple menus, 10 or more buttons, or is likely to grow with time, then a vertical menu in a left sidebar is your best bet, as this is the most flexible solution.

Sidebar placement is an issue that may raise some questions. You want your main content to take precedence, but you don’t want your sidebar content to be ignored completely. Luckily for us, others have already done the hard work to determine how users view websites using heatmap studies. Jakob Nielsen, arguably the biggest name in web usability, has an informative and easy-to-read article on reading habits, and Google has also done their own reasearch involving eye-tracking.

What should we take away from this? As Nielsen’s article shows, readers focus across the first two paragraphs of your content, and down the left hand side of a website. If you have a sidebar with lots of navigation, it better be in a left sidebar if you want your users to be able to find their way through your website. If your sidebar consists mostly of secondary content that is of less importance to your readers, do them a favor and keep it to the right. Advertisements raise an interesting conundrum. Your users don’t want to be bothered with it, suggesting a right sidebar placement, but you want as many views and click-throughs as possible, indicating a preference for a left sidebar. If your website has ads, I’ll leave it to you to decide what’s best for you and your readers. Since I don’t plan on having a lot of navigation in my sidebar, to the right it goes.

Ok, Now What?

So you’ve chosen a layout. Now how are you supposed to implement it, and ensure cross-browser compatibility, no less? Enter the grid. I’ll admit, until recently, I’d never used any kind of pre-packaged CSS layout framework. I recently stumbled upon 960 Grid and was instantly converted. One problem I’d always had when designing was getting columns of content to look good. I never had a problem setting up my main columns—normally utilizing the layout resevoir from bluerobot.com—but when setting up content within a column, my widths were always a bit haphazard and margins were set with abandon. It worked, but never felt quite as solid as it should be. The grid framework changes all that. By providing designers a simple way of defining columns with specified, aesthetically pleasing widths and margins. All the pain of complying with various browsers is alleviated as well, since the CSS is already written. Just apply the right classes to your markup and go. The benefit for me was that a grid system is just as good at setting up your main columns as it is formatting content within those columns.

I was all set to adopt the 960 Grid system, but quickly found that it wasn’t the only player in the game. Here’s a quick list of the more popular options:

• 960 Grid
• YAML: Yet Another Multi-Column Layout
• Blueprint CSS
• Yahoo! UI Grid CSS
• Grid Designer

Each has their ups and downs. For instance, Grid Designer lets you build any size grid you want, customizing columns, margins and gutters. For a thorough write up on CSS grid systems, check out “Which CSS Grid Framework Should You Use For Web Design?” by nettuts.com. In the end, I wound up changing my mind and going with Blueprint. Not only is it widely used, it’s more than just a grid framework. Blueprint includes frameworks for forms, and more importantly, typography. I say more important because my next topic of discussion will be CSS typography and Blueprint is going to make my life a lot easier in that regard.

Blueprint works on a 950px wide layout with twenty-four 30px columns, separated by 10px gutters. Creating a column is as easy as adding the following classes to your <div>:

• span-X : Creates a block that spans X columns
• prepend-X : Pads the block with X columns to the left
• append-X : Pads the block with X columns to the right
• border : Places a light border to the right of the block
• colborder : Appends a single column to the right of the block and places a border in the middle of said column

There are many more options as well, and Blueprint has a fairly thorough test page displaying what the framework can offer. For reference, this site uses class="span-16 colborder" for the main content column and class="span-7 last" for the sidebar. The last class makes sure there isn’t an unneeded 10px gutter to the right of the column. Click here to toggle the grid underlay (if overlay is a word, so is underlay) to see it for yourself.

The only complaint I could make about Blueprint is that it is not 100% compatible with IE by default. It corrects any bugs by using a conditional comment in the HTML header, adding an IE-specific stylesheet for users of Microsoft’s browser. A minor complaint, but a complaint nonetheless.

Ah, another day (ok, two days), another step under the belt. Come back next time to learn way more than you ever wanted to about CSS typography.

And the sins of the browser shall be visited upon the site.

Take a look at this test page of various HTML elements. Take a brief look at its formatting. The headers are bold and set in varying sizes. Block quotes are indented. Emphasised text is set in italics (or oblique, depending on the font, but that’s a topic for another day). Paragraphs have margins. Even the <body> itself has a margin. But why? I certainly didn’t tell the browser to style these HTML elements like this.

“But Jack, that’s what those elements are supposed to look like.”

Precisely. They’re supposed to look like that. It’s convention. Tradition. The way of things. In the days before CSS, browser manufacturers took it upon themselves to implement a set of presentational standards for HTML elements, making life for the website creator easier.

“We know you want your header to be big and bold, so we’ll save you the trouble by making it the default.”
“Oh, thank you, Netscape Navigator!”

That was fine and dandy until the day someone wrote out a CSS rule h1{ font-weight: normal; } and realized, “Wait, why should I be telling the browser what not to do? The browser shouldn’t be doing anything!” We simply don’t live in 1995 anymore. We’ve separated our markup from our presentation, and we want to keep it that way, but even modern browsers are hell bent on setting an arguably arbitrary set of default presentational rules. The worst of it is that the myriad browsers can’t even agree on the same defaults. Sure, headers will always default to bold, but how much space should be between a header and the following paragraph? Does a second-level unordered list use round or square bullets? Just how much do you indent a blockquote?

For an example of what the defaults for various browsers are, here are some screenshots I took of the aforementioned page.

• Windows – IE7
• Windows – Safari 4 Beta
• Windows – Firefox 3
• OS X – Safari 4 Beta
• OS X – Firefox 3
• OS X – Opera 9

Take particular note of the whitespace. While browsers may be more or less in sync when it comes to default font sizes, they’re all over the map when it comes to margins and line-heights. Firefox 3 in Windows is pretty generous with whitespace while Opera on OS X tries to cram as much content above the fold as it can. Also note that Opera 9 breaks from the crowd and refuses to style unordered sub-lists any differently than their parents.

Hit the Reset Button

You have two options here. Live with the fact that your users’ browsers are going to poke at prod at your markup and hope that you’ve defined a sufficient number of styles to keep the browser defaults from showing through, or you can wipe the slate clean before you even start writing your CSS. That’s where the CSS Reset comes in.

I won’t go into too much depth, because it’s been discussed at length over the past few years. In fact, Six Revisions has a pretty thorough article on resetting CSS. To make a long story short (too late), Eric Meyer, master of all things CSS, has what can be considered a pretty definitive foundation for CSS Resets. I say foundation, because you shouldn’t just dump this into your site untouched. For instance, why create a body{} rule to set up font color and background images when one already exists right there in the reset stylesheet? Also, your specific project may necessitate default styles that differ from what Meyer has deemed appropriate.

In fact, I wouldn’t really think of it in terms of resetting your CSS, but rather creating a new default for your particular site. If you know all the tables in your site will have a particular border style, don’t write a new table{} rule, just overwrite the existing rule in your reset stylesheet.

That said, let’s revisit our test page of HTML elements, now with Eric Meyer’s reset stylesheet applied. Much better…almost. You’ll notice that headers still appear in boldface, as well as table header cells (which also remain defaulted to a central alignment). Also, emphasized and strong text maintain their default appearance. Meyer has argued in favor of leaving these particular defaults as they are common enough and sensible enough to avoid resetting. However, for my needs, I would prefer defaulting headers to a normal font-weight and setting all elements to a default left alignment. To achieve this, I’ve added a few lines to Meyer’s universal rule to handle these attributes:

font-weight: inherit;
text-decoration: inherit;
font-style: inherit;
text-align: left;

These rules will default all elements to a normal font weight with no style or decoration, but allow me to override that as needed and ensure that all children of those elements inherit the overridden style. Of course, this also eliminates the styling on emphasized and strong text, so I need to explicitly define those styles now:

em { font-style: italic; }
strong { font-weight: bold; }

One last change I made was to ordered lists. While it’s good to leave unordered lists without any default styling (because they’re often used for much more than just lists of text), I decided that ordered lists will only be used for just that, ordered lists of text.

ol { list-style: decimal; }
ol ol { list-style: lower-alpha; }
ol ol ol { list-style: lower-roman; }

Let’s take one final look at our test page, this time with my version of the reset stylesheet. Now that’s a clean slate if I’ve ever seen one. I guess it’s high time I get cracking on making this site less of an eyesore. Readability, coming’ up!

P.S. – You won’t see any numbering on the ordered lists of the final test page because list-style-position defaults to outside, and since there are no margins in the page, the numbers wind up residing off the left edge of the browser window.

There is nothing wrong with your browser window. Do not attempt to adjust the stylesheet. We are controlling HTTP responses. If we wish to make it louder, we will bring up the font size. If we wish to make it softer, we will tune the color to #DDD. We will control the horizontal padding. We will control the vertical alignment. We can scroll the CSS sprite, make it flutter. We can change the drop shadow to a soft blur or sharpen it to crystal clarity. For the next few months, sit quietly and we will control all that you see and read. We repeat, there is nothing wrong with your browser window. You are about to participate in a great adventure. You are about to experience the awe and mystery which reaches from the inner DOM to…the outer scripts.

I know what you’re thinking.

Damn, the page didn’t finish loading, let me refresh. Hmm, still not working. I wonder if…Oh, oh god no. There’s no stylesheet. No javascript. No images. What is this, 1994? He’s using Times New Roman!

That’s right ladies and gentleman. Shield your children’s eyes, for you’re looking at bare naked HTML. As a web designer/developer with 10 years experience, what possible reason could I have for publishing a website in its raw, unprocessed state?

Well, website development is an involved multi-step process. I don’t think it’s too unfair to liken it to the production of a motion picture. Take your favorite DVD, for instance (Apocalypse Now, The Matrix, White Chicks, whatever…I’m not here to judge). Most people pick it up for the finished product, the movie itself. However, film buffs, students of the art form, and people wondering if Angelina Jolie was digitally ‘enhanced’ in Tomb Raider pick it up for something else, the special materials. Documentaries, interviews, art galleries. Not only do they appreciate the finished product, they want to see just how it came together. What goes into building the city of Minas Tirith? How do you direct an animatronic velociraptor? What was it like working with Estelle Getty on the set of Stop! Or My Mom Will Shoot? These documentaries provide an in depth analysis of just what it takes to create your favorite movie.

Likewise, most people are perfectly happy to visit a well-designed website and are wholly unconcerned about the process required to create it. But us? We see the whole, but we also see the sum of its parts. We’re all students of design. We’ve visited countless websites and wondered, “Man, how’d they make that menu? Is that a javascript framework? Why is that text so much easier to read than other sites?” The answers to these questions normally only come after digging through source code, searching for appropriate Photoshop tutorials, or plain old trial and error.

Not here.

Welcome to the first—I hope—real-time web design documentary. Over the coming months, I’ll be detailing every step of my design process for spaceforaname.com, and I hope you’ll take a bit of time out of your day to come along for the ride. What can you expect to find here?

• Research and discussion on every facet of website design and development. CSS, Javascript, programming languages, blogging software options, Photoshop. When I research a topic, I’ll post my findings. If I add a new graphic element to the site, I’ll link to tutorials for the effects and processes used to create it. When I choose a javascript framework, I’ll discuss why I chose it over competing alternatives.
• Community interaction. As soon as I get some form of commenting up and running, I’ll be looking to you for help as much as you’ll hopefully look to this site for tutorials, inspiration and research. I’ll probably even wind up putting some design decisions to a vote when designer’s block hits.
• An ever-evolving ’growing’ website. The benefit to doing this in real-time is that you get to watch the site grow as I develop it. I’ll also be keeping a daily screenshot gallery to archive the site’s evolution. There really is nothing quite like capturing your website’s first float on camera.

Hey, you’re still reading. Fantastic. Hopefully, that means I’ve managed to interest you, if only enough to come back and see what tomorrow brings. And if you’ve made it this far, you might be interested in my side project, GalleryView. My first jQuery plugin (Spoiler alert as to my choice of javascript framework? Perhaps.)

So, until next time, feel free to find me on Twitter or shoot me an email. Boy, I’ve got my work cut out for me.