We’ve been doing iOS development in-house at 37signals for over a year! Since the launch of the Basecamp for iPhone app we’ve had a lot of questions about our development & design process going mobile, our opinions on the new environment, and more. Recently our team has participated in some interviews about how we made the app, and I think you’ll learn a lot from them.
Ryan was interviewed by Hipmob about the design process of the app, and the issues we’ve faced on mobile platforms:
The biggest challenge for a company like ours is to change our way of thinking because, we grew up when the web was just a laptop thing. We learned on laptops and we defined our notion of what software is on laptops and desktops, and it’s really changing.
I was lucky to be invited to the 4th monthly MotionMeetup, a moderated Q&A session with various RubyMotion developers. They asked questions about what I learned making the Basecamp app, what advice I’d give to newcomers to the platform, and why I hate bees:
I’m running a conference, NickelCityRuby, in my hometown of Buffalo, NY this fall. I’m no stranger to getting people to code or work together, but organizing an event like this is a new challenge for me. My main goal with the conference has been simply to bring plenty of awesome people to see Buffalo, but another of mine has been to ensure the conference is as diverse as possible. Full disclosure: 37signals is a sponsor of NickelCityRuby.
Diversity is a tough subject in the tech world, and I think it’s something we just can’t ignore. I care about this deeply because I’ve witnessed exclusion happen before (myself being at fault too!), and the only way to make sure it stops is by making conscious decisions to change for the better. There have been severalscandals at conferences recently, and this has been my biggest fear of about organizing a conference: Can we deliver a conference that is diverse?
We recently announced our speaker lineup, and I’m really happy with how diverse it turned out. However, I think this is just the beginning of making sure we meet the mark. By no means is being inclusive a checkbox you can just tick off while organizing something: it has to be baked into your decision making process from the start. Here’s a few things we’ve done so far that I think any similar event should think about.
The latest Basecamp for iPhone release involved an immense amount of refactoring with how HTTP requests and HTML pages were rendered. In a previous release, my coworker Sam wrote several methods that didn’t serve to reduce duplication, but instead their purpose was to increaseclarity. Since the focus is on comprehension rather than just reusability, it’s easier to understand what is going on and jump in to solve the next problem.
This pattern has been eye-opening, and I’ve been using it to hide implementation details and remove comments explaining what chunks of code are doing. Instead, the name of the method explains what is going on. The gist here to communicate Intention Not Algorithm:
We have a lotofdata to parse through at 37signals. Our internal stats application, Dash, does the majority of heavy data lifting for us, including reports, application health, CI builds, and much more. Our Campfire bot named Tally happily pings us when a build fails, deploys are fired off, and when Nagios alerts pop up.
I had a problem though: I needed to have all of this data open constantly to absorb it. Either I had to look at the pages on Dash directly or make sure I’m in the reading through messages in the right Campfire room.
I decided it was time to fix this overload. The release of Status Board let me take a step back and understand what pieces of data really mattered to my daily work. As a programmer, I want to answer a few questions:
What’s the on-call load like? Do I need to help out?
I’m really in awe of this. There’s no “pledge $10 or more” and get a prize. There’s no stretch goals. It’s real, the entire production process is documented openly, and you can get the final product today for $20.
There’s something to be said for launching a product and making it happen yourself. Congrats on the launch, Jon. I can’t wait to play Space Dice.
Being remote means that the typical watercooler discussion of the office tends to be reduced to sharing neat links and cute dog photos in our Campfire rooms. This is another reason I enjoy our company meetups: it’s a chance to learn a little more about your coworkers. It’s much more rewarding when we share snippets of daily life, like our current workspace status.
There’re 36 signals now, spread across 6 countries. Since we’re remote, we don’t get to see each other that often. We have meetups 2-3 times a year, but I don’t view them that way: they’re reunions. Our first of 2013 was last week. When you don’t get in-person face time with your coworkers every day, seeing each other makes it special, and it’s much more fun.
Some of my favorite feedback on Basecamp for iPhone has been that the app feels wicked fast, and all native. The app actually is a mix of web and native UI, but it’s difficult to see where the line is drawn. The majority of the content shown in the app is web: From the login screen, to posting a message, and even uploading photos on a comment, that’s all done using UIWebView.
Chrome inspired us that web views could be pushed to the next level, and we wanted to make use of our existing fast, mobile HTML5 views. Going web wasn’t always solid: Some views started as web, went native, and ended up back in a web view. In the end, the app evolved into a simple web content browser with a native feel on top. It’s certainly a compromise, but we’ve been really happy with the hybrid architecture so far.