iPad an Impediment to Document Innovation

The popularity of Apple's version of the web has the potential of stifling innovation in non obvious ways. Interactive document formats are a case in point. Here Apple has two sets of rules: if you are Apple you are free to innovate, if you are not Apple you must innovate on top of HTML5 and Javascript. But are official World Wide Web Consortium standard languages sufficient tools to deliver cutting edge document functionality? The answer is no.

Here is an excerpt of Apple's licensing limitations:

3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

We can conclude that rich, interactive document formats that require scripting must use a language that is already available on Apple's devices. If that language is not good enough or not tailored to the environment (e.g. 3D scripting) then you are out of luck. If another manufacturer has similar rules to Apple but supports different languages then making a cross device document solution is not possible.

In fact the rules are even more stringent because the only built-in interpreter is Javascript, and it is only available from within Webkit, and you can't used it to manipulate your own document object model (DOM). Meaning the only content you are allowed to script is HTML. That means other interactive document formats are just plain verbotten.

There are some pretty reasonable and popular document formats out there that are not HTML. PDF and Excel spreadsheets are but two examples. PDF actually supports interactivity in several ways, including embedding Javascript (a basic use is to do the math in PDF forms) and 3D. The forms Javascript is an older variation that is not compatible with the Apple-provided interpreter (you can't really update 10 year old documents nor call Adobe lazy for not doing so). Even if it were, the Javascript has to bind to a native DOM, and Apple's Javascipt interpreter does not allow this.

Apple Preview supports a subset of PDF but does not support embedded Javascript. Rule 3.3.2 forbids an application from supporting PDF with Javascript. This is really too bad, because I could have seen the iPad as being a great, portable platform for using PDFs with rich forms entry and calculations.

Looking further at PDF, PDF has 3D capabilities that by their interactive nature require scripting. The existing scripting engines provided on Apple devices (Javascript) just don't cut it. 3D is the type of technology where developing the language is part of the innovation. Flash has similar, advanced rendering capabilities that are not available in HTML5 and Javascript. Essentially, therefore, innovation of this type becomes stifled.

Excel spreadsheets are not allowed because they use formulas that are not written in Javascript. iWorks gets away with providing excel support because, well, all iPhoneOS developers are equal, however Apple is more equal then others.

Apple is essentially killing these formats on their devices, which means the formats are not really universal any more. The only workaround is for the formats to avoid interpreted code, which is very limiting as well as impossible to do retroactively on already widely used formats (though, as the person responsible for digital signatures in Acrobat, I have to say I'd have welcomed a less-interactive version of PDF that was more stable when signed).

Some argue that the iPad is open because it supports native apps. I hope I am showing you that this is not a wide open field for those native apps. The apps being written are mainly web apps or other lighter weight apps that are content front ends. They tend not to be innovative platform applications on the scale of iTunes, Acrobat, Excel or a browser (note the emphasis on mainly and tend).

What about the next new document format? Look at what Wired did with their first magazine app. They essentially took screenshots of the pages, created an XML manifest of the contents, and added a bit of animation. Some are accusing Wired of being lazy, saying that they should have used HTML5 and Javascript. Perhaps they should have, but the argument is that they required and could not achieve pixel perfect rendering with HTML5. As well, HTML5 and Javascript weren't decreed to be the standard until this year, we might assume that they had legacy work that they needed to quickly rebuilt to a different format. Here the onus is on the Wired to adapt rather then what normally happens, which is for the platform provider to provide adequately for content generators. If Wired, or someone else, wants to innovate beyond what HTML5 + Javascript delivers, what do they do? The answer is that they are stuck.

Unfortunately all this is more evidence of the control that Apple is exerting over software development and the internet, and getting away with it because they are so good at what they do. They are the first company to explicitly ban capabilities from a general computing device (rather then mobile phone). They have enough of a foot hold that content generators need to take heed. Wide success will serve to chop off any pre-existing non Apple file formats at the knees, and serve to ban future formats by pigeon holing developers to use HTML + Javascript.

What we had all hoped for in the mobile market is that these devices would adopt the open PC model. That partially happened with Apple allowing a play-by-Apple-rules set of apps onto mobile. This was so much better then what existed before. Unfortunately what we are seeing is Apple's not-quite-open mobile model being extended to the PC. That is a scary vision and not my ideal vision for the future.

Update: See these blog posts The rules have changed and Apple Fears the Killer App

Somewhat Improved Facebook Privacy Controls

Facebook has made some reasonable, but not perfect, fixes to the user interface for changing privacy settings. A few things are better exposed, such as the list of applications that have access to your data, and what data you are sharing with who. But it's still broken because you can't, in one place, tighten your security settings.

If you edit privacy settings and set the Sharing on Facebook option to Friends of Friends, this indicates that Family and Relationships can only be seen by Friends of Friends. But your list of friends remains public under Basic Directory Information. You need to go into Basic Directory Information and fix this manually. I don't see why the Sharing on Facebook settings can't be used to determine the Basic Directory Information sharing.

A similar problem exists for sharing data on other sites. Under Applications and Websites I am happy that I can "control what information is available to applications and websites when your friends use them". I am less happy that this again is not under the umbrella of Sharing on Facebook.

The new top level privacy settings page is an improvement, but you still need to dig too deeply to protect yourself. If you can't describe to a non techie in memorable words what they need to do do protect themselves, then it's too complex.

MacRuby for Application Scripting

MacRuby 0.6 was released a few days ago (30 April 2010). MacRuby is a version of Ruby 1.9, ported to run on the Mac OS X Objective-C common runtime. You can write Cocoa apps and, interestingly, you can also use ruby as a scripting language to control applications running on your system.

The MacRuby install includes macirb, the MacRuby equivalent of Ruby's irb command line interpreter.

Here is an example script to read from and control iTunes via the scripting bridge.

framework 'ScriptingBridge
itunes = SBApplication.applicationWithBundleIdentifier('com.apple.iTunes')
itunes.playpause
track = itunes.currentTrackname = track.name

Here is an example script for Photoshop.

photoshop = SBApplication.applicationWithBundleIdentifier('com.adobe.photoshop')
doc = photoshop.currentDocument
n = doc.name
doc.rotateCanvasAngle 45

To see a list of what methods are available for an object, call its methods method as follows, subtracting out the methods available to Object.

photoshop.methods(true,true) - Object.methods(true,true)

Pretty cool stuff. I was never a big fan of AppleScript, and in fact stayed away from scripting applications because I didn't like using AppleScript. I can see MacRuby busting the doors off of scripting on the Mac!