Positions: Founders; programmer (Paul) and designer (Mark)
Background: Tapbots are “utility robot” apps designed and engineered for the iPod touch, iPhone, and iPad. These applications are easy to use, focused, and fun.
Link: http://www.tapbots.com/
Ken: Assume you have an app you feel good about pursuing. How do you map out building it? Do you break the app down into screens, features, or stories? Do you create a development schedule?
Mark: The first thing we do is figure out what the core purpose of the app is. It’s usually described in one or two sentences. Then we write down all the features and tasks that are needed to fulfill that core purpose. The most important features usually [become] version 1.0.
We try to keep an app from doing too much. Pastebot is almost an exception, but we did our best to stay on focus. We felt strongly that it was intended to be a clipboard manager, and its features should be focused around that task. It can be tough to say no to potentially good ideas, but in the end, we need our apps to stay focused.
Once the core features have been established, I start sketching wireframes and Paul usually begins the low-level groundwork for the app. We usually have about 90% of the artwork done before Paul starts coding anything on the interface level. The missing 10% usually consists of minor things like settings, dialog boxes, and other things not essential to the core functionality of the app. Once the app is in somewhat of a working condition, we iterate on what’s not working, which includes design, functionality, and the user interaction experience.
We don’t make a development schedule until we see the end of the road. Being a small team has its advantages. We don’t have the pressure to meet deadlines. We work until we feel the app is good and not to a time limit. Once we are at the end of the road, we do need to plan for testing, localization, and marketing, so that’s when we start making schedules.
Ken: Whether it’s the iPhone or some other platform, something typically goes wrong or not according to plan when developing software. What sort of time do you allocate (if any) to potential problems and bug fixing?
Mark: For the most part, [we allocate] whatever time is needed to fix the issue. And that means solving the issue or finding a suitable workaround. It really depends on the size of the issue. Some bugs can wait, while others demand immediate and full attention.
Ken: Related to these issues, do you do any rapid prototyping to identify potential roadblocks in the development of an app, or do you move immediately into full development once you have your plan in place?
Paul: [We do] very little [rapid prototyping]. I might check if something is possible given the current hardware limitations (speed/memory), but for the most part, it’s full speed ahead with development. Our apps tend to be simple enough from a concept standpoint that it doesn’t make sense to spend a ton of time prototyping things. For the most part, the majority of the time I spend is in getting the UI to look and work just right.
Ken: How do you—and how can developers—reduce development time without cheating in the process? What aspects of creating an app can be done in parallel? What can’t? Are there ways to get apps done faster besides having more resources available?
Paul: I’m a big fan of creating reusable classes/components. It won’t save you much/any time on your first iPhone application, but if done correctly, it’ll save time in future applications. Every app we create adds more classes to our library, which means we don’t have to duplicate efforts and we can also get a consistent look-and-feel to our apps. Another great benefit with using reusable classes is that often features for new apps can be quickly added to existing apps, which makes for happy users.
Ken: Tapbots is known for its incredibly polished interfaces. What do you do to ensure that they are not only polished, but also functional and easy to use?
Mark: We use them. And [we] have other people use them. We tend to take design risks with our apps, and they don’t always work out. What looks good onscreen doesn’t always translate well when the user is interacting with it on the iPhone. We aren’t afraid to design/code something and then start over if it doesn’t feel right. The biggest part about our apps is the overall feel of them when using them. We put a lot of effort into making sure that WOW factor is there. If we, the developers, are excited with how it works, then we can be pretty sure that customers who haven’t spent hours upon hours with the app will enjoy it.
Ken: Discuss what you consider the key differences of designing for the iPhone versus the iPad.
Mark: I can’t speak too much about the differences, as I have yet to design for the iPad. My instinct, though, is that it’s not a matter of just making everything bigger. The limitations and constraints of the iPhone made things simple. Now, there’s a lot more pixels to worry about. Then there’s the device orientation. Despite these concerns, I think it’s safe to say we are going to love designing and developing for it.
Ken: Overall, what is the key part of the development of your shiny apps?
Mark: Having clear goals for the app from the beginning and sticking to them. For us, our goal for all of our apps [is that they] are fun, focused, and easy to use. We really try to build around [that] goal.
Position: CEO and co-founder
Background: Started in 2006 by Dave Teare and Roustem Karimov, Agile Web Solutions is the company behind 1Password, the most popular password manager for Mac OS X, iPhone, and iPad, with more than 1 million users worldwide.
Link: http://agile.ws/onepassword
Ken: Since you had an existing product, how did you initially map out 1Password for the iPhone? Did you break the app down into screens, features, or stories? Did you create a development schedule?
Roustem: The development of the iPhone and iPad applications was driven by screens. Dan Peterson, our lead designer, mocked up most of the application screens in Photoshop before any coding started.
For the iPad version, once Dan completed the initial mockups, the whole team reviewed them and tried to imagine using the application on a real iPad. Things like being able to switch sections without moving your hand, left- versus righthand usage, and what portion of the screen is covered when interacting with it were considered. Basically, the screens were used as “target practice” and to help brainstorm additional ideas.
After the mockups were redesigned to incorporate the team’s feedback, the development team started implementing the design. It was an iterative process, and the layout and contents of each screen were revised as we worked through the implementation.
As for the schedule, we didn’t really have a formal schedule, but the goal was to be in the App Store by the launch of the iPad App Store. This forced us to limit the scope of the first version, and we removed features such as syncing with MobileMe and attachments.
Ken: What makes developing for the iPhone and iPad unique? Please also discuss what you consider to be the key differences between designing for the iPhone versus the iPad.
Roustem: There are a lot of similarities in designing [for the] iPhone and iPad. The main difference is that the amount of real estate on the iPad requires a lot more effort during design. This is magnified by the fact that Apple encourages a custom user interface specific to the iPad.
Developing for the iPhone and iPad is a dream in many ways. There are amazing development tools, polished frameworks, and APIs. Also, the App Store helps developers to not worry about running their own online store.
It comes with its own challenges as well. For example, developing on one platform and testing on another can be tricky, because the iPhone Simulator is not 100% identical to the real device.
The biggest difference is that iterative development is much harder on the iPhone platform. This is because it could take several days for the application to be reviewed by Apple and accepted into the store. Apple also makes a large beta program impossible. On the Mac, we currently have thousands of beta testers, whereas on the iPhone, we cannot have more than about 50. As a result, we submit new versions much less frequently.
Ken: Whether it’s the iPhone or some other platform, something typically goes wrong or not according to plan when developing software. What sort of time do you allocate (if any) to potential problems and bug fixing?
Roustem: At first glance, building “slack time” into the schedule to plan for the unknown seems like a good idea. The problem is Parkinson’s Law: work expands so as to fill the time available for its completion. If the schedule was expanded by 20% in an attempt to plan for the unknown, the feature set would increase by 20% as well.
Not only that, but Apple is constantly creating new “magical and revolutionary” devices and adding new features. It is hard to plan far into the future when new “game changers” appear so frequently.
Instead of spending time on detailed schedules, we prefer taking a more agile approach and do not plan far into the future. There is always something important waiting for the next version of 1Password, and the priorities of these features are constantly changing. If something important pops up, like a new platform or a critical problem, then we simply drop everything else until it is finished.
Ken: How did you decide what features went into 1Password and 1Password Pro? Specifically, how did you determine what paid features would compel customers to choose 1Password Pro?
Roustem: I am not sure we did it right in the beginning. Some of the premium features, like folders or additional syncing options, weren’t ready when the Pro edition was launched, and we decided to start with a lower introductory price. Today, this could be done much easier with the In App Purchase option.
Ken: Do you have any guidance for developers on thinking about how to break up major (e.g., v3.0) and minor (e.g., v2.1.1) updates? Do you work on major and minor updates in parallel? When is an update complete and ready to be shipped?
Roustem: It is a fairly straightforward process on the Mac where we make all major upgrades paid, include new features into the point (3.1, 3.2) updates, and mostly provide bug fixes in the point-point (3.1.1, 3.1.2) updates. There is no paid upgrade option for iPhone or iPad apps, and we simply try to keep the major version in sync with the desktop application and use point and point-point updates in a similar fashion.
Ken: You launched the iPad version of 1Password Pro as a Universal app. What went into that thought process?
Roustem: This was an easy decision. It helped to differentiate between the regular and Pro editions and also created a certain symmetry where the Pro edition combines all features of 1Password for iPhone and 1Password for iPad.
Get App Savvy now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
