Unfortunately, I couldn’t actually be there this year due to a last minute family emergency. But from the tweets I see coming out of the conference (check out the #renio hashtag), it looks like Tim Burks and Bill Dudney have done a fantastic job.
Posts tagged "ipad"
Here are the key numbers from yesterday’s “Let’s Talk iPhone” event.
iPhones: Half on the market are iPhone 4’s
App Store: >500k apps; 140k iPad apps
App Store: 18b; $3b paid to developers
If you compare these numbers to the WWDC keynote just four months ago (or so), what stands out to me is that there is a 55% increase in the total number of iPad apps (90k iPad apps then).
For more comprehensive stats and visuals, see MacStories post The (Big) Numbers Apple Touted At Their iPhone Event.
Because we are still discovering the ways in which we use tablets, we need to re-think how furniture might be better designed to accommodate these new lifestyles.
I was first introduced to Safari Books Online soon after it launched in 2001. As someone in the tech industry, it almost seemed too good to be true…an extremely large catalog of technical-related books available to read for a very reasonable subscription fee. Today the service might be described as a kind of Netflix for technical, design, and even some business book titles. Pay a monthly (or yearly) subscription fee and depending on the kind of account, it’s possible to have unlimited access to the 13,000+ books and videos in the Safari Books Online catalog by consuming them through the web browser.
But today that changes.
I’m happy to announce that the Safari Books Online service is now also available on the iPad as “Safari To Go.” That’s due to the incredible effort of both my team and many, many amazingly talented folks at Safari Books Online lead by CEO Andrew Savikas.
Fans of the service know that an initial version of the app was available back in November 2010 but what’s launching today is a completely new app with zero code reuse—v2.0—focused on a true native iOS experience. That means readers will find common controls and interactions available in most iPad apps and more specifically, iPad reading apps. More significantly is that with the approach we’ve taken, readers will benefit from much faster browsing of the book catalog, smoother reading experiences, and be able to finally enjoy reading a book offline when not connected to Internet.
The 2.0 version of Safari To Go also sports a new design, which feels like a native iPad app while also more closely reflecting the Safari Books Online brand. During the initial discussions about working together on this app, we suggested that the Safari Books Online team lead the visual design of the application with us focusing on user experience and the development. With this plan, we’d ensure Apple’s guidelines would be respected and at the same time, allow the Safari team to leverage its vast knowledge of its customers and brand. The positive feedback on the revamped design (and the app overall) indicates that this decision was a smart one and we’re proud of the new experience the two teams created together.
There were several mandates when we started this app. The first two, mentioned above, we’re related to improving performance and creating an app with a native look-and-feel. The final was to focus on developing a stable set of core features and then to iterate on them going forward.
As an example, notes and tags are not initially available in the application. Similarly, we found the performance on 3G to be sub-optimal due to the amount of content that transmits over the air. So, it was collectively decided that only an offline book should be accessible when on 3G for the first release of the v2.0 version.
Because of how we’ve built the app, we’re now in position to more quickly iterate on these and other features. In fact, we’re just now testing an update internally, which should be pushed to the App Store shortly. The Safari Books Online team also has a roadmap for upcoming releases with the expectation to update it and re-prioritize features based on customer feedback.
For existing Safari Books Online subscribers, I hope that you’ll download the new app (iTunes link). If you don’t have an account, sign up for a free trial today and go take a look. We’re just getting started, so let us know your feedback and what you hope to see in the future.
Beta testing isn’t specific to iOS development. In fact, it was very much popularized with web apps. It has similar benefits such as building early interest, collecting feedback, and generally making the app much more stable before launch.
Running a beta program for iOS apps also has distinct challenges. In the past, I’ve covered smarter ways to deal with having to distribute apps using tools like Hockey. Earlier in the process though, the focus is on gathering testers. Compared to web apps, much more than just an e-mail address is required for iOS beta testers. Important tester details include knowing their unique device identifiers (UDID’s), iOS version, and device type. Without this information, it becomes difficult to understand if a tester can run an app on their device. Worse, it’s simply not possible to include a tester in the beta program without having the UDID at a minimum.
Using Forms to Collect Tester Details
Unfortunately, iOS developers still haven’t recognized that there are better ways to collect this info from testers. I see this happen both with indie developers and with large, established companies alike. They are still having UDID’s sent to them via screenshots in e-mail and are then manually typing them into their developer account. At the same time, they have no clue if these testers can really even help them, meaning their precious device slots are being used for no reason at all.
Well, there are some really easy ways to improve this process but the main one I want to focus on for now, is building an iOS-specific beta sign-up form. The form should include basic tester information, such as name, e-mail, Twitter handle, etc., as well as device-specific details, such as UDID, operating system version, and device model. I recommend creating these forms in tools like Google Docs, Wufoo, or even Survey Monkey. Some may want to roll their own version but the key is funneling this information into an easily manageable single source (e.g., spreadsheet, database, etc.).
Over the past couple of years, I’ve continued to evolve my iOS beta forms but one by Xavier Veyrat of Hot Apps Factory recently caught my eye. With Rise Alarm, I had integrated my beta signup into my micro-site itself and added some new questions, including if the beta tester was going to be committed to testing the app. Hot Apps Factory took their form a step further though with their App Cooker beta sign-up form. It was extremely well-designed and also had significantly more questions for beta testers. Beyond the basics, it asked testers about other platforms of interest and even requested an acknowledgement from them that they wouldn’t share screenshots during the beta.
Short versus Long Forms
Forms don’t necessarily need to be long or exceptionally detailed. They might just include the basics mentioned above and a link to a UDID app (e.g., I recommend UDID Tool) to assist testers with grabbing theirs.
It’s true that longer forms may drop the number of testers who perform a signup. But it also has a benefit of filtering those who obviously are not excited or committed to providing helpful feedback.
Remember, that each device testing slot is highly valuable, since at least for the time being, Apple is still limiting each account to 100 total devices. Even two amazing testers are much more important than twenty unengaged ones. Those who take the time to complete all fields will likely fall into the former grouping. In any case, provided these forms submit into some sort of backend with reporting (e.g., Google Forms go into Google Spreadsheets), you’ll be able to quickly compare all the testers and select the ones you want based on their answers and device specifications.
When to Launch
The right time to surface the beta sign-up form can vary. But it’s a good idea to get it online 2-3 weeks before you’re ready for a beta. You may want to share it through social media channels or even give it a more prominent place in the navigation on the app website. When to launch, as well as the length of the form, is somewhat dependent on the amount of submissions you’re wanting.
No matter how many you receive, you can be rest assured that using a beta sign-up form is going to simplify this process, reduce errors (no more typing UDID’s!), and help you manage testers better throughout the entire beta program.