As soon as I heard about the new iWork.com site launched yesterday, I knew I wanted to know more about how it was made. iWork.com is a web-based way to share and collaborate over your iWork documents. I searched around the blogosphere seeing if anyone knew any technical details, but didn't find anything, so I had to crack open Firebug and see what was under the covers. I really wanted to know whether the apps were built with Flash or Ajax or something else.
I downloaded a trial version of iWork 2009 and published a Keynote presentation. The new Sharing function unfortunately requires you to configure and use the Apple Mail program, which I did before I could test out to see how the iWork.com shared documents work.
Looking at the JavaScript files, I see SproutCore and Prototype being pulled in, so everything is built with Ajax and web technologies. It's also using WebDAV to pull in the metadata about the document, which is interesting (though it's piping the WebDAV over some kind of proxy):
Notice how some of the metadata payload is JSON as well.
The web-based iWork apps are themselves built above SproutCore, using that framework to organize and do things. For example, there appears to be something named CoreHeckler that has to do with the commenting system, all built using SproutCore.
Using the Firebug Inspector, I see that the slides are a combination of an image file, the Canvas tag, and transparent DIVs that overlay; if there are hyperlinks on the page they are overlaid on a separate DIV that lies over the canvas. Comments also float on top of the Canvas using another DIV. The Canvas appears to be used for comments somehow, but I'm not sure how. I see CoreHeckler.Graphics being bound to the Canvas element; I'm not super familiar with SproutCore however.
Looking through the CSS I see they are using a few -webkit- specific CSS style rules, mostly around rounded border corners and shadows. They are also using the Webkit CSS Gradients and Clipping.
I wanted to see how things were handled in Internet Explorer. When I look at a published iWork.com document in Internet Explorer a very interesting dialog box first appears:
It was indeed slow; it took about 17 seconds to load the document in IE. Clicking on individual slides took about 4 to 5 seconds to show.
I used the Internet Explorer Developer Toolbar to get into the DOM and see how things run on IE. The first thing I see is that the Canvas tag is in the DOM:
However, notice a glitch that it has the <CANVAS> and </CANVAS> tags as separate elements, which can sometimes happen when IE is dealing with unknown tags. They are also definently using VML (Vector Markup Language) on IE, since I see them pulling in the VML behavior for IE on the main page. I wonder why they didn't just use the Google-ExCanvas library that emulates Canvas for Internet Explorer (Disclosure: I work for a team at Google that promotes open web technologies like this).
One other thing I noticed is that if you are on the iPhone you get redirected to an iPhone version of the app. This just replaces the URL /document/ section with /iphone/. When you navigate to this you get a PDF version of the page -- that must be the iPhone version, a PDF file!
I wanted to see how the Pages application does things as well, so I published a document there. The published text is selectable in the browser! The document itself appears to be an image file. To do selection, whenever I run over some text it appears that a Canvas element is created and a 'highlighted' type graphic is drawn over the correct characters. Internet Explorer also supports similar highlighting, though on there it appears to be using VML to do the highlighting.
All in all this is a very interesting web-based application built with Ajax and JavaScript!
Robert Tomsick has been playing with Sandboxed Safari, a project that aims to let you use the Leopard sandbox feature with the browser, via a little launcher:
When Leopard was released, one of its big selling points was its "sandbox" feature. This garnered a fair bit of attention, as sandboxing is a fairly new feature for consumer operating systems.
A lot of people (myself included) assumed that Leopard's sandbox system would be used for Safari, seeing as how web browser exploits are a tremendously popular attack vector. Unfortunately, Leopard's version of Safari is not sandboxed. In fact, very little of the OS actually is. I don't know the real reason behind this, but I suspect it had to do with the release date pressures. Although Leopard ships with a number of sandbox profiles for things like syslog and ntpd, they are not used in the default config. Pretty much the only things that are sandboxed are mDNSResponder and some xgrid daemons. A quick look at the comments in the existing policies indicate that Leopard's sandbox system (named "seatbelt") is rather... buggy. As it turns out, the comments don't lie -- seatbelt *is* quite buggy, at least as of 10.5.6. Still, it's an extraordinarily powerful (not to mention cool) feature, and it's got a lot of potential to increase the security of Mac OS X.
But enough rambling about seatbelt. I'll make a few pages documenting what I've learned about it -- but until I get around to doing that, let's talk about Safari. Basically, I found that Leopard's sandbox system, buggy though it may be, is sufficiently mature as to allow the development of a seatbelt policy for Safari, albeit with some caveats. SandboxedSafari is my attempt at developing such a policy.
He continues to discuss the flaws: No plugin support, overly-permissive process-exec rules, no network filtering, no address book integration, no keychain, focus issues.
It will be interesting to see if Safari 4 + Snow Leopard gets us this out of the box.
New language addition to Objective-J: The @accessors keyword to eliminate the boiler plate code of writing setters and getters. Read more about it here.
Support for more classes like CPTimer.
Performance improvements all around, but especially in Objective-J thanks to a major rewrite of the parser.
Improved debugging tools and a new debugging “mode”.
Tom Robinson has created an interesting new tool called nib2cib that could lead to you being able to use Interface Builder to create Ajax frontends.
nib2cib is a command line tool designed for converting Cocoa’s nibs and xibs to Cappuccino’s cibs. It is still very much a work in progress, but is a good foundation for starting to fully support nib-style development on Cappuccino.
nib2cib converts nibs and xib that you supply to it on the command line to cibs. Given the new nature of this program, a good place to try it out is with NibApp:
$ cd /path/to/Cappuccino/Tools/NibApp
Copy or symlink the Cappuccino Frameworks to this directory
$ nib2cib HelloWorld.xib
Open /path/to/Cappuccino/Tools/NibApp/index.html in your favorite browser.
The basic task behind nib2cib is to convert NS-classes to CP-classes. When you give it a nib or xib file, nib2cib open the file, unarchives the actual NS-objects, converts them, and then archives the CP-equivalents.
I noticed the new iPod Engraving Gallery that is a nice use of Coherent to show a slick UI with engraving suggestions.
I was also talking to a friend that has leopard beta bits and he was playing with an updated Dashcode. It appears that the Coherent library is now used for the widgets too. Yay data binding!
We've talked a bit about Apple's extensions to HTML and CSS; <canvas> has of course gone on to much fame and fortune. Charles Ying pointed us to his CSS-VFX project which aims to be
a collection of components and code examples that illustrate the power of CSS Visual Effects. So far, only 1 gem that illustrates a popular RIA user interface demo, "Cover Flow" is currently available. If you'd like to see more, please don't hesitate to suggest something you'd like to see.
Charles has a blog entry with a video showing off a mobile Safari demo of using Apple's CSS Visual Effects to create a Cover Flow interface:
The demo makes use of a variety of these extensions:
* zflow starts by loading each image from the images array. When each image is loaded, we scale the image to fit in a square region, and apply 3D CSS transforms to scale it in place.
* Reflections - zflow then takes the scaled image and creates a Canvas element that contains a gradient alpha mask of the image’s reflection (using a “reflect” function to do this) and positions the canvas element in place.
* Touch Controller - zflow creates a TouchController object, who’s job is to field touch events from Mobile Safari and calculate an appropriate offset.
* Clicking - zflow detects when no move events have been made, and zooms + rotates the focused image forward by setting a “CSS Transition”ed 3D transform on the focused image. Clicking again transitions the image back.
* Inertia - zflow achieves inertia by setting the “transition timing function” of the “tray” to an “ease-out” function, which slows things down. On the touch end event, we calculate the projected velocity and set the tray’s target position to that location. CSS Transitions handles the decay in velocity as the transition timing function executes — slowing the tray down gradually.
It makes you wonder how many folks are going to need to learn the SDK in the future...
Wouldn't it be nice if we actually had a decent component model? Instead of making JavaScript frameworks have to mess around and try to create one on top of the crud they have to deal with?
This is what XBL 2.0 is all about. I talked about XBL in one of my Web Archeology posts, and how Jonas Sicking of Mozilla was back working on the implementation for Firefox.
This means that fairly shortly we will have Firefox and WebKit/Safari running with XBL 2 support. That in turn means that we will have an interesting component model for the first time, and who knows where that could lead us!
