Scribbish hatom support updated for Mephisto too

Saturday, November 04

DeLynn Berry has just finished porting the improved hatom goodness of Scribbish to the Mephisto version. Oh, and this new version makes use of some new features in Mephisto 0.7, so make sure you’re up to date. Thanks, DeLynn. I hereby proclaim you the official maintainer of the Mephisto branch.

Scribbish hAtom support updated

Saturday, November 04

The hAtom specification has changed a bit since I implemented it in Scribbish. It was very much in draft-form at that time, and has now matured to verion 0.1. This morning I updated the typo version of Scribbish in SVN to use the new 0.1 API. I’ll work on the Mephisto version later on tonight. Now you can actually use an hAtom parser, like the Almost Universal Microformats Parser to extract content from a Scribbish-powered blog.

Here’s the parser’s output for QuotedPrintable.

Haml has a web site

Saturday, November 04

Remember yesterday when I was talking about how I get to work with incredibly talented individuals? Well, another one of those fine folks is Hampton Catlin, inventor of Haml and giver of swearword-riddled presentations. Haml now has its own website, dedicated entirely to, well, Haml.

It features, documentation, tutorials, download instructions, and links to the google-group. Check it out:

All Things Haml

Endless, Pageless

Friday, November 03

I’m lucky enough to work at Canada’s bestest Ruby on Rails consulting boutique, Unspace Interactive. One of the great things about getting to work at Unspace is that I’m constantly exposed to new and innovative ideas from some of the smartest, most creative people I know. Among those innovators is Pete Forde.

Pete recently published an article in which he describes an interesting user interface technique: endless scrolling. You can read it on the Unspace site: Endless, Pageless

As a long-time web developer, I know the term ‘pagination’ all too well. When I have a set of search results, a set of articles, or a series of comments that exceed more than, say, ten items, I paginate them. This usually involves the ubiquitous ‘Next’ and ‘Previous’ links, either at the top, or bottom of the resultset. Of course, this invariably raises the question of how many results to display on a single page, whether or not to hide the pagination area if there are no results, and whether or not to hide the ‘next’ link on the last page and the ‘previous’ link on the first page.

Not only is pagination a pain from a development perspective, Pete argues that it’s a pain from a user experience standpoint as well. I wholeheartedly agree. When I’m scrolling through a list of articles on a person’s blog, or photos in a Flickr photostream, I hate having to click for the next page. If I’m still scrolling, it means I want to see more. I want more results. I want more articles. I want more photos. In fact, I often leave the page once I’ve viewed the first page. Particularly when reading blogs. I wonder how many more articles I would read on someone’s blog if I could just keep scrolling, if the information just kept flowing?

This is clearly an idea that’s catching on. I’ve recently become a huge fan of the new Google Reader which employs this technique to great success. I can simply scroll through my list of articles without ever having to use the mouse. And as I approach the ‘bottom’ of the page, more articles are appended to the list automatically. (Incidentally, if you’ve not tried Google Reader recently, try it again; they’ve updated it and improved it significantly.) I can see this technique eventually making its way into Gmail, making the ‘number of messages to display on each page’ preference obsolete. I’m told that Yahoo! Mail is doing this now, though I have yet to see it for myself.