Skip to main content

Reification, Polymorphism, and Reuse

Michel Beaudouin-Lafon and Wendy Mackay set out three design principles for visual interfaces, arrived at while rebuilding Design/CPN, a tool for editing and simulating Coloured Petri Nets — a genuinely complex, non-linear professional workflow if ever there was one.1 The resulting interface, cpn2000, dispensed with pull-down menus, scrollbars, and even the concept of selection, and did more, not less, than the tool it replaced. The three principles explain how.

Reification

Reification is the conversion of a command or a passing state into a persistent, manipulable object. The paper's own example is alignment. An "Align" command performs an action and forgets it happened; the objects it moved carry no record of why they ended up where they are, and a later change to one of them breaks the alignment silently. A guideline, by contrast, is an object. Objects can be snapped to it, moved with it, added to it, or removed from it, indefinitely, after the fact.

Translate this into DCC terms and the pattern recurs everywhere a command quietly discards the reasoning behind it. A "snap to grid" toggle is a mode, invisible once set, indistinguishable in its effects from careful manual placement. A visible, draggable guide object is the same intent made persistent — you can see it, question it, and move it, weeks later, without having to reconstruct what you were thinking. The same distinction applies to style: an "apply style" command that copies attribute values once is inferior to a style object you can pick up, inspect, and reapply, because the object keeps existing after the command has finished running.

Polymorphism

Polymorphism is the discipline of keeping a small, fixed set of commands — move, copy, delete, apply-style — and making them work across every object type in the system, rather than letting each object type grow its own bespoke command surface. Beaudouin-Lafon and Mackay's own case is the "next frame" simulation command: applied to a single transition it fires that transition; applied to a page it fires any transition on the page; applied to the whole workspace it fires any transition anywhere. One gesture, one command, and the scope changes with the object, not with a different button for each scope.

This is the same argument made from a different angle in Consistency vs Clarity: a small vocabulary of commands that behaves the same way everywhere is what lets a user's learning transfer, rather than needing to be relearned per object type. Where that page discusses consistency at the level of visual and interaction design, polymorphism supplies the underlying reason it works — the commands genuinely are the same operation, not just styled to look similar.

Reuse

The third principle is capturing patterns of use without asking the user to name, save, or otherwise administer them. The paper's style picker is the clean example: lifting a style from an existing object and reapplying it elsewhere requires no "Save Style" dialog: the object's attributes were always available for reuse, because reification had already made them a first-class thing to reuse. Recently used values, extracted styles, undo history — none of it needs a save action if the objects and their history are already reified.

Workspace's discussion of "workspace seeding" — Barbara Mirel's observation that expert users pin, colour-code, and annotate their working environment as they go2 — arrives at a related conclusion from separate research. Both point at the same design instinct: professionals accumulate useful residue as they work, and software that forces them to explicitly package that residue before it counts as "saved" is asking them to do bookkeeping they never agreed to. Reification and workspace seeding are two independent theoretical routes to the same rule — capture what the user has already done, don't wait to be asked.

Why This Matters for Direct Manipulation

Taken together, the three principles explain something that looks, at first, like a contradiction: professional tools that strip out the traditional furniture of menus and dialogs in favour of direct, in-context manipulation do not become less capable for it. They become more capable. Reification puts the functionality into the objects themselves; polymorphism keeps the commands that act on those objects few and learnable; reuse means none of the accumulated work has to be re-entered by hand. The object stops being a passive thing a command is applied to, and becomes the place where the command's effects, and the record of how it got that way, actually live.


Footnotes

  1. Beaudouin-Lafon, M., & Mackay, W. E. (2000). Reification, polymorphism and reuse: Three principles for designing visual interfaces. In Proceedings of the Working Conference on Advanced Visual Interfaces (AVI 2000) (pp. 102–109). ACM.

  2. Mirel, B. (2004). Interaction Design for Complex Problem Solving: Developing Useful and Usable Software. Morgan Kaufmann.