Thousand Character Reference
The idea of using Adobe’s DMP tools to convert a project we did about eight years ago into a reference text for the iPad came to us in a roundabout fashion. It dawned on us after a conversation with a total stranger we met at a birthday party last Saturday night. The original project was a DVD of the 1000 Chinese Characters created using iMovie and iDVD and resulting in the standard media files (jpgs, sound files, etc.). When we got the iPad in 2010, we built a .pdf version to see how it would “feel” on the device. While the eBook was more usable than then DVD version, some features were missing. The PDF approach was fine for creating an eBook but adding additional capabilities (voice, video, multiple views) proved to be more challenging.
After a few beers, and while describing our experience with Adobe’s DMP tools, it clicked into place that we had all we needed to put together an iPad app of the Thousand Character Reference text with all of the features missing from the PDF version. The challenging part was creating a workflow to track the the different files (1000 characters @ 20 characters per page= 50 pages, x 4 different styles) while building the issue. With the workflow in place, we were able to crank through and build the fifty-page issue in less than two days.
We tested the various features as we were building the issue. Early in the beta program Adobe did not have a local version of the Viewer. To see our work, we had to upload the files to an Adobe server then download the issue to the iPad before we could test it. A few releases ago, Adobe made the process much simplier with a desktop version called the Content Viewer. There are some limitations as to what iPad functions the Content Viewer can simulate, but it is close enough that we were able to test about 85% of the features. The rest of the testing was done when we had the actual issue built.
In order to build the real iPad issue, the one that would be submitted to Apple, we had to have all of the files, security certificates, and other miscellaneous pieces in place. If any one of these items was missing or “bad,” the Adobe ViewerBuilder would reject the build request. With all the files uploaded, the request is queued and processed on a first in, first out schedule. The cycle is typically is a few minutes. We would have liked the ability to do the builds locally, but we understand Adobe’s reason for keeping control of this step.
If the build completes successfully, both the test and distribution issues will be available for download from Adobe via the ViewerBuilder. The test issue may be loaded onto the iPad (via iTunes) for viewing and final QA. The distribution version is zipped and must be sent to Apple “as-is.”
Once we were satisfied that everything worked as expected, we could then upload the Distribution package from Adobe onto Apple’s server. There are two steps involved in the process: creating the App Store page and uploading the package. ITunes Connect is used to create all of the marketing and sales info which will be displayed in the App Store. The Application Loader (part of XCode’s utilities) is used to send the zipped package to Apple. Once all of that is done, then it is just a matter of waiting for Apple to review the submission and hopefully approve it for sale in the App Store.
In less than three days, we were able to take an idea and turn it into an issue for the iPad using Adobe’s DMP tools. The issue has all of the standard UI elements of an iPad app. We were also able to add transitions and sound to the content. Once the Adobe tools go live, we will lose the ability to use Adobe’s ViewerBuilder to make standalone iPad apps. We hope Adobe will make a version of the ViewerBuilder tool for small publishers. The availability of such a tool will let those of us who are interested in creating specialized content an opportunity to get our idea off the drawing board and onto the tablet. We think it will be good for everybody.
Leave a comment