Thinking in Inheritance vs Editing Multiple Disimilar Values

Question

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?

Inheritance:

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.

Given these...

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?

Answer 1

Your question is one that Intuit has put a lot of time and effort into putting into practice with its TurboTax UI, where parent activities are done first, and child forms take care of the rest. The entire procedure of necessary work has been (as far as I can tell without being involved in its design) ordered from parent-to-child. As you may realize, children can be parents, too, so this is not a dualistic ordering, but a tree ordering of actions.

And then there are exceptions to the whole thing that can be taken care of. If step 15 necessarily affects step 9, then some reworking will need to be done by the system, and the changes explicitly communicated to the user. But this is an acceptable and expected experience. As a user, I'll probably realize that my action may affect something I did before, so I will expect the system to know the same.

So in my opinion, inherited values is the user-preferred, and less taxing option (no pun intended), especially IF the purpose of your interface is to get the user through the work accurately and without redundant activity.

Your general question, I'm sure, is applying to a very specific set of circumstances. Determining "widest range of user expectations" can be done through persona work and testing.