When presented with multiple similar modules, all containing the same set of user definable parameters, what pattern is shown to best suit the widest range of user expectations?
Using a simple example, a root module can be "cloned" and all of the values are inherited to these new children. Values in the children can be updated as one would expect.
Because values are inherited from the parent, an update to the parent is picked up by any children. This allows a user to quickly alter values across a large number of modules.
The exception to this is if a child previously altered the value. This starts to become an issue, as well as others, when the the inheritance structure becomes more complex.
These issues (expressed in image below) can be summarized with: (1) values not changing when the user expected them to, and (2) values changing when the user didn't expect them to.
In this situation - the root (left most module) has 3 children (center modules), each of which has several children (right bullet lines) that might also have children (per indentation).
This unexpectedness could be overcome/limited through process; where users are told (by there management) not to inherit beyond a certain level and/or not to change child values at a certain level. But the complex process becomes an issue itself at some point.
Multiple Dissimilar Value Editing:
In this scenario every module would be decoupled and the user would have to update each value individually. A multiple selection pattern could be set up to make editing the same value across multiple modules easier:
This pattern is found in many consumer applications, iTunes being one example where I can modify information for multiple music tracks at once. In some cases values can not be updated when multiple tracks are selected and an error is presented when that is changed.
The child-parent relationship would be only on creation in this case. A new item created could inherit from a parent, but would become its own entity upon creation. Any further action on the parent or child would only affect that specific object.
Trouble here being we have a single set of parameters representing multiple modules with (likely) differing values, which can create confusion for determining the original values.
Which pattern is shown to best suit the widest range of user expectations, or is there another alternative (which captures a wider audience) that is not explored here?