I thought it might be interesting to reflect on how we’re finding the iPad as a development platform regarding our latest digital fiction project ‘Changed‘, bearing in mind that we’re not using the Apple SDK or exporting an App from Flash CS5 to produce this piece.
Changed is an atmospheric story set beneath a roadway tunnel. It’s based on a script by Lynda Williams (see Grace, a short film which Lynda wrote, here). It contains a mix of text, video, audio and some elements of interactivity. It’s self-reflective and strongly visual, the tunnel itself forming the ‘canvas’ onto which all other aspects of the story unfold.
The work is being designed as a ‘Web App’, which means it can be found on Mobile Safari on the iPad, bookmarked, and then added to the iPad’s Home Screen as if it were a native App. Theoretically, once downloaded, it should run offline where no internet connection is available. We’re also looking to try and keep it compatible with desktop computers/browsers.
It’s a bit of an experiment into what’s possible – but here’s what we’ve liked and disliked about the iPad development part thus far:
The iCool Stuff
The iPad’s natively smooth touch/scrolling navigation method bypasses the need to create easing effects when it comes to exploring large-scale websites/environments. As such, it feels nice exploring long/wide site designs and text appears crisp and sharp. Everything generally looks good on the iPad – the brightness and resolution of the screen is impressive and it’s nice to be so ‘close up’ to what you’re experiencing and to be able to experience it without being sat up to a monitor or laptop with a keyboard and mouse.
Bookmarking to the Homescreen results in ‘Web Apps’ looking like native Apps and being able to use HTML5 Manifest to ‘cache’ data. This means Web Apps should work offline, ie, even when there’s no internet connection.
Web Apps run in full screen, which looks great. They can also have custom App icons and you can even design a ‘loading screen’ whilst they boot up. Using ‘meta tags’ it’s also possible to set the initial scale and resolution of the viewing area, thus customising the user experience.
The iShite Stuff
Building for the iPad without an Apple/the Apple SDK leaves you with no testing platform or emulator other than the iPad device itself, so development is notorously slow and painstaking and has to be done via uploading to a web server and continuously refreshing on the iPad to see the results.
There is only very basic web error message reporting available on the iPad (enabled in Settings) and often no error messages are reported when links fail or video/audio media does not connect or is in some way incompatible. It’s a huge matter of trial and error which again slows down any kind of development workflow.
All media is *by default* forced to appear ‘separate’ because of the way HTML5 tags operate. It is extremely difficult to make media look as if it’s blending together in any way; it always apppears totally boxed out. Video elements regardless of format always seem to display the ‘Q’ quicktime icon before they kick in to operation, which looks naff.
Activating one HTML5 media element automatically shuts off all others. So for instance, you cannot keep a continuous background sound active whilst also displaying a video sequence. This is not a limitation of HTML5 on desktop browsers, only on the iPad/Mobile Safari.
Video/audio elements will not autoplay because of restrictions imposed by Apple on the device. They claim that if you’re using 3G and potentially paying for your bandwidth, you won’t want media to start streaming automatically. So they’ve forced the function out.
Jpeg images cannot be larger than 1024 pixels in size. PNG images get around this somewhat, but even they fail to show up if they’re bigger than 2mb.
Even simple jQuery transitions stagger on mobile Safari, making straightforwardly smooth graphical fades/scales either slow or totally redundant.
For some reason Web Apps always start in ‘portrait’ mode even if you were in ‘landscape’ when you launched the App, which means you have to swing the device around needlessly.
HTML5 Manifest (for caching) does not report if it has any problems (other than saying it needs to connect to the internet) and automatically checks for updates at apparently random intervals. Sort of missing the point, then.
Despite the amazing number of bizarre limitations we’re not doing too bad and the piece is gaining a sense of identity and atmosphere, although it’s a long way from the look, feel and complexity of our other, Flash-based work. As an experiment into testing the creative possibilities of HTML5 and CSS3 alone, it’s proving worthwhile, and indeed continuously feeding useful techniques across into to our current (commercial) web design jobs.