Auckland Interface Model: treating GUIs themselves as 'documents' and using transclusion to tie them to the application

Short version: use prototype tables everywhere. If a widget has no data for a given property look it up in the prototype. Then use a domain specific language to set up the GUIs, which buries the complexity of setting up the lookup tables and wiring.

Transclusion

Storing data as a reference to the actual data. For example quoting by pointing to a document and range that is copied.

Transclusions allow providence of data; ex. the quote can be followed to the original context.

Applying transclusion to GUI data flow: centralizing values of importance, referencing those from the GUI, automatic dataflow to update each GUI component when those values change.

Applying transclusion to making GUIs: importing properties from other templates, ex all "save" buttons transclude from a template for save buttons.

Adding search scopes while running transclusion: can look up values by following a chain of prototype tables, going up a level each time you don't resolve it, so contexts can intercept and replace templates.

Widgets can hold their own values or rely on transclusion; they work as prototype tables. If they do not have a local answer, follow the chain upwards.

Background

1996 study by Page showed 92% of people customize a word processor when presented with the option to.

Primary reason people did not customize was difficulty in making the customizations

GUIs tend to be created by program code in a general purpose language

The general purpose later makes the code more complicated than it needs to be

GUI code requires recompiling the application to meaningfully change.