You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !

Ryan

About Ryan

Ryan's been getting to the bottom of things at Basecamp since 2003.

Features are a one-way street

Ryan
Ryan wrote this on 55 comments

Here’s another reason to double, triple, quadruple-check yourself when you want to add a new feature. A while back Netflix added a “Profiles” feature to their service. A couple weeks ago, they decided to pull the feature because it was too confusing and it wasn’t adding value. But it was too late. People were pissed. The blog post received 1286 comments. In the face of this reaction, Netflix had to turn 180 and keep the feature. Whether Netflix Profiles are good or bad, clear or confusing, they’re here to stay.

The lesson: Once your user base has grown beyond a certain point, you cannot take features away from them. They will freak out. Whether the feature is good or bad, once you launch it you’ve married it. This changes the economics of feature additions. If you can’t destroy what you build, each addition holds the threat of clutter. Empty pixels and free space where a new feature could be added are the most valuable real estate on your app. Don’t be quick to sell it, because you can never get it back.

Fresh UI ideas from Songza and Algorithm Ink

Ryan
Ryan wrote this on 19 comments

Aza Raskin released a new project today called Algorithm Ink. For the full story check out his explanation and video. The app is basically a “grown up version of Logo”—a front-end to a simple programming language for creating fractal images. While the fractal art is the main attraction, I was more interested in the unconventional UI.

Algorithm Ink continues the style that Aza demonstrated six months ago with Songza. His UI comes from another planet where Microsoft Windows never caught on and Hypercard rules the world. There are no native form widgets, no scroll bars, and nary a “ or Cancel” in sight. Normally this is a recipe for confusion, but in Aza’s case the results are often models of clarity and intentionality.

On Songza, the most noticable break from convention was the mouse-flower. Traditionally, a web UI for playing a song would consist of the song’s title, a widget to play/pause, and some adjacent links to share, rate, etc. Instead Songza only shows the song title. When you click the title, a flower opens with an action on each petal like “Play” or “Share.” You can click a petal or mouse away from the flower to dissolve it. The jury’s still out on mouse-flowers, but the clutter-free UI they enabled should raise an eyebrow.

On Algorithm Ink, the header is what interested me. Each of the grey buttons (Edit, Save, Browse, etc.) is actually a toggle between an “on” state and an “off” state. When a button is “on”, a panel appears on top of the canvas with the functionality for that button.

The grey buttons toggle overlaying panels

For example, when you click “Edit”, the button turns on and a panel is revealed with the code for the current artwork. You don’t “Save” or “Cancel” to leave edit mode. Instead you click the red “Draw” button to apply your changes, or click Edit again to hide the panel.

The Edit button is on and the panel is visible

Each of the buttons has its own custom panel. Edit displays a long narrow sidebar, while Save displays a thin horizontal strip. It’s note-worthy when different features of an app actually look different. We’re all guilty of leaning on our templates to the point that each screen in our apps looks a bit like the others. In Algorthim Ink, the Edit mode is tall and narrow. The Save mode is wide and thin. These differences give the app character and also help users develop a kind of “muscle memory.” They can remember the screens by shape as much as by name.

The Save button is on and the panel is visible

My favorite thing about these grey buttons is that they don’t just turn panels on and off. They also exclude each other, so that if you are using the Edit mode and you click the Save button, the Edit panel will disappear and the Save panel will replace it. You could say the buttons are “mutually-exclusive modes”. A simpler way is to say they act just like tabs.

Look closely at how a typical tabbed interface works. You click a tab, and the whole screen reloads to a new screen. The tab bar on the new screen has the same options and position as the old screen, except the tab that you clicked changes appearance to indicate that you are “on” this tab to the exclusion of the other tabs.

In Algorithm Ink, the buttons work in exactly the same way. Except there’s a twist. The “tabs” (grey buttons) don’t replace the screen, or even replace part of it. Instead they hide and reveal panels which overlay a single screen that never changes. Your art never goes anywhere, but the panels which allow you to perform actions come and go.

These overlay tabs may not be as eye-catching as a mouse-flower, but I think they’re very interesting. It’s hard to put my finger on what exactly I like so much about Algorithm Ink, but it’s plain to see that the approach is different. And in our current UI climate, well-executed difference is itself enough to deserve some thought.

What belongs in a helper method?

Ryan
Ryan wrote this on 33 comments

I’m working on some improvements to Basecamp, specifically the screens where you manage which people have access to a project. There’s an area on our new template with checkboxes beside peoples’ names so you can check which people should be added to your project. I want to apply a class name to the label tag around the checkbox for each person. So I pulled up the template and searched for “label” to find where I might add the class name. There were no matches. So I dug deeper, and saw that the HTML for the label, checkbox, and person name is being generated by a Rails helper method.

This is the template code that calls the helper method.


<% people_without_access_from(company).each do |person| %>
  <%= add_person_to_project_check_box(person, company) %>
<% end %>

Next I pulled up the helper method to see if it really is responsible for producing a chunk of HTML with the label and checkbox.


def add_person_to_project_check_box(person, company)
  content_tag(:label,
    check_box_tag("people_ids[]", person.id, false, { :class => "company_#{company.id}_person" }) +
    " " + person.name
  ) + tag(:br)
end

Yup, it’s generating the HTML. Right away this smells bad to me. The helper is first generating a label tag. Inside that label, there is a checkbox followed by a space character and the person’s name. Finally a break is appended after the label. This smells bad for two reasons. First, it’s just not so nice for helpers to cook out HTML when they don’t have a good reason to. Second, it’s harder to locate and change HTML when it’s hidden inside a helper.

Returning to my original goal, I wanted to add a class name to the label around this checkbox. If I add the class name to the existing helper, it’s going to get even more messy and complicated because I have to give content_tag an attribute with the class name I want. It would look like this:


def add_person_to_project_check_box(person, company)
  content_tag(:label,
    (check_box_tag("people_ids[]", person.id, false, { :class => "company_#{company.id}_person" }) +
    " " + person.name
    ), :class => 'checkbox') + tag(:br)
end

To find a better solution, we should rethink what the helper should be responsible for. Helpers are useful when they hide complexity that isn’t relevant to the template. Looking at this helper method, I see that it’s useful to hide away check_box_tag with all those params. But the label, the break, and even the person’s name could all be in the HTML and the template would be clearer. Let’s do that.

Here’s the new helper. Now it only produces the checkbox.


def add_person_to_project_check_box(person, company)
  check_box_tag("people_ids[]", person.id, false, { :class => "company_#{company.id}_person" })
end

And here’s the updated template code, with the label, person name, and break moved over.


<% people_without_access_from(company).each do |person| %>
  <label class="checkbox">
    <%= add_person_to_project_check_box(person, company) %> <%= person.name %>
  </label><br />
<% end %>

Now that’s a lot easier to read. Generally speaking, it’s a good idea to keep your HTML in your templates and out of your helpers. Helpers are useful when they hide implementation details that are irrelevant to your template, or when they allow you to abstract common template code to avoid repetition. If you find yourself generating a lot of HTML in a helper, think twice and try to keep as much HTML in your template as possible.

Generous link targets in the library

Ryan
Ryan wrote this on 12 comments

I love me some padded link targets and today’s provider is a Working Library.

The site is about books and their connections. Each post references one or more books and the referenced books are aggregated in the right-hand sidebar. When you hover over a book title, the crisp tiny type is immediately enveloped in a big cozy hover block.

I particularly like how the hover reinforces the column dimensions. It’s a sudden punch of structure to the otherwise airy layout.

(Found via JSM’s oddities)

Designers who also develop have more power

Ryan
Ryan wrote this on 54 comments

Alan Taylor of The Big Picture proves how designers who can also develop are able to get things done without jumping through hoops of approval, explanation, and cycles of review.

In an interview at Waxy.org, Alan talks about how The Big Picture came to life within the Boston Globe.

I have an advantage in that my main role is as a developer here, so I could build all my own templates, format my own style, and so on. I sort of bullldozed some things through though, like extra width, few ads, and I made it simple internally by doing it mostly on my own, no requests for development time, marketing or promotion. After the legal questions were settled, I was free to try it out. It took off fast.

This is another example of why I strongly advocate that designers build development skills into their kit. When you’re able to do things yourself, you can just do them. You don’t need anybody’s approval or anyone else’s time. And sometimes that makes the crucial difference between an unimplemented idea or a great success like The Big Picture.

Patience as a design principle

Ryan
Ryan wrote this on 8 comments

One of my intellectual heroes, Ronald Langacker, recently released a new book which summarizes his 30-year-old program of Cognitive Grammar, a radical and insightful approach to understanding language. In the very beginning of the book, Langacker outlines three principles which guide his work.

Integration means his explanations about language shouldn’t stand alone from our understanding of how the brain works or how psychology works. He wants his analyses to fit with neighboring disciplines instead of standing in their own tower.

Naturalness is his second principle. It means that a really good explanation should be reasonable and understandable. If an explanation is arcane, artificial, or exotic, it’s probably wrong.

Patience is an unexpected final principle. Being sure not to put the cart before the horse, it means withholding judgment on questions that are premature. As software designers, this means developing a “wait and see” approach that doesn’t indulge in too much speculation. Most feature ideas are speculative. “Wouldn’t it be cool if (x)” is very different from saying “for the last two weeks I’ve been frustrated by (y).” Having patience means putting speculative ideas on a shelf until actual life experience proves they have benefit. Launching a product with “too few” features is a kind of patience. Keeping your team small is a kind of patience.

At 37signals, we focus on lean features, short iterations, quick wins, small improvements, and the satisfaction of “build and release.” Paradoxically, all this quick movement and quick satisfaction rests on a foundation of patience. Most of our ideas are never implemented. Our products are never finished. Doing what’s in front of your nose, doing smart work that makes an impact today and leaves space for changes tomorrow takes patience. I’m glad Langacker’s book pointed this out.

Ryan talks design on the Rails Podcast

Ryan
Ryan wrote this on 11 comments

I just got back from RailsConf in Portland. It was really fun to be a designer among a sea of programmers. I spent a lot of time talking to programmers about what designers do on a Rails team and how we should work together. A number of those ideas worked their way into an interview with Geoffrey Grosenbach of PeepCode. Listen to the podcast at Rails Podcast.

UPDATE: Here are some quick video interviews with Ryan, Jeremy, and David from RailsConf 2008.

Ryan Singer


Jeremy Kemper


David Heinemeier Hansson

Padded link targets for better mousing

Ryan
Ryan wrote this on 44 comments

Among the minor tweaks we introduced with the new Basecamp project switcher are some larger link targets at the top of the screen. Since then I’ve been paying extra attention to link target size. Here are a couple examples of generous link targets for inspiration.

Threadless has featured large link targets on its main navigation for a long time. Here’s what the nav looks like:

Threadless links

As a user, when you glance at this nav, you might imagine the specific pixel areas that you need to target like this:

But when you move your mouse toward the nav, you’ll be pleased to discover the actual link targets are much larger:

The end result is a feeling of comfort. It’s just really easy to click the links. It feels like the links are working with you instead of against you.

Flor does the same thing with their links. Here’s the navigation:

Here are the targets you might aim for:

And here are the actual targets:

You might have noticed both of these sites use images for their navigation links. The same effect is easy to achieve with HTML links. Just use padding where you might have had whitespace.

Normally you might have white space between your links like this:

<div class="nav">
  <a href="">First link</a> <a href="">Second link</a>
</div>

Instead, use clickable padding on the anchors to create space between them:

<style>
  div.nav a { padding: 5px; }
</style>

<div class="nav">
  <a href="">First link</a><a href="">Second link</a>
</div>

Note how the anchors touch each other with no white space in the second example.

We do this in quite a few places in our apps and think it’s one of those small things that makes a big difference.

Think about paths instead of hierarchies

Ryan
Ryan wrote this on 29 comments

I’ve been re-exposed to “industry” web design practices while staying with some friends in Germany who work at a large agency. In particular, I’ve seen that hierarchical navigation and site organization tactics are no distant memory. A lot of clients still come to the table with an org chart and ask their designer to implement the same structure on their website. The result is a website that reads like an office directory in the skyscraper lobby. Or the hierarchy approach can lead to terms that simply block customers from finding what they want. For example, my friend did some work for a shoe company who wished to hide six different kinds of shoes behind a gate called “Performance”. When my friend asked 40 uninvolved people in his office what the category “performance” meant to them, only 10 had even a vague idea. So hierarchies have their problems. What other organizing methods could we consider instead?

Instead of thinking in terms of hierarchy or up-front structure, I think it’s better to work with paths. A path is a line that goes from a starting point A to an accomplishment B. Each customer who comes to the site doesn’t care about the overall structure. They care about getting from A to B. That’s a path. Where are your golf shoes? That’s a path. Does my cell phone support international calling? That’s a path. Collect all the paths you can think of in a pile, pull out the 8 paths that 80% of your visitors come looking for, and that’s your home page. When paths overlap or the same customer needs them, weave them together. Add the occasional fork. DRY out paths with lots of overlapping information for efficiency. These operations feel concrete, and they connect directly with customer goals instead of organizational box drawings or hand-wavy concepts.

Lines are better than boxes for mapping the contours of your domain. So next time you work with a hierarchy-minded group, try to pull them out of the boxes and talk with them about individual starting points and goals for their customers.

Why do we plan up front?

Ryan
Ryan wrote this on 27 comments

Buying my first place has been a really educational experience. I posted earlier about how I got boxed in with paint colors. Today I reflected on another lesson. When it comes to software development, I always try to follow a step-by-step approach. Mock something simple, see how it feels, decide what to do next. Rinse and repeat, and let the design unfold. It’s a slow game of patience and confidence, and I swear by it for the best results.

Why then, am I doing the exact opposite with our condo? We still haven’t closed, and I have a precision scaled floorplan in Illustrator full of furniture arrangements. I have a Backpack page detailing the exact sofa, sideboard, console, shelving, and landing strip gear. It’s a master plan with every piece fitting into the puzzle. And I haven’t the faintest idea if I’ll actually like it all.

I know I’m doing it all wrong. I should go to the real space and start with one thing. Pick the perfect sofa, put it in the living room, and feel it out. What is needed next? What would compliment the room now? What’s the next-most-important thing? My top-down plan is the total opposite of such a sensible bottom-up approach. So what’s going on here?

Here’s the secret: Uncertainty. It’s the same reason why so many people balk when we tell them to throw their functional spec out the window. I care so much about the design and feel and function of my condo-to-be that I can’t stand the uncertainty of not knowing how it will turn out. I want to know NOW so I can stop worrying about it. And of course, it’s impossible to really know what the best design will be without actually building the real thing step by step. But still, I don’t want to wait for such realities. And so I plan, and I plan, and I plan.

Plans are a strategy against uncertainty. The problem is, they only make you certain of your imagination. I’m lucky enough to know that my plan is a nervous occupation, not something I’ll follow. I haven’t purchased that sofa, that sideboard, or those shelves yet. And the next time someone furrows their brow when I tell them to slow down and go step by step, I’ll remember the feeling.