Halogen Labs

I’ve written up my experience at Interaction 10 the other week in Savannah, GA.

I’ve been giving my much-ignored blog some love lately. I noticed my SEO-friendly permalinks broke a while back. I’m not sure when it happened, but I only really noticed it after Dreamhost moved my hosting to a different box. It could just be a coincidence, but at least it’s fixed now.

I’ve also implemented some fancy fonts using the awesome Kernest service, and I’ve also tweaked some of the other ugliness on the page. The bit of stuff between the page footer and the content has a proper background now, and I’ve made it a little wider. I’ve also fixed some of the padding and margins around the page headers. Hopefully the blog is easier to read.

It starts out simple enough. You’re building a webapp, and you want people with a certain role (read: Administrator) to have access to a separate “back-end” part of the system. They have to do different stuff, so it makes sense to make a separate administrator interface. A classic example of this is something like WordPress, where you have a totally different area of the website to sign into, and you have a myriad of different tasks you can perform.

At first, it seems to make sense — administrators have various goals they want to accomplish, like mass-approving comments or creating a draft of an article. The part of a blog that faces the reader is usually geared towards reading content, not making changes to it.

Lately, I’ve been thinking about something that I remember hearing a while back from Edward Tufte. The phrase is “administrative debris,” and Ryan Tomayko wrote about it a year ago.

Anyway, I’ve had the itch to finally write my own blogging app for personal use, and I’m following some of the ideas that Ryan writes about — things like using in-place editing, and making content look identical between reading/editing.

The nice thing about having your content be your interface is that it’s a lot quicker to make changes. Because it’s less painful, I’ll be more likely to write.

• I don’t have to remember the secret admin URL.
• When I’m logged in, I don’t have to parse a cluttered admin interface.

I’ll post more thoughts about design of the project when I get closer to actually having it live.

I recently installed the wonderful test_benchmark plugin for Rails, and ran it against our code. I was surprised to find that we had a couple unit tests that were taking 4 seconds to complete.

Digging in, I found code that was doing the following on a time range:


range = # .. a time range 24 hours "wide"
start_time = range.min
end_time = range.max


I looked up the API for Range, and there are no .min and .max methods defined, but they live in enumerable. So what’s going on here?

A little more digging:


>> count = 0; r.max { |a,b| count +=1; a <=> b }
=> Fri Apr 03 20:07:29 UTC 2009
>> count
=> 88200


Oops. 88,200 comparisons for a time range. Switching the code in the test and the class under test to use .first() and .last() instead of .min() and .max(), and I shaved off a cool 8 seconds from rake test

Is our beloved Mac text editor, TextMate, dead? The TM Blog hasn’t updated since the middle of August, 2008.

The latest cutting-edge version is 1.5.8, r1498, and it’s been a while since that’s updated, too.

Has TextMate died, or has it just reached a maturity level where it doesn’t need updates and new features as often? Whatever happened to the fabled TextMate 2.0? Last I read about 2.0 was back in 2006 when Alan mentioned 2.0 would require Leopard. Not even a peep about 2.0.

What’s going on?

Edit: I found a TextMate 2.0 FAQ, which indicates that TM2 was actively being developed, at least towards the end of November 2008. Hopefully we’ll see something in 2009.

The Wheres and Whens of User Expectations is a good article by UIE that talks about user expectations for account sign-in links and fields:

As we watched users, it seemed they first looked for two text-entry boxes of equal size. Their eyes would scan the page (often with the mouse cursor in tow) searching for the two entry fields.

Sites that had two text-entry boxes, often contained in a larger box with a distinct background and border, would quickly acquire the user’s attention. They’d type their username into the first box and their password into the second.

This pattern is so strong that we see it work even on sites that don’t follow the pattern. Over at Etrade.com, the online trading and banking site, their design has two pairs of dual text-entry boxes. One pair is the standard login field, but a more prominent pair is for stock quotes and the site’s search functions.

Because of the strong drive of the user to react to this pattern, it’s common to see users type their username and password into the stock and search buttons, completely missing the proper sign-in fields. From this, we can see designers need be careful when placing pairs of text fields that users don’t confuse them for the sign-in boxes.

The Sign-In Link Pattern

If users don’t see two boxes, they then start scanning for a link called Sign-in or Log-in. (We haven’t seen anyone who uses a button for this, but it’s also an option. However, we’d wonder if a button would create cognitive dissonance if it appeared without corresponding fields.)

A pattern that worked well in our research was, once logged in, to replace the sign-in link with the user’s name, id, or email address, followed by a sign-out link. Users showed they understood the semantics and reassured them that the system had recognized their account information.

Just futzing with the layout of the site. Not that anybody reads this thing anymore :)

Not a lot going on. I had a very busy spring. The house almost burned down. Summer was busy too, as well as fall. Hopefully I can relax this winter :)

Scope me on Twitter.

More later.