Yesterday we announced the official Basecamp app for iPad. Just like our other apps for iPhone, Android, and Kindle it’s a hybrid—a native wrapper around a mobile web core. We’ve written about this setup before but today I wanted to really get into the details to show how it all works and how we’ve been able to launch four distinct apps with a handful of developers, just 5 people in all.

How it works

Basecamp has variants for desktop, phone and tablet. Desktop is the default browser experience we launched in 2012. When it detects a mobile device or a native app declares itself, Basecamp renders the phone variant. The phone variant has its own set of templates and its own images, CSS, and Javascript assets. Nearly every screen in Basecamp has both a desktop and a phone template. Here’s how it looks:

Variant flows for desktop and phone

While developing Basecamp for iPad we introduced a third variant: tablet. Basecamp’s phone.css already includes responsive styles which allow it to adapt to portrait and landscape layouts as well as larger phones, tablets and everything in-between. The tablet variant uses these phone styles as a baseline and then layers on additional CSS for specific tablet designs (like those for the iPad app). Responsive design has plenty of drawbacks if you’re trying to take a complex app designed for the desktop all the way to phones but it’s fantastic when you need a nip and tuck from phones to tablets. Furthermore, the tablet variant can have its own templates when a nip and tuck isn’t enough. Making a new variant template means new cache fragments so we generally tried to go as far we could with responsive designs before making that trade-off.

Screenshots of Projects on desktop, iPad, Kindle, Android, and iPhone
The Project screen on desktop, iPad, Kindle, Android, and iPhone
Directory structure diagram
Directory structure for variants in the Rails app

The Project screen is one place where we made that trade and it’s also a great way to see all of this in action. It has a unique design on desktop, phone and tablet. The tablet design is further enhanced when the tablet variant knows it’s rendered in our iPad app. To do that Basecamp for iPad has a unique user-agent string and declares itself (and certain capabilities) by setting classes on the HTML element when containing the mobile web views. Here’s the diagram from before with the tablet variant added:

Variants flow for with tablet

How we got here (on the cheap)

Basecamp for mobile web was a by-product of building Basecamp for iPhone with just one designer and one programmer. That existing foundation gave us a huge leg-up when it came time to bring Basecamp to Android. Because we had a ton of work already done in the web views we could spend time focusing on improvements just for Android. We crafted CSS to make the web views feel more at home on the platform and leveled-up with an even more native hybrid navigation. A team of two full-time programmers and a half-time designer made Basecamp for Android in about 6 months.

Basecamp for iPad’s team was the same size. Their by-product, the tablet variant for iPad actually debuted months ago in Basecamp for Kindle because Amazon’s HTML5 Web Apps let a lone designer package that up in a few hours. We’ll be able to use the tablet views again when it’s time to improve support for Android tablets.

That’s not to say our approach is only about repackaging the web views. Relying on the web core allows to to spend our time on something other than reimplementing the same features for yet another device. The Basecamp for iPad team added new features like editing individual comments which also arrived on iPhone and Android because the feature was built in the web views. And we continued the progression we started on Android moving navigation and actions from the web views into the native wrapper where users expect them. iPad further leveled-up by introducing a fully native UI for working with to-dos. Because so much of the work was already done, we had the freedom to add features not available in mobile browsers like drag-reordering which opened us to up a rich single screen UI for managing your to-dos. It’s a huge improvement.

The Future

Basecamp originally launched in 2004, re-launching in 2012 as a completely new product with a ground-up redesign. It’s always been primarily a desktop experience for our customers—people at their desk getting things done. But that is changing as mobile becomes more a part of people’s lives and even more so as the line between desktop and mobile becomes meaningless. In the future everything is just a computer and they’re all quite capable.

Basecamp mobile in all it’s permutations today is still an add-on to this desktop app. It makes some fundamental assumptions about what was possible and practical on phones when it was released (Basecamp mobile launched when the iPhone 4S was top of the line) and there are features in the desktop version that may never make it to mobile because they’re technically or conceptually impractical. There’s nothing wrong with that, of course. 100% feature parity shouldn’t be the goal. Every device, platform, and situation has its own forces, constraints and jobs that affect the design. Basecamp for iPhone, for example, has a very tight feature set compared to desktop but customers find it useful because it has the right set of features.

Today’s devices are larger (phones) smaller (tablets), and most importantly more powerful. HTML, CSS and Javascript performance are better than ever, the future looks especially bright for hybrid web apps on the latest versions of iOS and Android. Practical compromises in 2012 might be irrelevant today or in the very near future.

So how might we do things differently if we started from scratch today? One option would be to make the phone variant the golden path. Perhaps instead of being completely separate, desktop could work more like today’s tablet variant layering enhancements on top of phone. Here’s how a more adaptive and additive approach might look:

This approach makes more sense as computers and mobile devices converge in terms of capability. Plus designing for a small screens first has numerous benefits that push up into the tablet and desktop designs. It’s so much easier and more effective to adapt designs and features to a more spacious and resource rich environment than it is to squeeze them into a smaller container. Just like it’s easier to move your living room furniture from an apartment to a house than the reverse. In the later case you might have to get rid of a few pieces or replace them with simpler versions (Where’s my recliner? Useless!). Sound familiar?

Even as an add-on this hybrid approach has made it possible for us to deliver a lot while staying small. We’ve learned a ton along the way and I’m excited to share this look at where we’ve been and where those lessons could take us. Thanks for reading!