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

Signal vs. Noise: Design

Our Most Recent Posts on Design

Crossing Streams

Jamie
Jamie wrote this on 16 comments

When I switched to Android a few years ago, I promised myself this: I’d switch back the minute Apple added smart notifications, app data sharing, widgets, and a better keyboard to iOS.


Apple’s WWDC keynote yesterday was exciting. Craig Federighi is super awesome (I wanna hang out with him). iOS is finally getting the Android features I love. Yesterday I was ready to switch back, but now I’m not so sure.
Some iOS fans have pointed to Google’s Android as being a poor copy—thermonuclear theft. On the surface there are similarities, but conceptually Android started from a power user’s perspective. Where Android had power features it also lacked in the simplicity and obviousness of iOS. Simply because iOS did far less.
Yesterday Apple showed iOS doing a whole lot more. Apple is refining iOS by layering on functionality. They’re adding features to the simple iOS foundation. However, the more features there are, the more complicated it becomes—and the harder it is to use.

Meanwhile, Google has done something interesting with Android. It started out as a very power-user complex platform, but they’ve been refining it in a different way than Apple. Instead of adding features, they’ve pruned them. Historically Google hasn’t been afraid to nix apps or services in an effort to focus and simplify. You can see these efforts in Google Now. With Google Now you don’t interact with apps or widgets. Their “cloud” knows what you want to know and tells you. No interaction needed.


It’s always harder to take away features that are already there. But, I have no doubt Apple will try to continue making iOS easy-to-use while they layer on new power user features. At the same time, Google’s not afraid to take away features. Maybe Google will keep simplifying Android, pushing all you need to know from their sentient “cloud”.
I’m curious to see what happens next. But, I’m not switching back to iOS just yet.

It's OK not to use tools

Jonas Downey
Jonas Downey wrote this on 54 comments

Recently I did a little side project to improve the website for a non-profit animal shelter in our town. The existing site was an outdated Microsoft FrontPage menagerie, so basically anything I did would be a big improvement.

I spent around 20 minutes creating a simple design in HTML, and then several hours editing, rewriting, and refining the copy. In the end, I reduced a scattershot 25-page website down to about 8 focused pages written in a friendly tone.

My next instinct was to apply our great modern web toolset to the site. Let’s add a static site generator or a CMS! Let’s add Sass and a grid system! Let’s do more fashionable things!

Then I started looking at those tools critically. A static site generator usually requires knowing Markdown and esoteric commands and configuration. A typical CMS will need setup, logins, security patches, templates, and maintenance. Even hosted CMSes have a lot of cognitive overhead, and the content is trapped away inside someone else’s system.

These are tools made by geeks, for geeks. Why do we need a CMS for an 8-page site? And for that matter, why even bother with Sass? Regular old CSS can do the job just fine.

Who knows who will take over the site in the future. I’ll hang with it for a while, but someday someone else might have to work on it. It would surely be easier to do that with 8 simple, straightforward HTML files than with some custom WordPress installation that’s several versions out of date. So what if I have to repeat the navigation markup 8 separate times? It’s not that hard. We used to do it for much larger sites!

Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?

As builders, we like tools and tech because they’re interesting and new, and we enjoy mastering them. But when you think about the people we’re building for, the reality is usually the opposite. They need simple designs, clear writing, less tech, and fewer abstractions. They want to get stray animals adopted, not fuss around with website stuff.

Remember when the web was damn simple? It still can be. It’s up to us to make it that way.

jeepsubject.png

I really like Jeep’s text-based 7-bars + headlights subject lines in their marketing emails. Fun touch.

Jason Fried on May 14 2014 3 comments

Responsive design works best as a nip'n'tuck

David
David wrote this on 15 comments

It’s pretty amazing how far you can take responsive design these days. Between the latest CSS tricks and a splattering of JavaScript, you can turn an elephant into a mouse, and make it dance on a parallax-scrolling ball. It’s time to reconsider whether you should, though.

There’s a point on the trade-off curve where rearranging everything, hiding half the page, and then presenting it as “the same template, just styled differently” is simply not meaningful. Nor is it simple. Nor is it efficient. A one-size-fits-all HTML base document is not a trophy-worthy accomplishment in itself, lest we forget.

The way we think about this at Basecamp is as a nip’n’tuck. If you’re just stretching or shrinking things a bit, then responsive can definitely be easier (we do that on this blog, for example). But the further you move towards a full make-over, the less it makes sense.

This is particularly true if your framework of choice doesn’t make it needlessly complicated to use separate templates for separate purposes. Rails 4.1 has a feature called variants that makes it trivial to share the controller and model logic of your application, but return different HTML templates when the devices call for it. It’s this feature we’re using for the Basecamp mobile views (which in turn are embedded in our mobile apps) instead of the prevailing responsive paradigm.

By going with dedicated templates, we don’t have to include needless data or navigation that’s going to be hidden by the responsive rules. We have less variables to think about on the individual page. It’s just a simpler workflow where it’s easier to make changes without considering a smather of side effects.

So the next time you’re marveling at a responsive design that’s able to make the best use of a 27” iMac at full screen and a fit neatly on a 3.5” iPhone as well, you might want to ask yourself why you’re trying to make one performer do so many tricks.

audioicon.png

Great UI in Chrome here… I had about a dozen tabs open, and some audio was playing. It was an auto-play ad, so I didn’t initiate it and I didn’t know where it was coming from. I happened to look up in the tab bar and spotted a little speaker icon in one of the tabs (see the middle tab in the photo). I clicked it. Sure enough, that’s where the sound was coming from. When the video ended, the little speaker icon went away. Great little touch that answers a common question… “Where’s that sound coming from?”

Jason Fried on Apr 24 2014 11 comments

Reading the difference

Claire Lew
Claire Lew wrote this on 2 comments

“All that work, and that’s it?”

I remember thinking this to myself a few weeks ago. I’d been building a new homepage for Know Your Company. But I didn’t feel I’d made much progress.

I’d rewritten copy, collected stories from current customers, designed several new pages, made the site more mobile-friendly…

Yet despite these changes, the site didn’t look much different than before. I began to question if I’d accomplished much at all.

Luckily, as I started to feel this way, I happened to be chatting with Jonas, a designer at Basecamp. He’s also the original designer of Know Your Company, and has helped me transition the product into its own company.

Jonas said this to me:

“Claire, go read what the homepage had before.”

I went and did that.

“Okay. Go read it now with your changes.”

I went and looked at my new site.

“See? Before, people looking at your site didn’t know what customers thought about your product. Before, they couldn’t request a product demo as easily. Now, your revised design helps people do those things. So don’t get discouraged because your design doesn’t look different. If you read it, you’ll see it’s much better than it was before.”

What a great reminder.

I’d forgotten my progress simply because it didn’t look different. When you just look at the difference, you might not see much. Text looks like text, regardless of what it’s saying. But if you read the difference, you see how big your changes actually are.

Progress isn’t measured by how different something looks. It’s measured by how useful something has become. Is it making this person’s life easier? Is it doing the job you want it to do? Reading the difference, not just looking at it, reveals your progress.

So the next time you doubt how much progress you’ve made, don’t look at the difference. Read the difference.

You’ve probably accomplished more than you give yourself credit for.

Basecamp goes back to basics

Jonas Downey
Jonas Downey wrote this on 11 comments

If there’s one thing everyone can agree on, it’s that computers and user interfaces peaked in the 1980s. Everything was clear and simple, without all of our modern annoyances like portability, color, touchscreens, and the Internet.

With that in mind, we took a long, hard look at Basecamp. We asked questions like:

  • Is Basecamp as simple as it can be?
  • Should we make Basecamp less colorful?
  • What if Basecamp was stored on 800kb floppy disks?
  • When is Knight Rider starting?

So today, after months of work, we’re excited to announce that Basecamp is going back to basics. We’ve rolled out an update to all our users that’s available right now. Just visit Basecamp in your web browser, and type the code dogcow to get a sneak preview of our new direction. We think you’re going to love it.


Basecamp’s new system requirements:

  • Macintosh System 6 or higher
  • 512kb of RAM
  • 800kb floppy disk drive
  • 1200bps dial-up modem (recommended)

P.S. refresh your browser to exit the preview.

Drawing Trouble

Nate Otto
Nate Otto wrote this on 13 comments

One of the fun aspects of illustrating for the new basecamp.com marketing site is getting assignments from Jamie, Jason, and Mig. One of my favorite briefs I got was “can you illustrate browser trouble?”

Upon getting art requests, I usually search to see if there’s a standardized image for the concept. In this case I didn’t find any imagery that rose to the level of iconic, or was particularly interesting or clear. I opted to start from scratch.

Hmmm, browser trouble

Broken windows, bugs, injuries, cracked screens, dizzy people? I drew a page of visual brainstorms and posted it on our Basecamp project.

Whoever assigns me a drawing—in this case, Jamie—reviews my explorations and then ask me to flesh out one of the directions. Jamie liked the guy with the computer head and suggested that there be a browser window with a frown face.

I drew up another page with color.

With that, Jamie got back to me with “Awesome.”

I waited to see how the image would be implemented. Working with the Basecamp design team is great for me because I’m not particularly strong in Photoshop or Illustrator—those guys are all ninjas. I like to draw, and that is how my time is spent most efficiently.

Usually I have no idea how the images are going to be used until they are implemented live on the website, which is fine by me. I like the surprise of finding a fully rendered web page with my drawings.

Hopefully it is a page you will never have to find.

Yelp's nice settings toggle

Jamie
Jamie wrote this on 5 comments

Yelp updated their Privacy Policy so now businesses can get some insight on their customers. The nice thing is Yelp gives you a preview of how your information would appear to these businesses.

You can Change Privacy Settings to toggle between how much info you want to reveal. As a Yelp user I’m not passive in this. I’m given a choice. I thought this was a pretty cool interaction—a nicely done modal.

Join our team: We're hiring a product designer.

Jason Fried
Jason Fried wrote this on Discuss

We’re looking to add another product designer to our team! We don’t hire for this position often, so we really savor moments like these. We’re eagerly anticipating hearing from you.

Besides design, your job is to make an undeniably positive impact on our company, our culture, our products, and our customers. As long as you make your best effort, and you love to learn, we will do everything we can to support you creatively and help you do the best work of your life.

Product designers at Basecamp are always working on different things. You may be working on polishing up an existing feature, pitching and designing something brand new, or fundamentally rethinking how we do something. You could be working on the web or you could be exploring designs and interactions for a native mobile app. Projects at Basecamp always start with design, so you’ll constantly have the opportunity to lead us in new directions. Challenge us! Push us! Be original and show us the way!

Besides having great visual taste, talent, and the right sensibilities, you must write well-structured HTML/CSS. Basic Javascript or Rails skills are a plus, but not required. Experience designing for iOS and Android is also a plus. Great writing skills are required.

We are not looking for someone who’s already expert in everything they do. We’re looking for someone great who demonstrates the interest, drive, and desire to keep learning new things and continually get better.

At Basecamp you’ll be working with great people. Friendly, talented, original folks from dozens of cities around the world. The people who work here have a wide variety of interests and interesting life experiences. You’ll have a chance to learn from some of the best people you’ve ever met. And we’ll get to learn from you. We’d love for you be part of our patchwork.

Working as a product designer at Basecamp is a unique opportunity. We have a small team, so you won’t be one of dozens. You’ll be one of a few, so your impact will be felt inside and outside the company. You’ll be working on a product that is used by millions of people. You will help drive us in new directions. You’ll help us see things we haven’t seen before, consider things we’ve never considered before, and bring fresh perspective to our team. Brighten us up and put a big smile on our customers’ faces.

You love to write, too. You understand that copywriting is design. The words matter as much as the pixels. Great visuals with weak words are poor designs. You should care about how things are phrased as much as you care about how they look.

We’re open to hiring the best person no matter where they are. If you’re in Chicago we have an open desk for you in our office. But more than half of our company works remotely all over the world, so you’re welcome to be part of the team no matter where you live. If you do want to relocate to Chicago we’re open to that as well.

How to apply

Send relevant work samples, and anything else that will make you stand out, to jason@basecamp.com. Extra effort and personal touches will be looked upon favorably. Show us how much you want this job and not just any job. Please include [DESIGN] in the subject of the email.

It doesn’t matter where you went to school, or if you even graduated. It doesn’t matter if this is your first job or your fifth. Doing great work and being driven to improve yourself and everything you touch is what matters.

If we think you’ll be a good fit, we’ll be back in touch with step two of the application process.