Document Definitions

DocumentDefinitions is a simple set of reference definitions (associated with the document-based model for UserInterfaces) for use in other pages that reference this one, without introducing a page-per-definition (since WikiIsNotaDictionary). This page gives reasonably precise working-definitions to several words associated with documents, interfaces, and features associated with them that might otherwise be too fuzzy for distinction.

You are not expected to agree with the following definitions, only to understand them in their context and resist pointless LaynesLaw battles. That said, the definitions do attempt to remain reasonably consistent with the common use of words.

document: a presentation of information and options designed for consumption by humans, with a default bias towards two-dimensional static visual presentations of text and graphics. The 'document' concept extends in general to the auditory and temporal dimensions (as per: sounds, animations, music, video) designed for consumption by humans, and could presumably be extended to other senses. Documents tend to be composable and decomposable, and as a consequence the boundaries between them are arbitrary and are often chosen for convenience to the discussion at hand. Sensors, actuators, commands, queries, processes, and protocols are examples of things that are not documents, though information about these things can be presented in documents.

active: A document is active if it presents input options to a human operator. Traditional input options include push-buttons, knobs, sliders, toggles and radio-buttons, text-fields, menus, and drawing canvases. These options are designed largely around the common input devices - mouse and keyboard. However, one can provide activity in other ways: gestures, drag-and-drop, context menus, focus, hooking joysticks and microphones and cameras, command-lines, etc. Degree-of-activeness can be measured in terms of spatial properties (e.g. percentage of document supporting user input) and logic costs (fraction of document definition associated with presenting or providing input options, but not to processing the actual inputs).

live: A document may be live, in which case it automatically reflects updates to external systems - specifically excluding user input - over time. Example features include dials, gauges, lights, rolling text, progress bars, alert-icons, changing text, pop-ups. Examples of live documents include RSS feeds, web cameras, stock tickers, etc. Liveness can be measured in degrees in terms of reactivity (e.g. latency between an update to a system and its corresponding update in the document), spatial properties (percentage of document subject to update).

static: A document that is neither live nor active is static. Static documents might still be subject to update, but said updates won't be seen automatically. Static documents can still be temporal in nature (such as sounds, movie clips, and animations). A bit stronger than 'static' document is a dead document, which will never see updates. Documents tend to become dead through neglect, completion, or versioning.

interactive: A document is interactive if it is active and there is a causal feedback loop such that activities cause changes to the document. Interactive documents don't need to be live (as evidenced by simple calculators, simple video-games, etc.).

interface: A document is an interface if it is active and the activity causes a command to an external system. Doesn't imply live feedback as part of the document. Interfaces without feedback are often applied usefully when the external system being controlled is within visual or auditory range of the operator. The degree to which a document is an interface is determined both by how active it is and how many activity options influence the external system as opposed to modifying the presentation of the document.

live interface: an interactive interface document such that at least one bit live feedback is causally influenced by external systems that are causally influenced by activities. I.e. there exists a causal interactive loop via influence on external systems, as opposed to 'document local' feedback loops.

document definition: A complete, serialized representation for a document. Document definitions are immutable, but that fact does not hinder liveness (which may be achieved through keeping a document definition up-to-date relative to its source document-object or through the document composing external data-sources such as other document-objects).

document object: A service that, upon request, provides a document definition. The traditional example of a document-object is a file, but documents can just as easily be requested from live systems, and it isn't unreasonable to even treat queries to databases as 'document objects'. 'Document object' in the purest sense should be understood as possessing 'universal identity', such that two distinct requests for the document object without any intermediate updates to the object can be guaranteed to return the same document definition. (Caching and other practices relax this purity in order to improve performance, but understanding 'uniqueness' of document objects still remains important to understanding the document-based UserInterface model.) Document objects give identity to documents. For example, concepts such as create, update, delete, history, versioning, difference, DataDeltaIsolation, and subscription are not relevant for document definitions but are meaningful when applied to a document objects.

document server: A service that, upon request, provides or creates+provides a document object. That might sound incredibly generic, but this definition is meant to be interpreted in a rather literal sense: (a) the provides "or" creates+provides MUST be a decision that can (at least potentially, unhindered by protocol and semantics) be made "upon request", (b) it provides a "document object", as opposed to returning a document definition, which means the return value from this request is an identifier for a document object (generally a URI). With that clarification it might sound too narrow, but it is acceptable to view "returning a document definition with an implicit order to 'clone' with a new 'self' identity" to be a mechanism for creating+providing a document object, at least so long as said document object arguably has independent identity. Under this definition of document server, a traditional FileSystem or FTP server doesn't qualify as a document server (since FileSystems are traditionally not supposed to create documents upon request), but any modern WebServer certainly qualifies (with Dynamic HTML and forms being 'new documents' - TiddlyWiki is an extreme example of how such divergence can occur). This definition for 'document server' makes distinctions that are irrelevant until considering multi-user environments, the possibility of shared forms, and issues of divergence that are more significant than merely being out-of-date with the source.

shell: a framework and LayerOfIndirection that mediates between an application and an application platform to produce a UserInterface. Part of the application model of UserInterfaces. While "shell" in common vernacular refers to the CommandLineInterface, shells may also be graphical in nature (Windows Shell, Gnome, KDE). The indirection enables a great number of features, such as consistency and stylizations and multiplexing of some user input.

application: a program that produces a usually interactive UserInterface via interaction with a shell. Applications are often distinguished based on the frameworks against which they were written, such as 'command line application' vs. 'Win32 application' vs. 'MFC application'. However, application is mentioned here to distinguish the application model for UserInterface from the document model for UserInterface. An overview of the most relevant differences (and the reasons for their relevance) is at the bottom of the page.

application platform: the platform atop which application programs are built. Usually refers to an OperatingSystem, a VirtualMachine, or a WebBrowser.

browser: a browser is a UserInterface service that provides meaningful interaction and navigation within a system of objects. A 'document browser' would be a browser that is targeted to interact with document objects, but there are other sorts of browsers (ObjectBrowser, FileSystem browser). Assuming a document browser, the primary "meaningful interactions" would include display of documents, keeping said display up-to-date, zooming, navigation between documents, support a multi-tasking user by allowing multiple documents to be displayed simultaneously, multiplexing user inputs for activity between and within documents, and sending appropriate command-messages as a consequence of said activity based on object definitions.

In the 'pure' sense, a mere 'document browser' should not have any responsibility for maintaining or hosting document objects.

However, a typical WebBrowser also shoulders this responsibility due to Dynamic HTML and forms. Hosting document objects introduces a significant amount of complexity. As two examples, one now needs a document object model, there are 'concerns' for such issues as persistence and recovery that simply don't exist if all document objects are hosted externally, and so on. Introducing this extra responsibility essentially to a document browser essentially forces the browser to serve a dual role as an application platform.

document object model: A language for selectively identifying parts of a document definition. A necessary prerequisite for allowing a language to manipulate parts of a document definition. A document object model (or more than one) is used in DataDeltaIsolation and for allowing browsers to act as application platforms (host documents and accept commands to update said document). The 'trivial' document object model is simply to treat each document as the sequence of bits used to serialize the document definition, but this model is rather difficult to program against. 'DocumentObjectModel' with capital letters refers more specifically to the W3C standardized DocumentObjectModel for XHTML and XML.


Comparison between Application and Document models.

Application Model for UserInterface

Entities Relationships: Properties: Document Model for UserInterface (pure, rejecting browser-as-application-platform)

Elements: Relationships: Properties:

HtmlDomJsCss and WPF might be considered hybrid models of Application UI and Document UIs.


Related: DeclarativeGui, AutomaticVsManualPlacement, ObjectBrowser, CapabilityUserInterface, ZoomableUserInterface, KillerUserInterface

EditText of this page (last edited September 27, 2009) or FindPage with title or text search