Sharding is a database technique where you break up a big database into many smaller ones. Instead of having 1 million customers on a single, big iron machine, you perhaps have 100,000 customers on 10 different, smaller machines.

The general advise on sharding is that you don’t until you have to. It’s similar to Martin Fowler’s First Law of Distributed Object Design: Don’t distribute your objects! Sharding is still relatively hard, has relatively poor tool support, and will definitely complicate your setup.

Now I always knew that the inevitable day would come where we would have no choice. We would simply have to shard because there was no more vertical scaling to be done. But that day seems to get pushed further and further into the future.

Last week I took you through the Highrise signup chart redesign.

This week I want to talk about part of the Highrise home page redesign that we’ve already redesigned. The design is alive – we’re making a lot of small tweaks post launch.

Original: In the cards

When we launched the new Highrise site, we had a block in the middle of the page that looked like this:

Three “cards” as we call them. Each card highlighting a major feature of Highrise. The idea was to rotate these cards every once in a while. They looked good and gave the page a nice splash of color, but they didn’t communicate very well. We were using 163,566 pixels, but we weren’t really saying anything.

Redesigned: In the icons

So we decided to make a change. Instead of using all that space to advertise three features, we thought we’d try using it to communicate eight benefits instead. So in a couple hours we came up with this:

Eight benefits, concisely explained, each with an icon for some color and identity. Now that block says something. There’s more to swallow, but it’s easy going down. And it’s only 98 pixels taller than the cards design. Here’s the overlay (the red is the extra height):

There are only two hard things in Computer Science: cache invalidation and naming things. —Phil Karlton

Karlton’s quote isn’t just for techies. Interface designers are in the business of naming things too. We’re copywriters. It matters if we call something an Event or a Milestone or a Deadline. And it also goes deeper than that. The names we choose shape our software. They define the way we think about it and the way our customers interact with it. To understand why this all matters, you should meet two important ideas from the programming world: domains and domain languages.

When you’re working on software, the domain is the life situation your software is involved with. Basecamp’s domain is the life situation where people are trying to collaborate together on a project. iPhoto’s domain is that situation where someone has a collection of photos and they want to look at those photos and share the photos with others.

Now here’s where it gets interesting. Each application has a way of approaching its domain. Software designers think of a domain like a big cake and cut it into slices. Basecamp cuts project management into Messages, Files, Milestones, To-Dos. Photo organizers before iPhoto ‘08 always sliced their domain into Photos and Albums. In both cases, the software designers take a complicated life situation and boil it down to a few easy pieces with names. No domain comes pre-sliced—unless you’re blindly copying someone else’s software. It’s up to the designer to cut the pieces and give them names.

This process results in a domain language. A domain language is the set of words that reflect the way you cut up a domain. It consists of the pieces you sliced and the names you chose to give them. This language defines an application and makes it special. And for the last couple years Apple has been innovating iPhoto’s domain language very intentionally.

Last week I set out to improve the performance of the Dashboard and Contacts tabs in Highrise. Both tabs would frequently be much too slow. Especially the Contacts tab, which for our own account some times could take upwards two seconds to load.

The number one rule for improving performance is to measure, the number two rule is to measure some more, and the third rule is to measure once again just to be sure. Guessing about performance never works, but it’s a great excuse to get you out in the weeds chasing phantom ponies.

Looking outside the epicenter
So I measured and found that part of the problem was actually not even part of the epicenter, the notes and the contacts. In fact, we were wasting a good 150ms generating New Person/Company form sheets all the time (through a complicated Presenter object that’s high on abstraction and low on performance). Even though these sheets were the same for everyone.

That left me with two choices: Either I could try to speed up the code that generated the forms or I could cache the results. Since speeding up the code would require taking everything apart, bringing out the profiler, and doing lots of plain hard work, I decided to save myself a sweat and just cache. People using Highrise couldn’t care one way or the other as long as things got faster and frankly, neither could I.

I ended up with this code:

<% cache [ 'people/new/contact_info', image_host_differentiation_key ] do %>
  <%= p.object.contact_info.shows.form %>
<% end %>

This cache is hooked up to our memcached servers for Highrise. The image_host_differentiation_key makes sure that we don’t serve SSL control graphics to people using Safari/Firefox, but still do it for IE, in according to our asset hosting strategy.

Good enough performance
But saving 150ms per call wasn’t going to do it. So I added memcached caching to the display of the individual contacts and notes as well. The best thing would of course be if I could cache the entire page, but since Highrise is heavy on permissions for who can see what, that would essentially mean per-user caching. Not terribly efficient and hard to keep in synch. So instead we just cache the individual elements and still run the queries to check what you can see.

Learning grammar has to be one of the most boring parts of studying language, especially studying the grammar of your native tongue. There are always exceptions of course—perhaps grammar is your cup of tea—but I’d bet it’s safe to say that most of us would rather undergo a root canal than sit through a lecture on inflectional morphology or modal forms.

However, when my wife was in college, studying linguistics, a classmate of hers had a really fascinating senior project. He proposed (and in fact, implemented) a sixth-grade grammar curriculum with an interesting focus: he had the kids create their own conlangs, and introduced both grammar and orthography concepts as part of that process. He supported the curriculum by showing the kids interesting real life examples, including (among other things) Mayan heiroglyphics!

I wish wish wish wish WISH that I’d had that man as my English teacher when I was in school. What a fascinating way to present an otherwise dry topic. Practical applications trump contrived examples every time.

Also, if you happen to be into conlangs, you may be interested in the 3rd Language Creation Conference, to be held on March 21 and 22 in Providence, Rhode Island. Whether you want to present or just attend, it looks like opportunities are available. (Disclaimer: I’m not affiliated with the conference, but it’s being organized by a friend of mine.)

Have you noticed how everything is trademarked these days? Company and product names I get, and some taglines I understand too, but some of this stuff just seems a bit much.

A few days ago I picked up some new shampoo. I was reading the bottle and it said “The Kiehl’s Patch-Test™: Before applying…” Why does that need to be formally trademarked? Are they worried Aveda or Redken or some other shampoo brand is going to suggest you use the “Kiehl’s Patch-Test” before you try their shampoo? What exactly is Kiehl’s trying to protect?

In the end none of this is a huge deal, it’s just something I’ve been noticing more and more lately. I wonder how much of this is lawyer driven. I assume it’s a pretty easy way to send a client a bill.

I’ve only known one method for approaching a Design project. There are many variations out there, but it can essentially be broken down into 4 steps: Discover, Plan, Design/Develop, and Deploy. It didn’t matter where I worked—agency or internal design department—these were the steps, and I didn’t question them.

Then 37signals published Getting Real, and I wondered if this might be a better way of approaching a project. I’d like to share with you a few stories from past Design projects while reflecting on how Getting Real would have helped. I’ll also share some insight into how the process here at 37signals works.