In his Lessons for Developing Tablet Apps (for Non-Developers) talk at Web 2.0 Expo in New York, Scott Smith outlined the lessons Time Inc. learned when developing a suite of magazines for tablet devices. Here’s my notes from his talk:
- Time Inc. built their iPad application before ever seeing an iPad so they could release the app on the day it launched. It was initially met with a lot of disdain but still remains in the top grossing apps of all time. Has 7,396 one star ratings. Most of them are about paying for subscriptions vs. paying for one issue at a time. Have since made adjustments.
- Time has embraced other platforms as well including the HP TouchPad, Barnes & Noble Nook, Blackberry Playbook, and Android. The company feels they are at the beginning of a transition so they are working on many initiatives to learn.
- Time Inc. create new content for tablets. Most everyone else publishing magazines is re-purposing existing PDFs. People designing magazines at Time are also given the ability to design the tablet experiences.
- When it comes to developing apps for tablets, you have to be willing to embrace start-up development methods: launch quick, learn, and iterate. There’s just too much happening in the market to use standard, long processes.
- Choose the right partner. Time uses Woodwing for their apps. They picked them because they adopted open standards, had room for growth, but were proud of their work. Also work with Adobe because all the content for apps is made in InDesign.
- Know the territory. Applications can’t function the same across operating systems. Embrace what each OS does. Know what you want so you can effectively communicate with developers.
- Get buy in on the project and set up a fixed process that people will stick to: what will be done and what won’t be done.
- Be flexible. Time tried to put re-purposed PDFs on the Web and people didn’t want them there so why would people want them on tablets? It turned out were actually reading re-purposed PDFs on the Nook Color. So Time made new content for the device since there was clearly an opportunity.
- Document your vision (preferably with pictures). Though a vision piece may not be built it can define what people want built. Time had a number of “future” pieces created to open people’s minds to where digital publishing could end up.
- Limit the features to prevent scope creep, shrink time to market, and avoid confusion. Scope creep: the feature you want is going to take longer than you think. Time to market: the more you throw in the longer it takes to get customer feedback. Start the conversation with your customers as soon as possible.
- Creation is a messy business. List out all the features you need on one piece of paper and get agreement. Stick to the list but don’t rank it. Instead prioritize the list of things you can’t do so things can be added as time or subsequent releases permits.
- When you get an answer of this will take longer, don’t assume you can add more people to speed things up. It doesn’t work. This is the mythical man month.
- Fight off everyone else. Keep your developers safe from churn.
- When you first see the app, don’t panic. It will be incomplete. Ask instead: At its core, is this the application that you asked to get built? Are you on the right track or do you need make a business decision to adjust the process?
- Keep the development cycle as short as you possibly can. Only 2-3 people should be talking to developers and you are probably not one of them. Work on finding the bugs that slipped past developers and organize them by “showstoppers” and “everything else”.
- Pay no attention to the emulator. It does not reflect what the experience on the device will be like.
- If you are not embarrassed by your application, you waited to long to launch. You won’t be able to fix every little thing before you need customer feedback. So don’t wait to get your product out there.