Act 5, scene 20: Drill-down: the interface

Scene 20: the interface

Next comes the interface, where the customer wanted the product personalised down to the individual user and operable by their own agents. With a grammar of what a screen can be, a screen becomes a document too: which entities it shows, which fields, in what order, with what validation, all checked against the domain's rules. Each tenant's layout, or one user's, is a variation of the screen's document, which the agent can write. In an existing product, the compiler emits those screens as source code at build time, reviewed and deployed through the normal pipeline, so each variation is a build. Composing the interface at run time, per user, needs a platform that accepts a desired-state description, which usually means new platform work. For the provider, there is a fixed cost to build the grammar and the compiler, then a cost per screen that falls as converted screens become worked examples, with close review of the first ones. The evidence supports converting screens at a faster rate, with review still needed. The same language is what a customer's own agent needs to operate the product in the domain's terms.