Parchment on the iPhone

I recently spent time making Parchment work properly on my new iPhone 3G.

The iPhone has been my first foray into the world of the mobile web, and getting Parchment to work well on it was an interesting experience. Some of the challenges I faced involved getting the iPhone’s on-screen keyboard to display properly—Parchment doesn’t actually have any text input fields on it, so by default the iPhone didn’t think that users had to enter text—and modifying some processor-intensive JavaScript code so that the iPhone didn’t think that Parchment had gone into an infinite loop.

Another interesting challenge was figuring out how best to display content so that it would be viewable in a way that didn’t require the end-user to perform unnecessary panning and zooming. By default, the iPhone assumes that pages it views were made to look good on a page that’s about 980 pixels wide, so that’s how big the “virtual viewport” is; this default seems to make sense, since most pages were made with desktop screens in mind, and the ability to zoom and pan makes it relatively usable. However, when a developer is creating a rendering of a site specifically for smaller screens, they can force a particular viewport size—thus minimizing or entirely obviating the need to pan and zoom—by inserting a viewport meta tag in the HTML and using some iPhone-specific CSS properties like -webkit-text-size-adjust. All of these sorts of issues were documented nicely in Apple’s Safari Web Content Guide for iPhone. Though they’re not “standards” per se (at least as far as I know), nonetheless I think that tailoring pages for an incredibly small, zoomable screen could be viewed as little different from tailoring them for print—something CSS already supports—so I hope that these extensions can eventually be turned into standards and supported by other mobile browsers like Fennec.

Right now my biggest criticism of the iPhone, despite all its enormous benefits, is the fact that its native platform is quite sterile, or at best contingently generative. I was hoping that the open web would be one way to get around this, and getting Parchment to work on the device was my way of testing these waters.

Parchment’s ultimate goal, as outlined on its Google Code project page, is to serve as a compelling replacement for desktop-based Z-machine interpreters. Among other things, this implies that it should work fine when disconnected from the internet, and it does: once you’ve started a game, it’s entirely loaded into the browser and no further network connections are made. In Firefox 2 or above, selecting “Work Offline” from the “File” menu will allow you to still access the game and play it even if you don’t currently have it loaded in a tab (why Firefox can’t automatically detect whether you’re offline is being worked on). You can even save and load games while offline because the game state is appended to the URL hash—put in DOM Storage too, if support is detected—and Damien Neil has a patch that uses PersistJS to provide even better support.

The thing is, Safari on the iPhone doesn’t seem to have any kind of “offline mode” like Firefox does. Further, it only keeps one web page loaded at a time, even though it has something resembling tabbed browsing; so if you switch from Parchment to another website and back to Parchment, the entire page is reloaded—something that not only consumes network bandwidth but also processor time. This hugely limits Parchment from becoming a compelling replacement for a native iPhone app that does the same thing. And thanks to Apple’s gate-keeping, there’s serious doubt as to whether the latter is even a possibility.

I also have no idea if Apple is even likely to introduce an offline mode for the iPhone, because there appears to be a clear conflict of interest between their closed platform and the open web: it makes sense for Apple to “gimp” the web as much as it can so that application developers are forced to develop for the platform that Apple controls. So I’m really looking forward to both Fennec and Android supporting generativity in the mobile space.

In any case, if you have an iPhone, feel free to play a story on Parchment and let me know what you think.

8 Replies to “Parchment on the iPhone”

  1. Safari on the iPhone does keep multiple ‘tabs’ open at the same time, unless the one you are viewing uses too much memory. Then it’ll discard the ones you are not viewing (they’ll become blank in the overview screen). The Apple apps work the same way, they’ll be kept in memory unless memory is exhausted.

    Not really a problem for me, it’s a phone, not a laptop.

  2. By far the best handheld z-machine interpreter I’ve used (and perhaps the best, full stop) is YAZI on the Apple Newton. The developers don’t seem to be around anymore, but there’s an old version of their YAZI page on (check out the screenshots for a better idea of the app):

    A few things in particular made it great for use with a stylus: there were single-click buttons for many common commands; there was a customisable menu into which you could store your own frequently used commands; most of all, you could click on the words in the output screen to immediately copy them to the input line. These shortcuts mean, for example, that if an item appears in a room description it only takes two clicks to subsequently examine it.

    This made it easy to play a game with very little typing needed – ideal for a tablet based machine with no physical keyboard, such as the Newton… or the iPhone. Perhaps it’s worth thinking about a means to add these sort of facilities to Parchment.

  3. A most interesting exploration, Atul. I know this discussion will go round in circles for years to come, but contingently generative is often a benefit to users who are not technically capable of generating content. It gives them (pardon me) someone to blame when quality control goes wrong, especially something related to security. “Apple approved this app; why is it sending my contacts to!?””

    I know you’re talking about community-driven notions of trust to try to replace the central-clearing-house-of-trust. But I maintain that a majority of people who use computers *should not* be expected to understand the technology well enough to participate in such communities. Thus, for many people, the limitations of a trusted central clearing house are more useful than the flexibility of open platforms.

    Which is not to say, for even a minute, that it isn’t in the open platforms that much (even most?) technological innovation occurs. Apple has invented precious few new software technologies, borrowing heavily (and often without credit) from the open source community.

    Really, I just wish I had voice recognition to play these games… But you can’t have everything in this life, I suppose.

  4. What a great idea for the iphone! I just tried Hitchhikers on it – a couple of points:

    I ended up emailing myself the link as it was too big to type in, and I couldn’t find it on the Parchment site. Some sort of iphone friendly index page would be very handy.

    More importantly, when a command is being entered in Parchment, there are two buttons available “Done” and “return”. It’s not totally clear to me why “Done” doesn’t submit the command, but “Return” does.

    Very minor points – just thought you might like some feedback.

  5. I would really love to be able to use parchment on my site. Having an interactive fiction running as accessible text on a page instead of in some java or flash box opens up a whole universe of possibilities. You could use jquery to turn text into links, or apply custom CSS to it… Unfortunately every time I’ve tried to find out more about using it, I get no response… is this beta software that you don’t want out in the wild beyond the test page you put up?

  6. @Wiley: Not at all! The uses you’re talking about were exactly the kind of thing Parchment was made for… We’ve got a Google Code project up for it here and a mailing list here. Please feel free to drop by and say hello.

  7. I poked around on the google code pages for it a while back… that’s a lot of scripts, and no documentation. I was able to get my inform story in the right format, but I couldn’t immediately figure out where to change what story file parchment was opening. I’ll take another crack at it though.

  8. also, what all do I need to check out in subversion? I’m not a javascript developer, just a css guy, so I’m a little intimidated by all those files.

Comments are closed.