Just a quick update on our new 37signals Affiliate Program.

We launched it about 90 days ago and so far we’ve seen about 1000 new product signups referred by 37signals Affiliates. Basecamp leads referrals, Backpack is second and Highrise a very close third.

Some people are working harder than others. The top affiliate has potential earnings of over $1300 already!

If you’re an affiliate, thanks for representing our product to your clients, colleagues, friends, and family. If you’re not, please consider becoming a 37signals Affiliate today. It only takes 30 seconds to get started and there’s no cost to you.

I’ve wanted to redesign the Highrise sidebars for a long time. They’ve felt cluttered and messy to me, and as we add more features to Highrise the mess will only multiply. So I was glad to have the chance this week to redesign the sidebar modules. The visual side of the redesign was straightforward, but implementing the design in code required a few tricks. Here’s a look behind the scenes at the coding decisions we made for the new Highrise sidebars.

“Subjects” in Highrise

Which sidebar modules am I talking about? In Highrise you can keep track of People, Companies, and Cases. These all have the same basic code and UI. You can keep notes about them, set tasks for the future, and manage some common types of metadata. Since People, Companies and Cases share so much plumbing, we’ve abstracted them as subjects. A subject is anything in Highrise that you can attach notes and tasks to. When you look at a subject’s page, you see a sidebar with some modules for adding or editing metadata such as contact information, background information (a kind of static text description), dates to remember for that subject, and more. The screenshot below shows a subject page with the sidebar modules highlighted.

Redesigning the modules

Each module has a header like “Contact Bob” or “Dates to remember” and data below. In the original design, modules can be either “active” or “empty” based on whether they have any data in them. Empty modules have a grey header and an “add” link floated right. Active modules have a light blue header and an “edit” link on the right. We made this distinction so your eye would more easily catch active modules when you’re looking for information. The idea was good, but the original implementation looked messy with its mix of grey and blue, scattered red action links, and lack of separation between modules.

For the first redesign (above) we cleaned up the modules. Active modules are now wrapped entirely in a light grey box with a tiny drop shadow. We killed the blue header style, relying instead on the space between modules to separate them. Empty modules no longer have a header. They are grey boxes collapsed down to a single link to add the content relevant to that module. Finally we replaced all the red links with grey links in order to put the focus on the data within active modules rather than all the possible actions. One last tweak: we changed the text for “About [subject’s name]” to “Add background information.” We’ve gone back and forth a number of times on the language for this feature, and at this stage we decided to try “background info” on for size again.

The first redesign was a big improvement. But we didn’t like the way active and empty modules looked mixed together. The dim bar in between those two active modules creates a kind of striped look that we want to avoid. The problem was worse on subjects with more sidebar modules, like companies or cases. So we decided to group all the active modules together on the top, and then group the empty modules on the bottom. The result is much cleaner, and it’s easier to scan when you load up a subject in order to quickly grab some info like an email address or birthday.

The re-ordered sidebar was a winner. But it came at a price. We couldn’t just change the CSS and call it a day. Now we also had to write code to re-order the sidebar modules dynamically based on whether they were empty or active. Ruby’s power and flexibility really came in handy for this job.

The code

I said earlier that people, companies, and cases are handled by the same plumbing because we abstracted them as subjects. The result of this abstraction is that whether you are looking at a person, a company or a case, the sidebar is rendered by the same template: subjects/_sidebar.rhtml.

(This kind of “view polymorphism” has been subject to a lot of internal debate since we first released the app. It makes maintenance both easier and harder because the code has less repetition on one hand but on the other it is less intention-revealing due to the abstractions and indirection.)

This is what the original template code looked like to render the subject sidebars:

in app/views/subjects/_sidebar.rhtml:

  <% if @subject.is_a?(Party) %>
    <%= render(:partial => 'parties/contact_info') %>
  <% end %>

  <% if show_company_contact_info?(@subject) %>
    <%= render(:partial => 'parties/contact_info', :object => @subject.company) %>
  <% end %>

  <%= render :partial => 'backgrounds/show' %>
  <%= render :partial => 'contact_dates/index' %>

  <% if @subject.is_a?(Kase) %>
    <%= render :partial => 'kases/parties' %> 
  <% end %>

  <% if @subject.is_a?(Company) %>
    <%= render :partial => 'companies/people' %>
  <% end %>

Don’t worry too much about the individual partials and conditions. The key point is that each partial is a sidebar module, and each module is conditioned based on the particular subject we are rendering. A different mixture of partials will be rendered depending on whether the subject is a person, a company or a case, but they’ll always render in the same order.

We want to re-order these partials dynamically based on whether each module is active or empty. That means we need to represent the possible partials, the conditions for displaying them, and also the conditions for determining whether they are active or empty within some kind of data structure. So we popped open our Rails subjects_helper.rb and represented this information in an array.

in app/views/helpers/subjects_helper.rb:

  def sidebar_modules_to_sort
    returning [] do |m|
            # partial to render       module_is_active?                 options                          render the module for this subject? 
      m << ['parties/contact_info'  , show_contact_info_module_on_top?, {}                             ] if @subject.is_a?(Party)
      m << ['parties/contact_info'  , true                            , {:object => @subject.company}  ] if show_company_contact_info?(@subject)
                                        #necessarily true per the condition at right
      m << ['backgrounds/show'      , !@subject.background.blank?     , {}                             ]
      m << ['contact_dates/index'   , @contact_dates.any?             , {}                             ]
      m << ['collections/parties'   , @subject.parties.any?           , {}                             ] if looking_at_collection?
      m << ['companies/people'      , @subject.people.any?            , {}                             ] if @subject.is_a?(Company)
    end
  end

The helper method sidebar_modules_to_sort returns a parent array full of child arrays, one for each module with an element for the template path, a true/false value to show if it is active, and an options hash for the render method. The conditions that used to determine whether each partial should be rendered now determine whether each child array should be included in the parent array. Thanks to that boolean in the second element of each child array, we can partition the parent array into two groups: those where the second element which represents that the module is ‘active’ are true, and those were that element is false. We use another helper method to partition and reassemble the array into groups.

in app/views/helpers/subjects_helper.rb:

  def sidebar_modules_in_order
    active_group, empty_group  = sidebar_modules_to_sort.partition {|m| m[1]}
    active_group.concat empty_group
  end

Finally we return to our sidebar template to do the actual rendering.

in app/views/subjects/_sidebar.rhtml:

<%= sidebar_modules_in_order.map {|m| render sidebar_module_partial(m)}.join %>

This line in the template takes the sorted array of sidebar modules and replaces each element in the array with the rendered partial. Then the join method converts each element to a string and concatenates them. sidebar_module_partial is a call to one more helper. This helper assembles the arguments for render out of the elements provided in the array. It looks like this:

in app/helpers/subjects_helper.rb:

  def sidebar_module_partial(m)
    m[2].merge({:partial => m[0]})
  end

In the snippet above, sidebar_module_partial takes the third element of each module array, which is either an empty hash or some special options for render, and merges a key specifying the template path onto that hash.

We definitely could’ve hidden these rendering gymnastics behind a helper, perhaps called render_sidebar_modules or something similar. However we’ve decided for style reasons to avoid calling render from within our helpers. Therefore we decided to use a helper to merely fill in the arguments to the call to render within the template itself.

In the end, we have a new sidebar design and some clean and intention-revealing code. This was a fun chance for me to expand my Ruby knowledge by dipping into the nuts and bolts of arrays and hashes. Thanks to Jamis for reviews and advice when I knew there had to be “a better way.” We hope you enjoy the new sidebar modules in Highrise.

Related: What belongs in a helper method?

Wanna feel ripped off today? Sign up for an online virtual service that charges a one-time activation fee. It’s a special feeling to hand over $35 for nothing.

I’d almost understand if there was actual work involved. Or hardware was manually set up. Or someone had to climb some stairs and walk down a few halls to flip something on.

But to charge me $35 to “activate” my account by adding a few records to a few databases, well, that feels like… You know what that feels like.

Some recent posts at the 37signals Product Blog:

Highrise
Top magic site thrives due to Highrise and Getting Real
“The real crux of our system is Highrise. We use it in managing projects, production, post-production, and marketing. We use it to stay organized. We use it to manage our authorized retailer clients around the world. And we couldn’t breathe as well or sleep as well without it.”

Backpack
All about tags in Backpack
A tag is a simple label or keyword you can use to categorize your Backpack pages any way you want. Then when you click a tag you can see all the other pages that have that tag. It’s a great way to keep your pages loosely grouped in ways that make sense to you.

Scottish wood floor company runs its business using Backpack
“Our first task was to store documents that we use on to our ‘Important Documents’ page. Traditionally these documents were stored on our company server but it was sometimes problematic accessing these via a VPN if we were working from home or abroad. Accessing them on the cloud via Backpack has simplified this task and we are now working faster and with less hassle.”

McKay Hardwood Flooring, a Backpack customer, installed the flooring throughout the National Galleries of Scotland.

Basecamp
Embedding a tutorial video into a Basecamp project
“I used the same idea to embed our Camtasia videos into our Tutorials project… solves a huge issue for me since before I could only add a link to the video … I have attached a image of how it looks. It was a great help.”

Subscribe to the Product Blog RSS feed.

The other day I went to sell some books at The Strand bookstore. They have a separate desk in the back for selling books. I brought in a bag and two clerks started sorting through them.

Then another guy lined up behind me. One of the clerks said to him, “You here to sell books?” He said, “Yes.” The clerk responded, “Wait in the line outside.” The guy went outside.

Thirty seconds later he was back. The clerk repeated, “Wait in the line outside.” The guy said meekly, “There is no line outside.”

The clerk sighed, looked at the other clerk, and sarcastically said, “There is no line outside.” The other clerk said gruffly, “If you can’t figure out the line, then you can’t sell books here.” The potential seller walked back outside meekly.

A minute later, a girl walked up with books. “Wait in the line outside,” said the clerk again. She walked outside. A few moments later, she was back. “What are you doing?” She said, “Selling books.” He said, “The line is outside.” She walked outside again. The clerks laughed. “Let’s see if the Mensa society out there can figure out how the line works!” And they laughed some more. As if both these customers were complete morons.

Lucky for me, I had arrived moments before these other two. Because I sure had no idea there was a place outside to wait in line. Or that “there’s a line outside” actually means “form a line outside.”

I think a lot of people who work in customer service make a similar mistake in laughing at customers or making fun of them behind their backs (PEBKAC comes to mind).

It can be a dangerous trap. Sure, any one customer might be stupid. But if multiple customers are repeatedly making the same mistake, maybe it’s not a mistake on their part. Maybe it’s a mistake on your part. If no one can figure out where to wait in line, maybe that’s a sign that you’re not doing a good enough job explaining it.

I’ve been poking around a lot of architects’ web sites lately and I’m thoroughly surprised at how bad they are. It seems almost without fail that they are either blowing my browser window up full size, asking me to read light grey 9px text, overflowing with obfuscatory flashterbation, teasing me with custom designed scrollbars that don’t behave as you’d expect, or asking me to evaluate their work based on postage stamp sized photographs. It really feels like 1998. I see I’m not alone in this observation.

Architects have so much to gain from the web. Big huge photographs of their work, clear statements of who they are and what they believe in, easily linkable and sharable portfolio pages, daily links of interest.

As it stands today, if you want to show someone an interesting piece of work you usually have to give them a step-by-step guide on how to get there: First go to the home page, wait for the countdown timer to expire, then hover over the logo, then grab a magnifying glass, then squint, then click the 4th tiny icon on the left (I can’t really tell what it is), then use that custom scrollbar that looks like an elevator, then take a screenshot, then pull that screenshot into Photoshop, then zoom in about 8 times so it’s all nice and big on your screen, then take about 10 steps back from your computer, then look.

I’m only half kidding.

Come on, architects, get with it! Anyone got any links to a great architect’s site that bucks this trend?

The next 37signals Live will be tomorrow, August 26th at 11am central time.

The first two Live shows were general Q&As. This time we’re going to narrow down the focus to chapter 13 of Getting Real: Promotion. Generating buzz, getting press, promotion without a budget, launch, etc.

Come armed with questions and we’ll fire back answers. We’ll see you tomorrow at 37signals Live!

“How Design Can Save Democracy” is AIGA’s attempt to identify common design problems in election ballots and offer improvements.

Problem (excerpt)

Solution (excerpt)

More details.

Is it an improvement? Sure.

But the real crime here is how terrible the original one is. Looks like a bunch of lawyers trying to figure out Quark. It’s tough to have much faith in your government’s ability to solve truly complicated challenges when it seems so inept at dealing with relatively simple issues. Hasn’t this been a known problem for eight years now?!

It’d also be interesting to see what ballots look like in other parts of the world.

Update: Julien links to this can’t miss ballot used in Quebec.

For the unenlightened, Git is a distributed version control system that’s recently taken the software development world by storm. It’s what we use to manage all of our source code at 37signals. GitHub is an online service providing Git repository hosting and collaboration tools (we featured them recently on the Product Blog).

Rails, Capistrano, and Prototype are already hosted on Github, and we’re going to be releasing some of our internal libraries and plugins there as well. Feel free to follow, fork, clone, and contribute!

Darden Studio
Even though it works like typical lightboxes, the lightbox at Darden Studio (example) feels different due to design choices the firm makes.

The loading screen has custom typography centered on a black bezel:

And then check how using a non-browser typeface, including the x on the upper right, and the arrows in the lower right spice up the design of the lightbox itself.

ShoeGuru
ShoeGuru makes shoe shopping elegant.

Cymbolism
Cymbolism is a new website that attempts to quantify the association between colors and words. You can search for a word and see what colors people associate with it. The goal is to “make it simple for designers to choose the best colors for the desired emotional effect.” Here are the results for the word spring.