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.

It’s the small touches that won me over. Well designed, a bit of attitude, and useful.


App store reviewer Jragon on Sketches. Should good software have ‘a bit of attitude’?

Rails tip: Use subdirectories to namespace images by resource. Eg. images/people/add.gif vs. images/add_person.gif.

How to manage long breaks in your software side projects

Ryan
Ryan wrote this on 22 comments

Pablo Corral wrote me an email after I posted this tweet about managing on-again-off-again side projects.

I’m very curious about how to use Backpack to have a better experience on braindumps for side projects.

I switch a lot, and my side project sometimes is off for many days, and some weeks. Can you explain more about this?

It’s hard to find steady uninterrupted time for software side projects. Maybe you only have time on weekends or the occasional free night for your project, and sometimes weeks or months go by where you are too busy to sit down and make some progress. When you finally do find time to work, you can waste half of it just catching up on where you left off.

This has been a big challenge for me because one of my projects is a Rails app that supports registration and administration for a biannual retreat course. Four or five months may go by before I return to the app for another course, and with each course there are new bugs to fix or feature requests to implement. A couple years in this situation have helped me develop a system to manage my side projects with a minimum of headaches and wasted time.

My system is a one-two punch: Hosted version control plus a single Backpack page. These two are all you need to keep the state of your project off your brain and at the ready.

First punch: Hosted version control

Sign up with a hosted version control service like GitHub for Git or Beanstalk for Subversion. I advise using version control even for static websites.

There are two key benefits to hosting your source with these services. First, your source is independent of your work machine. If your machine crashes, you replace it, or even if you space out and delete some things you shouldn’t (that would be me), your code will always be safe and secure in the online repository.

The second benefit is an easy-to-read commit log. With one click you can visit a bookmark and see a timeline of changes you’ve made to the code in chronological order and in your own words. Just glancing at the commit log can be enough to jog your brain after a long absence and bring you right back into the project.

Second punch: A single Backpack page

I make a single Backpack page for each project with two lists and some notes. The two lists are ‘To-Do’ and ‘Debt.’

Continued…

Behind the scenes: Redesigning and coding the Highrise sidebar modules

Ryan
Ryan wrote this on 26 comments

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.

Continued…

Modal overlays beyond the dialog box

Ryan
Ryan wrote this on 32 comments

Aza recently posted on modal overlays, those dialogs that pop up and disable the background behind them. You can click anywhere inside modal overlays, but you can’t click anything in background until the dialog goes away.

Usually when we think of modals, we think of dialog boxes like the one below from Google Documents. Aza’s critique applies to this kind of modal. After you call up the find/replace box, you can’t click anywhere but inside the dialog. That means you can’t scroll the document underneath the dialog or copy and paste a word from the document into the dialog box while the dialog box is displayed.

But that’s not the only kind of modal overlay. Check out this Preference pane from Apple’s Me.com. It has nothing to do with modifying the content behind it. It could just as well be a separate screen.

Actually, this fact that it could be a separate screen caught my interest. At 37 we never use modal overlays. All our settings screens are completely independent from the other screens in the app. In order to explore the difference between these two approaches, I mocked up an alternate version of Apple’s preference screen that fills the entire window like a typical web app might.

Continued…

New color picker in Basecamp

Ryan
Ryan wrote this on 33 comments

Creating color schemes in Basecamp just got easier. Before, you had to understand complicated hex codes to customize your colors. Now anybody can choose colors with a shiny new color picker. Kudos to Sam for the extra attention to detail on the color picker. We think it’s solid and it’s the best color picker we’ve used on any web application. Picking colors in Basecamp is a lot of fun thanks to the live feedback, so load up your Settings tab, click “Color Scheme” and take it for a spin.

New in Basecamp: Updated People and Permission screens

Ryan
Ryan wrote this on 12 comments

Today we released some improvements to the People and Permission screens in Basecamp. We’ve improved the process for adding new people to a company within a project and we redesigned the Permissions screen with a number of subtle usability improvements. You’ll also find a new Administrators screen to easily control which people in the account holder’s company have Administrator powers. Check out the video below to see the changes.

The redesigned Permissions screen wasn’t really a redesign. 90% of the screen looks and works the same. We worked a lot with subtle changes in text size, positioning, and color in order to bring more clarity and spaciousness to the screen.

Here’s the old version:

And the new redesign:

Continued…

Soundcloud expands the audio player

Ryan
Ryan wrote this on 16 comments

Most embedded audio players offer a tiny player with the basics: play/pause and a progress bar.

While this design works great for the casual listener, Soundcloud has another audience in mind. Musicians, producers and sound engineers want to do more than listen to a track. They want to provide feedback on specific details. The bass at 2:36 needs more compression. There’s a mic out of phase at 4:01. Can we try another patch for this one chord in the bridge?

In order to allow this kind of collaboration, Alex and the guys at Soundcloud could have used a standard player and tossed a comment stream below it. Instead they decided to expand the player and allow commenters to add notes directly inside on the waveform itself. The result is pretty cool. People can post tracks and receive a flurry of comments attached directly to the waves.

The player spans the full width of the screen, so it’s easier to set the playhead at the exact spot you want. Commentor’s avatars appear in the bottom of the player, and their comments pop up on hover.

I like how these guys set out to build a collaboration site for music makers, and what did they concentrate on? The music player. It cuts straight to the epicenter (more).

They also scratched my persistant itch for larger link targets in their “Actions” section of the sidebar:

Soundcloud is still in private beta, but Signal vs. Noise readers can check it out with this link: http://soundcloud.com/guestlist/signalvsnoise .

Learning from "bad" UI

Ryan
Ryan wrote this on 90 comments

When Gruber first linked the TripLog/1040 UI by Stevens Creek, I wasn’t kind either. Bright colors, controls seemingly placed at random. It was the opposite of what designers strive for in our circles. A mess. Soon the Flickr page was a schoolyard of insults. And then something interesting happened. TripLog’s designer Steve Patt posted a comment amidst the bile to share the rationale behind his design. The many who chose not to listen to him won’t learn anything, but the rest of us may find fruit in Mr. Patt’s thoughtful explanation and twenty years of software experience.

The first charge against TripLog is “clutter,” that there’s too much on the screen at once. We’ll get to clutter, but first we have to talk about speed. Patt explains that the #1 purpose of TripLog is to help people track their deductible or reimbursable mileage. If people can’t enter their trips very quickly, the friction of entering data will overpower the motivation to track. For customers, untracked data means miles that aren’t reimbursed. So speed is Patt’s top priority.

What does speed have to do with clutter? I once saw Tufte give a workshop in Chicago where he introduced a valuable concept. He said information may be displayed adjacent in space or stacked in time. Take a book for example. If two dots are on the same spread, they are adjacent in space. All it takes to switch between them is movement of your eye. Compare that to a dot on one page stacked above a dot on another page. You can’t see them at once. You have to flip back and forth between pages to see one dot versus the other.

The trade-offs between elements adjacent in space versus stacked in time are always in the mind of a UI designer. Placing many elements on the same screen reduces the need for navigation and gives users a comprehensive feeling of “it’s all at my command.” Moving focus from one element to another is instant and seamless. On the flip side, separating elements onto different screens slows things down with navigation while increasing clarity. There is more room for explanation and luxurious space when fewer elements occupy the page. The eye has less to filter through. The course of action is more obvious.

So did Patt put too many elements adjacent in space on one screen when he should have separated them out in time? Is his UI “cluttered?”

Continued…