Interactive Document

An InteractiveDocument is a document that accepts and responds to user input. Significantly, it is a document. Note the singular!

The fundamental difference between 'document' and 'application' regards state and identity: If you open a calculator 'application' ten times, you'll have ten different calculators each with their own state. If you open a calculator 'document' ten times, you'll have ten views of one calculator. Pressing a button in one view should be, to some degree, visible in all others. (Ideally, you could even see the button-press animation and hear the button-press click sound from the other views.) In a document-based UserInterface, if you want ten calculators you'll need to explicitly create ten documents with different names - which really means: different URLs.

Different 'views' of an InteractiveDocument can differ, however. For example, the same calculator could be presented with different styles, different rotation angles, different scrollbar locations.

InteractiveDocument is a mode for UserInterface development that is potentially quite competitive with RichInternetApplications. In particular, the InteractiveDocument model allows opportunity for further improvements:

Support for bookmarking and history of views.
Migration, e.g. ability to bookmark a view on your laptop then open it on your desktop.
Easily open multiple 'views' of the same system and edit whichever is most convenient.
Collaborative multi-user editing by default.
Composition. URL per document allows hyperlinking and transclusion between live documents in ways that are not feasible using modern application architectures. The composability also makes the documents much closer to language design - e.g. objects might be represented as documents.
ZoomableUserInterface. 'Views' are cleanly separated from the document state, so it becomes feasible to navigate views in a rich environment. A lot of work is still needed for this feature, though - it would greatly affect how documents are described and composed.
Transclusion and mashups - i.e. ability to take just a button or text field from one document and present it in another; ability to view and extend a system in ways that the original developer did not imagine. This requires exposing interactive elements as URLs. (Of course, some developers are against mashups for these same reasons - something about artistic control.)

One could implement apps atop docs easily enough, by (for example) explicitly cloning a prototype calculator upon the press of a button.

Challenges for InteractiveDocuments:

Keeping (or replicating) state and code near the users. This suggests some sort of mobile code or distributed database. This is important for performance and offline support. Making this work without a lot of complex code and overhead would be very important.
Consistent views. Basically, InteractiveDocument suggests some sort of synchronization between views, similar to a PublishSubscribeModel. Ideally, the design is 'eventually consistent' so that all connected users eventually have the same view of the system.
Teaching new idioms to developers. For example, with WebApplication you get a fresh form whenever you load a URI, and you 'submit' that form when you press a button. With InteractiveDocument, forms with the same URI are shared, so you would instead press a button in order to create a 'new' form, then you would fill the form and perhaps toggle a checkbox to activate it. Similarly, you can treat a lot of 'state' a simply different 'views' of a system... e.g. which branches of a drill-down tree are visible could be treated as a 'view' of a document. Potentially, you could bookmark and share such views.
Offline accessibility. Ideally being offline doesn't disrupt your work entirely. You want to continue work with the application then synchronize once connectivity is restored, hopefully in a consistent manner and minimum code overhead.