Destinations

Not much in the way of posting tonight. Instead, I concentrated on converting the ‘Destinations’ section of my sidebar so that all items now have comment and TrackBack ability, and there are archives for items that have scrolled off the page.

Doing this was fairly easy, if a little time consuming.

All I had to do was create a new weblog to hold all the links, instead of using a TypeList (since TypeLists don’t support archives, comments, or TrackBack). For the weblog itself, I just copied all my templates from Eclecticism so that the visual design matches this one, and then tweaked them a bit so that they linked directly back to Eclecticism’s main page rather than the new blog’s main page, as it’s intended to be a subset of this blog.

I then added a new Index Template that mimics the output of the TypeList. Since TypeLists are simply unordered lists, this was fairly easy to do — here’s my destinations.inc template:

<h2>Destinations</h2>
<ul>
 <mtentries lastn="10">
 <li><a href="<$MTEntryBody$>" title="<$MTEntryTitle$>"><$MTEntryTitle$></a>
  <mtentryIfExtended>
   <br />
   <$MTEntryMore$>
  </mtentryIfExtended>
  <mtentryIfAllowComments> | <a href="<$MTEntryPermalink$>#comments" title="Read comments for '<$MTEntryTitle$>'">c:<$MTEntryCommentCount$></a></mtentryIfAllowComments>
  <mtentryIfAllowPings> | <a href="<$MTEntryPermalink$>#trackback" title="See TrackBack pings for '<$MTEntryTitle$>'">tb:<$MTEntryTrackbackCount$></a></mtentryIfAllowPings>
 </li>
 </mtentries>
 <li><a href="http://djwudi.typepad.com/destinations/archives.html" title="Destinations archives">Archives&hellip;</a> | <a href="http://djwudi.typepad.com/destinations/index.rdf" title="Subscribe to Destinations">RSS Feed</a></li>
</ul>

Then I altered the code in the sidebar1.inc template for Eclecticism so that rather than inserting the Destinations TypeList, it inserted the destinations.inc file I had just created.

After that, it was just a matter of copying all the old TypeList entries into posts in the new Destinations weblog. Each post gets a normal title, the URL of the link goes in the main post body, and any descriptive text goes in the extended entry — very similar to the TypeList method of entry, just in a standard post form.

End result, the same basic functionality of the TypeList I was using before, only now with comments, TrackBack, and archives. Not bad for an evening’s work.

The MovableType/Mac conspiracy…

Another IM conversation, investigating the MovableType/Six Apart/Mac/Apple conspiracy…

Me: i’ve got a blogger account for a side project of mine, but it’ll probably be moving to TypePad pretty soon
Me: i can’t do anything on a free Blogger account, and if I’m going to give someone money, I’d rather have it be the Trotts

Phil: Keep it for testing at any rate, could you? I don’t really know anyone who uses Blogger and has a Mac.
Phil: Other than me.

Me: sure, will do

Phil: The Mac populace seems to prefer MT, interestingly. Except the people at Forwarding Address: OS X.
Phil: Hm…. maybe I could get Cory Doctorow as a beta tester. That’d be amusing.

Me: i’ve noticed that, actually – been pleasantly surprised at how often Macs get mentioned on TP blogs

Phil: Interesting correlation, really, if you think about it.
Phil: People who use Blogger often go on forums and curse about how unreliable and buggy it is.
Phil: People who use Windows often go on forums and curse about how unreliable and buggy it is.
Phil: People who use MT are often like “Look at this cool trick I can do with my blog!”
Phil: People with Macs are often like “Look at this cool trick I can do with my Mac!”
Phil: Do you see a trend?
Phil: I think maybe Movable Type is the Mac of the blogging world.

Me: i think you just get in a mindset…using computer == dealing with bugs (if you’re on the Windows side)

Phil: Same way with Blogger.
Phil: Using Blogger == dealing with bugs.
Phil: Oh!

Me: Is Six Apart the New Apple?

Phil: Yeah, I saw that.
Phil: And (using Blogger/using windows) == no help at all from the parent company.
Phil: Well, except the UNIX geeks and developers.

Me: ‘zactly
Me: and us Mac users are spoiled by the “It Just Works” syndrome

Phil: True.

Me: MT “just works” – and you never have to deal with the underlying code if you don’t want to
Me: OS X “just works” – and you never have to deal with the terminal if you don’t want to
Me: but in both cases, if you do want to, a whole world of new toys and possibilities open up

Phil: Hacks, plugins, new applications you’d never even thought of.
Phil: And I could be talking about either one with that last sentence.

Me: bingo

I think we’ve got something here!

Overpriced? Oh, come on.

(Disclaimer: Long, rambling post ahead. This originally started as a comment in response to some comments on this post and others I’ve seen in the past day. This probably isn’t my best written or most coherent rant ever, but here it is.)

Since the official feature and pricing list for TypePad went up yesterday evening, I’ve seen quite a few people grousing about TypePad being overpriced, especially for the Pro package. I don’t think it’s overpriced at all, and will be quite happily signing up for an TypePad Pro account.

First off, about this “free MovableType” that people keep referencing. Sure, MT can be legally downloaded and used for free — however, it’s far better to give a donation if you continue to use it. I’ll save the ranting on the current desire for everything to be free for later, but for now, suffice to say that I’m of the belief that purchasing the software you use regularly is a good thing. The Trotts have put incredible amounts of time and effort into creating what I feel is the best blogging back end application available, and I quite happily sent in a donation to pay for my MT license.

Now, about my present server situation. I’ve been running my personal website, including a MT powered blog, off of my own computer in my apartment for years now. In other words, essentially free, without even the costs of paying for a hosting provider. Theoretically unlimited disk space (as long as I can add new drives, I won’t run out of space). No monthly bandwidth cap. No ads. No limitations on what I can do with my site (I could, in theory, run a porn server without any hassle. It’s a direction I’ve never wanted to go, but I could). My only sacrifices are that my transfer speed is somewhat limited by my DSL line (which, when dealing with text and images, isn’t much of a sacrifice at all over a T1-speed DSL connection), and I don’t have a top-of-the-line server, so it’s not always the speediest on the ‘net (again, though, the majority of the time this isn’t even noticed when just serving text and graphics).

So, I’ve been living with most of the benefits of paying for a hosting service, without the costs, and with the added benefits of having total control over my webserver. I can tweak Apache’s http.conf file to my heart’s content. I can install any number of CGI scripts, SQL databases, or other toys without limit. I don’t even have to deal with uploading and downloading files to my site — all I have to do is copy from one directory on my computer to another, and everything’s good to go.

Why in the world, then, would I want to pay $15/month (not counting any discounts I get for being a TypePad beta tester) to relinquish that amount of control over my site?

Quite a few reasons, actually.

First off, when did $15 become so horridly expensive a price? That’s nothing. It’s the price of an evening at the movies (ticket plus drink and snack) for one person. It’s what, two and a half decent sized coffee’s from Starbucks? Less than the price of having a single medium Domino’s pizza delivered to your door. Less than three packs of cigarettes, if you’re a smoker (and heavy smokers can go through that in a day, let alone a month). These days, it’s less than a full tank of gas.

Next, everything you get with your account. Merely looking at the feature list doesn’t really convey how completely cool some of these features are. You get all the functionality and benefits of a MovableType installation (plus quite a few) without having to bother with the installation itself, without having to worry about which Perl modules are or aren’t installed (Do I have access to Image::Magick? If not, can I get it installed? What about the alternatives?), without having to worry about your hosting provider throttling MT when it tries to grab processor time during a rebuild. Basically, without any of the issues that running your own installation can present. Now, admittedly, for many people, these issues are trivial, and easily dealt with — I’ve faced and conquered quite a few myself — but many other people aren’t going to want to have to worry about things like this.

You also get the extras that are built into TypePad, some of which have been covered this week during the Five Days of TypePad series. Simple, built-in moblogging, allowing you to quickly and easily post from your cell phone, PDA, or by e-mail — a feature I haven’t played with, but other people have said good things about. Amazingly easy photo albums. TypeLists, which have made maintaining the sidebars on this website incredibly easy — the four blogrolls on the right, and the ‘Destinations’, ‘Bookshelf’, and ‘Noises’ lists on the left are all TypeLists.

Beyond all that, there’s the interface itself. The template builder makes the basic layout and design of a simple weblog ridiculously easy: choose a basic layout style, which features you want displayed, and drag and drop them into place. If you want to go beyond the basics, you have access to the source code, complete with all of the MovableType template tags you’re already used to using, and you can tweak and customize to your hearts content. I could easily have duplicated the design and style of my old weblog here at TypePad if I’d wanted to, however it was more fun to play with the built-in tools until I got a basic design that I liked, then go into the code to tweak it from there, with an end result that I like better than what I had before.

Also, for me (and this is somewhat specific to my situation), the speed is a definite improvement. As I mentioned above, my home server isn’t the speediest in the word. While this doesn’t affect me much for simple page serving, it does tend to show a little bit when people are leaving comments on my site, and it shows more for me on the administration end when I’m navigating within the MT interface. By moving to TypePad, everything’s far speedier to work with — combine that with the ease of use of the new interface, and it’s well worth it.

Now, there are a few things that I’m giving up in order to move over here. TypePad users don’t have the ability to muck around directly with the source code of the back end software. This precludes using some of the hacks that involved tweaking the MovableType source code. Adding MovableType plug-ins is also not an option. For some people, this is going to be a very strong and valid reason not to use TypePad — there are a lot of very impressive, very powerful hacks and plug-ins available for MovableType. Some of these I’ve used, and losing their functionality is a little disappointing — however, the majority of the time (for me), they fell into the “here’s a neat trick, I’m going to play with it for a while” category, and not the “this is functionality that I don’t want to live without” category, so I’m willing to lose those specific bells and whistles for the new bells and whistles I get to use here at TypePad.

In the end, for me, the benefits far outweigh any disadvantages. That may not be the case for everyone, and I realize this — however, I think that the complaint that TypePad is overpriced is silly at best, and almost offensively self-centered at worst. There are already a good few years of development sunk into MovableType, plus the extra time and effort that has been put into scaling MovableType up into a public service like TypePad. Is all that time worth nothing at all? From the number of people declaring how they’ll stay with MovableType because it’s free, it seems that that seems to be a very prominent (and sad) attitude.

For myself, though, I’ve paid for MovableType, and I’m going to pay for my continued residence here at TypePad. For me, the features are worth it, the ease of use is worth it, and I’m supporting the hard work that Ben and Mena (and Anil, Brenna, and anyone else at Six Apart) have put into MovableType over the years. They’ve done an incredible job with the services and software packages that they offer, and I’m happy to stick with them.

So I’m staying. :)

Help search engines index your site

We all know that Google is god. Chances are you’ve used Google when doing a search on the ‘net at least once, if not daily, or many times a day. If not, then I’ve heard rumors that there are other search engines out there — though I haven’t used any in so long, I can’t really vouch for the veracity of that rumor. ;)

I wanted to share a few tricks I use here to help Google (and other search engines) index my site, and to try to ensure that searches that hit my site get the most useful results.

All of the following tips and tricks do require access to your source HTML templates (in TypePad, you’ll need to be using an Advanced Template Set). While I’m writing this for an Advanced TypePad installation, the tips will work just as well in any other website or weblog application where you have access to the HTML code.

Specify which pages get indexed, and which don’t

What? One of the most important pages on a weblog from a user’s point of view is the main page. It has all your latest posts, all the links to your archives, your bio, other sites you enjoy reading, webrings, and who all knows what else. However, from the perspective of a search engine, the main page of a weblog is most likely the single least important page of the entire site!

This is simply because the main page of a weblog is always changing, but search engines can only give good results when the information that they index is still there the next time around. I’ve run into quite a few situations where I’ve done a search for one term or another, and one of the search results leads to someone’s weblog. Unfortunately, when I go to their page, the entry that Google read and indexed is no longer on the main page. At that point, I could start digging through their archives and trying to track down what I’m looking for — but I’m far more likely to just bounce back to Google and try another page.

Thankfully enough, though, there’s an extremely easy fix for this that keeps everyone happy.

How? One short line of code at the top of some of your templates is all it takes to solve the problem. We’re going to be using the robots meta tag in the head of the HTML document. The tag was designed specifically to give robots (or spiders, or crawlers — the automated programs that search engines use to read websites) instructions on what pages should or shouldn’t be indexed.

For the purposes of a weblog, with one constantly changing index page and many static archive pages, the best possible situation would be to tell the search engine to read and follow all the links on an index page (so that it finds all the other pages of a site), but not to index that page. The rest of the site, it will be free to read and index normally.

That’s very easy to set up, as it turns out. The robots meta tag allows four possible arguments:

INDEX
Read and index a page normally
NOINDEX
Do not index any of the text of the page
FOLLOW
Follow all the links on a page to read linked pages
NOFOLLOW
Ignore all links on a page

So, in order to do what we want, we add the following meta tag to our document, in the head section, right next to the meta tags that are already there:

<meta name="robots" content="noindex,follow" />

Now, when a search engine robot visits the index page of the site, it knows that it should not index the page and add it to its database, however, it should follow any links on that page to find other pages within the site. This way, searches that return hits for the site will be sure to find your archive pages for the information that is requested, rather than your front page, which may not have the information anymore.

Update: It turns out that this technique may have some side effects that I hadn’t considered, and might possibly not work at all. For more details, please scroll down to Anode’s comment and my reply in the comment thread for this post. Hopefully I’ll be able to dig up more information on this soon.

Fine tune what sections of a page get indexed

What? There is a proposed extension to the robots meta tag that allows you to not just designate which pages of a site get indexed, but also which sections of a page get indexed. I discovered this when I was setting up a shareware search engine for my old website, and have since gotten in the habit of using it. Now, this is not a formal standard, and I don’t know for sure which search engines support it and which don’t — the creator of this technique has suggested it to the major search sites, but it is not known what the final result was.

Now, why would you want to do this? Simply this: on many weblogs, including TypePad sites, the sidebar information is repeated on every page of the site. There is also certain informational text repeated on every page (for instance, the TrackBack data, the comments form, and so on). This creates a lot of extraneous, mostly useless data — doubly so when that information changes regularly.

By using these proposed tags, any search engine that supports them will only index the sections of a page that we want indexed, and will disregard the rest of the page.

How? Because this is based on the robots meta tag discussed above, it uses the same four arguments (INDEX, NOINDEX, FOLLOW, and NOFOLLOW). Instead of using a meta tag, though, we use HTML comment syntax to designate the different sections of our document.

For instance, every individual archive page on a TypePad weblog that has TrackBack enabled will have the following text (or something very similar):

Trackback
TrackBack URL for this entry:
http://www.typepad.com/t/trackback/(number)

Listed below are links to weblogs that reference (the name of the post)

In order to mark this out as a section that we wanted the search engine not to index and not to follow (as the only link is to the page that the link is on), we would surround it with the following specialized tags:

<!-- robots content="noindex,nofollow" -->
<!-- /robots -->

For example, I would change the code in the TypePad Individual Entry template to look like this:

<mtentryIfAllowPings>
<!-- robots content="noindex,nofollow" -->
<h2><a id="trackback"></a>TrackBack</h2>
TrackBack URL for this entry:<br /><$MTEntryTrackbackLink$>
Listed below are links to weblogs that reference <a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a>:
<!-- /robots -->
<mtpings>

The same technique can be used wherever you have areas in your site with content that doesn’t really need to be indexed.

Now, as I stated above, this is only a proposed specification, and it is not known which (if any) search engines support it. It also requires a healthy chunk of mucking around with your template code. Because of these two factors, it may not be an approach that you want to take, instead simply using the “sledgehammer” approach of the page-level robots meta tag discussed above.

However, I do think that the possible benefits of this being used more widely would be worth the extra time and trouble (at least, for those of us obsessive about our code), and I’d also suggest that should TypePad gain a search functionality, that these codes be recognized and followed by the (purely theoretical, at this point) TypePad search engine.

Put the entry excerpt to use

What? The entry excerpt is another very handy field to use in fine tuning your site. I believe that the field is turned off on the post editing screen by default, but it can be enabled by clicking on the ‘Customize the display of this page’ link at the bottom of the post editing screen.

By default, the entry excerpt is used for two things in TypePad: when you send a TrackBack ping to another weblog, the excerpt is sent along with the ping as a short summary of your post; and it is used as the post summary in your RSS feed if you have selected the ‘excerpts only’ version of the feed in your weblog configuration. However, it can come in handy in a few other instances too. One that I’ve discussed previously is in your archive pages. However, the excerpt can also be used to help out search engines.

You may have noticed that when you do a search on Google, rather than simply returning the link and page title, Google also returns a short snippet of each page that the search finds. Normally, this text snippet is just a bit of text from the page being referenced, intended to give some amount of context to give you a better idea of how successful your search was. There is a meta tag that lets us determine exactly what text is displayed by Google for the summary, though — which is where the extended entry field comes in.

How? We’re adding another meta tag here, so this will go up in the head section of your Individual Archives template. Next to any other meta tags you have, add the following line:

<meta name="description" content="<$MTEntryExcerpt>" />

Then save, and republish your Individual Archives, and you’re done. Now, the next time that Google indexes your site, the excerpt will be saved as the summary for that page, and will display beneath the link when one of your pages comes up in a Google search.

So what happens if you don’t use the entry excerpt field? Well, TypePad is smart enough to do its best to cover for this — if you use the <$MTEntryExcerpt$> tag in a template, and no excerpt has been added to the post, TypePad automatically pulls the first 20 words of your post to be the excerpt. While this works to a certain extent, it doesn’t create a very useful excerpt (unless you’re in the habit of writing extremely short posts). It’s far better to take a moment to create an excerpt by hand, whether it’s a quick cut and paste of relevant text in the post, or whether it’s more detailed (“In which we find out that…yadda yadda yadda.”). In the end, of course, it’s your call!

Use the Keywords

What? Keywords are short, simple terms that are either used in a page, or relate to the page. The original intent was to place a line in the head of an HTML page that listed keywords for that page, which search engines could read in addition to the page content to help in indexing.

Unfortunately, keywords have been heavily abused over the years. ‘Search Engine Optimizers’ started putting everything including the kitchen sink into their HTML pages for keywords in an effort to drive their pages rankings higher in the search engines. Because of this, some of the major search engines (Google included) now disregard the ‘keywords’ meta tag — however, not all of them do, and used correctly, they can be a helpful additional resource for categorizing and indexing pages.

How? One of the various fields you can use for data in each TypePad post is the ‘Keywords’ field. I believe that it is turned off by default, however you can enable it by clicking on the ‘Customize the display of this page’ link at the bottom of your TypePad ‘Post an Entry’ screen.

Once you have the ‘Keywords’ field available, you can add specific keywords for each post. You can either use words that actually appear in the post, or words that relate closely to it — for instance, I’ve had posts where I’ve used the acronym WMD in the body of the post, then added the three keywords ‘weapons mass destruction’ to the keywords field. You never know exactly what terms someone will use in their search, might as well give them the best shot at success, right?

Okay, so now you have keywords in your posts. What now? By default, TypePad’s templates don’t actually use the data in the Keywords field at all. This is fairly easy to fix, however.

In your Individual Archives template, add the following line of code just after the meta tags that are already there:

<meta name="keywords" content="<$MTEntryKeywords$>" />

Then save your template, republish your site (you can republish everything, but doing just the Individual Archives is fine, too, as that’s all that changed), and you’re done! Now, the next time that a search engine that reads the keywords meta tag reads your site, you’ve got that much more information on every individual post to help index your site correctly.

Conclusion

So there we have it. One extremely long post from me, with four hopefully handy tips for you on how you can help Google, and the rest of the search engines out there, index your site more intelligently. If you find this information of use, wonderful! If not…well, I hope you didn’t waste too much of your day reading it. ;)

Feel free to leave any questions, comments, or words of wisdom in the comments below!

Geeking about Dean

I really wonder if there are people on the Howard Dean campaign who are tied in enough to the “geek” side of the blogosphere to realize how big of a deal it could be that Dean is getting mentioned prominently by Doc Searls, Robert Scoble, and Tom Negrino.

Much as Robert likes to claim he’s got all of 18 readers (which is about 12 more than I’ve got, I think), he, Doc, and Tom and his wife Dori Smith are some of the bigger names in the weblogging world. Robert’s one of the most well-known Microsoft webloggers and a Longhorn evangilist; Doc, among many other things, is the senior editor for Linux Journal; and Tom and Dori are Mac fans and authors of several technical books. Big names, getting Dean’s name out into tech circles. Could be a very good thing. If nothing else, it’s more exposure, but given the general tech bent of all three weblogs, Doc’s interest in copyright and media issues and Dean’s appearance on Lawrence Lessig‘s blog last week, I can’t help but think that there are possibilities here.

Make sure that Dean is kept current on some of the “geekier” political battles and can articulate his stances on those issues clearly (one of the issues I’ve read about the Lessig guest-blogger appearance was Dean’s perceived lack of a solid stance on many of the issues that Lessig’s core readership hold dear), and it could go a long way to solidifying Dean’s support among the tech set.

TPBETA 1505

TPBETA 1505

My own little concept for marking my spot as a TypePad beta tester. A small badge, with ‘TPBETA’ on the left, and ‘1505’ on the right. 1505 is the ID number for my TP blog — obviously, the older the blog, the lower the ID number will be. Just another idea to toss into the mix of ideas running around right now. ;)

On the off chance anyone wants to duplicate this, I used the Kalsey Button Maker with the following settings:

  • Outer border: 666666
  • Inner border: ffffff
  • Bar position: 50 pixels from left
  • Left box:
    • Text: tpbeta
    • Background: 006699
    • Text color: ffffff
    • Text start: 5 pixels from left
  • Right box:
    • Text: 1505
    • Background: dddddd
    • Text color: 000000
    • Text start: 4 pixels from the bar

Update (prompted by Grumpy’s comment): You can find your blog ID# by logging into your TypePad admin page, going to your weblog editing screen, and checking the address bar of your browser. The end of the URL will look something like blog_id=1505 — there you go!

TPS Syndrome

Am I suffering from TPS: TypePad Snobbery? You know it, baby! ;)

Common symptoms discovered so far: