Sometime between September 1st and September 3rd, I thought this stuff was interesting. You might think so too!

A new year is (almost) here, and along with that, it was time for a bit of a refresh to the design. It’s not a huge change — generally speaking, all the bits are in the same basic places — just a little fine-tuned and tweaked.

  • I’ve switched the theme to a mostly-stock installation of Carrington, with just a few tweaks here and there to suit my tastes.
  • Tweets are now a little more visually separated from each other and from longer posts, and are now linked back to the original entry on Twitter.
  • I’ve been adding tags to my entries for a little while, but they’re just now starting to be exposed via the new sidebar. Most entries don’t have tags, but I’m slowly adding them as I go back to work with older posts…that’s going to be a long, slow process that I’m not devoting a whole lot of time to. New posts will be tagged as they appear.
  • Google Adsense banners have been tweaked so that they’ll now appear underneath the first two non-Tweet posts on the main page. I’ve been trying to have some variation on that for a while (keeps them visible, but not super intrusive), but it’s been buggy. I think I’ve finally got it working properly.

And that about covers it.

I’m all for giving attribution for the goodies people find on the ‘net, letting readers know where the information comes from, acknowledging that links to cool stuff don’t just spontaneously appear, but are usually passed on from person to person and website to website.

Unfortunately, sometimes the process of tracing those breadcrumbs back when you actually want to get a little more information is an exercise in frustration.

For instance:

  1. Boing Boing posts about a silly little photography gadget that they saw over at…

  2. LikeCool, who have a tiny little “via” link (that I almost missed as it was buried under a stack of Google ads) that links to…

  3. Gizmodo, who finally link back to…

  4. Photojojo, who actually sell the silly thing, and have things like tech specs, adapter info, and so on.

In LikeCool’s defense, they did link directly to Photojojo’s page in the text of their post, but I missed that link on my first readthrough (the forest green link text wasn’t enough of a contrast difference to the black body text to catch my eye on the first skim).

Would it be too much trouble to say “I read about this here, and you can buy it or get more info here,” instead of forcing your readers to jump through multiple hoops? By the time I found my way to the source page, I’d pretty much lost interest in it. Besides, it looks more creepy than amusing or useful.

Wacom is currently having a “Go Platinum / Go Pro” photo/design contest.

Go Platinum: design a cover for a stock photography CD.

Go Pro: submit a photo for inclusion in a future stock photo CD.

The winner of each contest will get a 40Gb iPod and $1000 as payments for the rights to use their submission.

Pretty cool, I think — I’ve submitted my Post Alley photograph. Worth a shot, at least!

Printing often seems to be the bane of web publishing doesn’t it? All this information scattered across the ‘net, and so many times, trying to get a decent hardcopy printout just results in frustration. Sites that are beautiful in a browser may fail when printed — text disappears into background colors if you’re printing black and white, ads take up tons of unnecessary space on the printed page, and if the site uses tables or a fixed-width CSS layout that’s wider than the page, you may end up with having text cut off along one side of the page. Many commercial sites create special ‘print friendly’ pages, but that’s something of a kludge in itself — it’s an extra click, sometimes the link to the ‘print-friendly’ page is difficult to see, and it means having to deal with that many extra pages (and extra bandwidth) to maintain and serve.

Thankfully, CSS allows a remarkably simple way to avoid having to deal with all these frustrations. With a little bit of coding time, you can create a special “print stylesheet” that will determine exactly how your page looks when it’s printed out, without ever having to deal with the problems outlined above. Here at TypePad, you’ll need to be a “Pro” user to take advantage of this (as you’ll need access to the code of your templates), but the same technique will also work for MovableType powered sites, or any other website where you have full access to your code.

Need a quick example? Just try printing this post out, then compare what your printer gives you to the screen version (Netscape, Mozilla, Firebird, and Safari users will get an extra bonus trick that IE doesn’t support). For all the gory details (which really aren’t all that gory), just read on…

This site without print CSS

For a quick example, I’ll hold myself up to the spotlight (hey, if I’ve going to point out the problems, might as well humiliate myself instead of someone else, right?). The image to the right shows the result of printing this site after my redesign — those nice big white borders that work so well on screen cause definite issues on the printed page, squishing all the actual content into a single really tiny column in the middle of the page. This obviously was not acceptable! So, I got to work.

The first step was to design the print stylesheet itself. The basics of that are essentially the same as designing an on-screen stylesheet, and you can even use a browser to work it all out. I started by copying my stylesheet into a blank text document on my computer and tweaking it piece by piece to adjust it for the printed page. I won’t go through all the changes I made (though you’re welcome to compare the two to see for yourself — feel free to look at the code for either my screen stylesheet or my print stylesheet), but I do want to call attention to a few of the methods I used.

First off, the borders — an easy fix there, all I had to do was adjust the margins for the #content div from 150 pixels to 5%. By using a percentage instead of a fixed value, it ensures that the content area of the printed page will always be 90 percent of the available width, no matter if the person printing the page is in the US or in Europe (as there are different standard paper sizes).

Now for a handier trick. One of the major differences between on-screen display and the printed page are that navigation elements, such as the navigation sidebar across the top of each page on my site, are essentially useless when printed. Obviously, they can’t be clicked, so all they really end up doing is taking up space on the printed page. If that’s the case, then why bother printing them at all?

In my original stylesheet, my navigation bar is contained within a div of its own, like so:

#navigation {
   text-align: center;
   margin-top: 2px;
   padding: 4px;
   background-color: #eee;
   }

So, for the print stylesheet, I simply changed all of that to this simple argument:

#navigation {
   display: none;
   }

And voila! When printed, that entire div just disappears from the page. That little display: none; argument comes in very handy for deciding just what appears and doesn’t appear on your printed page and on screen. I added a class called “screenonly” to my print stylesheet that uses the display: none; argument, and then wrapped the comment entry form on my individual entry pages in a div class="screenonly" tag — bingo, no printed comment entry form. With a little experimentation, it’s very easy to determine exactly what elements on your pages will and won’t print.

The same technique can be used on screen, of course. I added another class to my screen stylesheet called “printonly” that also uses the display: none; property, then added a copyright declaration to the bottom of every page that is wrapped in a div class="printonly". Now that won’t display onscreen, but will appear when printed. Pretty nifty, isn’t it?

There’s one last trick I want to call attention to before I close out, though — while it will only work in browsers that have good CSS support (in other words, almost every browser except Internet Explorer), it’s incredibly useful.

Links are somewhat of a quandry on the printed page — in fact, by default, they’re nearly useless. A slight color change in the text, but nothing else. However, CSS includes ways to work around this, as well. I added the following lines to my print stylesheet:

.postbody a:link:after, .postbody a:visited:after {
   content: " (" attr(href) ") ";
   }

This looks a little complex, but it’s really not all that scary. The first line says simply that within any element that has the class postbody (I’ve wrapped the text of my posts, trackback excerpts, and comments in divs with that class), any a element that is either a link or a link that has been visited is going to have some information added after that element.

The second line is the content that we’re adding: first we add a space and an opening parenthesis, then we add the href attribute (in other words, the URL that the link points to), then we add a closing parenthesis and another space. That’s it — the last line is simply closing the CSS argument.

So what does all that mean? Simply this — when the page is printed, every link will be followed with the target URL of that link in parenthesis. Nifty!

Okay, so those are some of the tricks I’ve used. Now, supposing you’ve done some poking, prodding, and experimentation on your own and you’ve got a print stylesheet all set up and ready to go — how do you get it working? Easy enough! First off, create a new Index Template for your site, name it something like “Stylesheet-print”, and have it output to “print.css”. Now, you’ll need to do a slight edit to each of your templates.

The default line in TypePad templates that calls the stylesheet is in the header information at the top, and looks like this:

<link rel="stylesheet" href="<$MTBlogURL$>styles.css" type="text/css" />

We’ll be adding one argument to that line, and then adding a second, very similar line –here’s what you should end up with:

<link rel="stylesheet" media="screen" href="<$MTBlogURL$>styles.css type="text/css" />
<link rel="stylesheet" media="print" href="<$MTBlogURL$>print.css" type="text/css" />

What we’ve just done is tell the browser that the “styles.css” file should only apply to on-screen display, while the “print.css” file should apply to content that is sent to the printer. That’s it — rebuild, and you’re done!

My site with the print stylesheet

And here we have the final result — the image to the left is how my site prints out with the print stylesheet added. The useless navigation bar has disappeared, borders have been set to values that are far more manageable and readable for the printed page, I’ve brought the font size down a touch, and all links now display their target after the link itself. All in all, a far more readable printed page than what I started with, and all accomplished with a little bit of playing with CSS.

So that’s it! Hopefully this all made sense and is useful for you. As always, feel free to leave any comments or questions below, and I’ll do my best to clarify any places where I may have been unclear. Enjoy!

(Post-link URL display code was found at A List Apart.)

Up until now, all the various design tweaks I’ve made on this site have been conducted from within the TypePad interface, without my mucking about with any of the code. That’s starting to change, however, as I start to incorporate some of the conventions I’ve gotten used to with my templates at The Long Letter into the site here. I’m taking things a little slowly to make sure I don’t break anything (permanently), but work has begun.

Some details and thoughts on my changes follow.

(The following notes will be updated as I work my way through the various templates and make my changes.)

All templates

Two minor changes have been made to all the templates.

The first is purely cosmetic, in that I’ve adjusted the indenting of all the HTML code so that it’s easier for me to track through. As a side benefit, it should be a bit easier for other people if they go poking around in my source code.

Secondly, and important for usability, I’ve noticed that in the default templates, none of the hyperlinks have the title attribute set (the text that shows as a tooltip in most browsers, or before the URL in the status bar in Safari). I was somewhat surprised by that, but it’s a fairly simple fix for most of the tags.

Archive Templates (category and monthly)

The default templates for archives display every post in its entirety in reverse chronological order (exactly which posts are displayed depends on the archive type — all posts in a single category for category archives, all posts in a month for monthly archives, etc.). That may work well if you create short posts, or don’t post terribly often, but for me, it’s a nightmare. I tend to babble and create (ridiculously) long posts, and while this site is new, if I do end up adopting TypePad for my permanent home once it’s open for business, then I’m going to want to import all two years plus of my archives. Obviously, with the default templates, this could make for extremely long archive pages.

So, to combat that, I set up my archive templates to create essentially a ‘table of contents’ for each archive page. Each archive page now displays the title of each individual post, linked to the post’s individual entry page. After that comes the post excerpt, then a brief listing of the post’s metadata (post time and whether any comments have been added — were I creating a multi-author weblog, post author would be included also).

With this setup, while each archive page will still grow over time, it will be substantially smaller than it would be if it were displaying the entirety of each post. By including the post’s excerpt, it allows for a little more contextual indication of what each post is about, so it should still be relatively easy to find individual posts.

Currently (as of 8:20pm, July 13th) I’ve only altered the category templates to reflect this scheme, but monthly archives should be updated shortly.

7/13 8:54pm: Monthly archive pages have also been updated.

Archive templates (individual)

Not too terribly many changes here, aside from the aforementioned HTML re-formatting and adding title attributes to the hyperlinks. I did tweak the post metadata line so that the permalink is attached to the timestamp on the post rather than a single word that just says ‘Permalink’, and then added permalinks to individual comments with the same style. Other than that, it’s primarily the same.

I would eventually like to see if the live comment preview I have working on my individual pages on The Long Letter will work in this layout, but I’ll probably save that for another night, just in case it turns into more of a battle than I think it will.

Main index template

Again, like the individual archives, not too many changes — primarily just the formatting of the metadata line, with permalinks moved to the post time. Not that exciting, overall.

Main archives template

The default main archive template is functional, but nothing more than that. A simple list of links to the monthly archives, with links to category archives (if you’re using categories) below that. Not bad, of course, but I wanted to do better.

The monthly archive links I’ve kept more or less the same, with the exception that rather than listing out one on top of the other (and using up a large amount of vertical space for very little information), they list out horizontally. Of course, you can’t really tell that now, but when we roll around to August it’ll be more obvious.

For the category archives, I’ve included the post titles to the last ten posts in each category beneath the category title. The title itself links to the full category archive page, while the post titles link to their respective individual pages. It’s not much more information that what was available before, but it does give a little bit more, and can make searching for a recent post a little quicker than digging through each archive page if you don’t quite remember what category it got tossed into.

Usability guru Jakob Nielsen posted his list of the year’s top ten web design mistakes, and while it’s aimed more at commercial sites, I thought I’d take a quick gander and see if there are any that I should worry about.

  1. No prices: Hrm. Well, in general, I’d say that this one doesn’t apply. However, let it be said for the record that I’m often fairly cheap. Even free, given the right circumstances!
  2. Inflexible search engines: Unfortunately, there’s not much I can do about this one. The search page for my site is nice and powerful, but I’m not enough of a coder to tell it how to correct for spelling errors. Bummer, too — that’s a nice feature.
  3. Horizontal scrolling: I try to avoid this one, however on a smaller screen or resolution, my archives page might need scrolling. Right now, I like the format I’m using, though, and until I find a better one, this will work. Anyone have any suggestions for a different design?
  4. Fixed font size: Yay! I got away from this one during my last site redesign. Something I don’t have to make cute comments or excuses for! :D
  5. Blocks of text: Guilty. Very guilty, in fact. Given the fact that I tend to ramble, I’m not sure how to approach this one, aside from spending some time going through Jacob’s articles on writing for the web, which I should do soon.
  6. Javascript in links: Lightly guilty here — while I’ve excised most of the JS links on my site, the ‘Show Smileys’ links in post comment forms still use it. I need to find a good way around that, I suppose (probably either displaying a small set of smileys and leaving the rest hidden, or just removing the smiley code entirely). Again, any suggestions? I’m leaning towards removing the code — they’ll still be available, but they’re used so infrequently, I might as well get rid of them in the comment form.
  7. Infrequently asked questions in FAQ: Not having a FAQ, this one doesn’t really apply. I’ve never gotten enough questions to warrant a FAQ, actually.
  8. Collecting e-mail addresses without a privacy policy: Well, again, this doesn’t really apply. While there’s a spot for e-mail addresses in my comment forms, they’re optional, and I don’t do anything with them. They just sit there.
  9. URL’s greater than 75 characters: I’m pretty sure I’m safe here. Some of my posts with obnoxiously long titles probably break this one, but they’re relatively few and far between. I’ve also been trying to keep my post titles shorter since I moved to an archiving system that names the files by the post title, rather than using generic numbers for names (such as 000735.php, for instance).
  10. Mailto links in unexpected locations: I think I’m good here. Every page has a fairly clearly marked “Email me” link at the bottom, and that’s it. Not hidden, available at all times, and not overly intrusive.

Not too bad, all in all, I’d say.

However, this does bring to mind a question. For those of you that visit my site from time to time — is there anything I’ve done here that bugs you? Or even if it doesn’t bug you, is there anything that you think might be worth my investigating? I’m starting to get into a mood to play with code and clean up some small areas that are bugging me, and I’m always open to suggestions. Feel free to let me know!