Enabling environments focus on doing what’s enabled, but Novices in enabling environments often can’t do what’s enabled. A well-designed Enacted experience can allow participants to immediately experience doing what an environment enables.
For instance, say a software company has special testing infrastructure which enables their engineers to make large changes confidently. A manager might introduce a new engineer to that infrastructure by assigning him a feature which the manager knows will require modifying well-tested code. The engineer will see that adjacent code includes references to the testing framework and will integrate his new feature accordingly. Code review might create useful discussions about the tests. The testing infrastructure enables the engineer to land his new feature confidently. Because of this experience, he can test future features with ease.
By comparison, imagine that the manager hadn’t done this. Someone else asks the engineer to extend a feature which doesn’t already use the special testing infrastructure. The engineer might not think to use it. Someone might point it out to him in code review and send him some introductory documentation, but reading that is an activity about his goal, so he’s less connected to it. He tries to just dive in, but he finds the testing infrastructure challenging to integrate, since his module has no examples to modify.
Unfortunately, Enacted experiences are hard to author and Enacted experiences are hard to distribute. Still, Enacted experiences have incredible potential as a mass medium. I see this as the central promise of media like the Primer: The Primer++ is embedded in a field, bootstrapping participation through enacted experience.