Nice job including Excel! The world's most used programming tool! Having worked on that from as early as 1992 and as recent as 2018 I can tell you it is loved and used for everything from poetry to large-scale financial applications on Wall Street. Another useful tool used for long tail office productivity solutions was Visual Basic for Applications (VBA). Each Office application created an object model that exposed their capabilities inside Visual Basic. A myriad of 'emergent' solutions could be built satisfying specialty needs to the right of the tail built on more generalized capabilities found on the left of the tail. VBA hit some security snags in the early 2000s and VB as a language died out. But elements of this idea are re-emerging in the cloud version of Office using JS.
This is a great read, thanks for the clear articulation of this fairly nuanced topic!
My 2 cents at the risk of stating the obvious: designing for emergence leads to more expensive implementations than user-centered design. These meta designs that allow users the flexibility to design their own experience require building user controls for things that could otherwise be "hard-coded".
So the long tail can feel being stuck between a rock and hard place - (a) making incremental improvements that may not justify the cost and (b) taking on the risk of building something expensive and flexible, hoping that users find their own ways to use it. Do you have more insights to offer here? :)
Great post and it sparked a lot of interesting questions for me.
In particular, how do we know we are on the right path to building an emergent set of "things?" It feels like the new properties of the emergent system would be detected as "surprises" to the original creators. Maybe there is some ratio that you need to get on the other side of to say that there are strong emergent properties? But this would be a following indicator rather than a leading one...
Nice job including Excel! The world's most used programming tool! Having worked on that from as early as 1992 and as recent as 2018 I can tell you it is loved and used for everything from poetry to large-scale financial applications on Wall Street. Another useful tool used for long tail office productivity solutions was Visual Basic for Applications (VBA). Each Office application created an object model that exposed their capabilities inside Visual Basic. A myriad of 'emergent' solutions could be built satisfying specialty needs to the right of the tail built on more generalized capabilities found on the left of the tail. VBA hit some security snags in the early 2000s and VB as a language died out. But elements of this idea are re-emerging in the cloud version of Office using JS.
This is a great read, thanks for the clear articulation of this fairly nuanced topic!
My 2 cents at the risk of stating the obvious: designing for emergence leads to more expensive implementations than user-centered design. These meta designs that allow users the flexibility to design their own experience require building user controls for things that could otherwise be "hard-coded".
So the long tail can feel being stuck between a rock and hard place - (a) making incremental improvements that may not justify the cost and (b) taking on the risk of building something expensive and flexible, hoping that users find their own ways to use it. Do you have more insights to offer here? :)
Great post and it sparked a lot of interesting questions for me.
In particular, how do we know we are on the right path to building an emergent set of "things?" It feels like the new properties of the emergent system would be detected as "surprises" to the original creators. Maybe there is some ratio that you need to get on the other side of to say that there are strong emergent properties? But this would be a following indicator rather than a leading one...
Anyways, really interesting!