Harmonious Authorship from Different Representations Antranig Basman, Clayton Lewis and Colin Clark

Harmonious Authorship from Different Representations

Antranig Basman, Clayton Lewis

and Colin Clark

“Don't get involved in partial problems, but always take flight

to where there is a free view over the whole single great

problem, even if this view is still not a clear one.”

- L. Wittgenstein, Journal Notes, 1 November 1914

This Talk

1. Our domain and what we hope to do for it

2. Toy example and elaboration

3. Principle and idioms

4. Cognitive dimensions for collaboration

5. Wild claims and future work

1: Our domain

• The domain of user software

• Contrasted with the domain of expression of algorithms, programming language tools or systems software– Although our system shares some aspects of

a programming language, and constitutes a form of system

See Gabriel (2012) – “The Structure of a Programming Language Revolution”

What we hope to do for our domain

• Allow shared authorial access to the same programs operating on the same data by people– Of varying levels of technical experience– With differing goals and mindsets– Using different tools, representations and

modalities– Working in different times and places

2: A familiar example

• Maintain two fields holding corresponding values in two different temperature scales– e.g. SICP Example 3.3.5 (Abelson/Sussman

1984)– or NoPumpG Figure 10 (Lewis 1987)

User E

Application in textual (JSON) formfluid.defaults("examples.simpleRelay", { gradeNames: "fluid.component", components: { celsiusHolder: { type: "fluid.modelComponent", options: { model: { celsius: 22 } } }, fahrenheitHolder: { type: "fluid.modelComponent", options: { modelRelay: { source: "{celsiusHolder}.model.celsius", target: "{that}.model.fahrenheit", singleTransform: { type: "fluid.transforms.linearScale", factor: 9/5, offset: 32 } } } } }});

User A

Application in visual authoring tool

(mockup) User B

Decoration of application binding to an HTML interface

fluid.defaults("examples.relayApp", { gradeNames: ["fluid.viewComponent", "examples.simpleRelay"], components: { celsiusField: { type: "fluid.uiInput", options: { model: { value: "{celsiusHolder}.celsius" } }, fahrenheitField: { type: "fluid.uiInput", options: { model: { value: "{fahrenheitHolder}.fahrenheit" } } } }}); User D

Decoration of application allowing console interactionfluid.defaults("examples.reportingRelay", { gradeNames: "examples.simpleRelay", distributeOptions: [{ record: { funcName: "fluid.log", args: ["Celsius value has changed to", "{change}.value"] }, target: "{that celsiusHolder}.options.modelListeners.celsius" }, { record: { funcName: "fluid.log", args: ["Fahrenheit value has changed to", "{change}.value"] }, target: "{that fahrenheitHolder}.options.modelListeners.fahrenheit" }]});// User A'' uses the grade of User A' to construct an instance of our decorated tree typevar tree = examples.reportingRelay(); // This will immediately report: // Celsius value has changed to 22 // Fahrenheit value has changed to 71.6tree.celsiusHolder.applier.change("celsius", 20); // Celsius value has changed to 20 // Fahrenheit value has changed to 68tree.fahrenheitHolder.applier.change("fahrenheit", 451); // Fahrenheit value has changed to 451 // Celsius value has changed to 232.7777777777778

User A’

What we hope to do for our domain

• All the different worlds of these users should be freely connectable

• Shared authorial access to the application structure, as well as the data it manages

• Updates in any representation (to application structure as well as managed data) can be pushed to any other

3: What we hope to do for our domain (in the abstract)

• Enable open graphs of creators, sharing elements of a closed algebra of expressions– A new open/closed principle

• Creators are joined by an arc in the graph of creators if there is a means for one creator to influence the artefact received by another

• We want all arcs in our graph to be bidirectional– An example of a unidirectional arc is a compiler

Open/closed principle

“Any expression by a creator in a network can be overridden by a further expression from a further creator”

Some core idioms we will use• A lens establishes a

bidirectional, transforming relationship between two bodies of state (Pierce, 2009)

• We represent state held for our users, as well as that for our own bookkeeping, as publically addressable, naturally aligned state

- Related to notion of “Observability” (Kell, 2012)- Part of the work described under “bookkeeping” is that formerly done by “types”

Precedents for part of this idiom

• Naturally evolved web technologies are naturally oriented around observable state– Fielding’s REST implies that the “state” held

at the end of an HTTP endpoint should be considered “transferrable”

– The DOM API provides means for considering the live structure of an HTML document is observable

• We need to unify and extend such idioms into a self-sufficient paradigm

The space of selectors• As with CSS selectors applied to markup

documents, we provide IoCSS selectors identifying parts of an application design

• As with CSS, these are a central point for negotiation between different communities

"{that celsiusHolder}.options.modelListeners.celsius"

Head Context(matches upward)

Tail Context(matches downward)

Path Segments(linear reference)

Unifying requirements• We can do better than web incarnations of

these idioms through purposeful design– The underlying runtime can maintain “live

references” producing constantly observable incarnations of the referents of selectors

• Only passive observation is possible in the DOM

– We can manage granularity of observable updates explicitly through batching into transactions

• Transactions occur opportunistically in the DOM, driven by the requirements of the “principal consumer” (the rendering process)

• Etc.

4: Example 1: Inter-creator viscosity

• An analogue of the traditional cognitive dimension of viscosity (Bresciani: modifiability) which acts when multiple creators collaborate on the same artefact

• A design can become brittle in the face of multiple collateral modifications– For example, one creator may require to change the

containment structure of a set of objects in order to reflect a change in lifetime or other common fate

– The use of IoCSS selectors can allow other creators (in some circumstances) to maintain a stable binding onto parts of the design that are of interest to them

Example 2: Tracking sources and sinks meeting a criterion I

• A slightly different scenario involves one or more creators encountering a design with little or no initial knowledge (enabling cross-creator discoverability1)

• They would like to track the appearance and disappearance of sources and sinks of state which might be usefully transformed to bind compatibly

1Bresciani: inference support? Directed focus?

Example 2: Tracking sources and sinks meeting a criterion II

• Example: A system may dynamically connect and disconnect one or more pointing devices (sources), such as a head tracker, joystick, etc. which might be bound to a particular interface (sink)

• The integrator or user would like to be able to assert, dynamically, that their preferred device should be bound to the interface if it happens to be connected

• IoCSS selectors can be used to express the dynamic constraint in terms of the grade structure of the sources and sinks

A concrete incarnation

• For the currently active Prosperity4All project (EU FP7) we shall build a concrete embodiment of this system, the “Nexus”– An instance of the runtime exposing all the authoring

affordances described earlier over standard web protocols (JSON over HTTP, WebSockets)

• This will enable the interconnection of live bodies of state held by users in different communities using arbitrary technologies, assuming they can operate standard web protocols

Questions?

• Fluid Project – http://fluidproject.org

Lenscape Image: Kine Solberg

Extra Slides

Source code

Developer

Executable

UserCompiler

World of Compiled Code

A Closed Graph of Creators

Configuration

Developer 1

Configuration

User 1Aggregation/

Merging

An Open Graph of Creators

Configuration

Configuration

Developer 2

Developer 3

Configuration

Integrator 1

Configuration

Plugin author 1

Configuration

Integrator 2To

User n