I have this hierarchical structure. For simplicity & understanding's sake, let's call it a postal address:
country
--city
----street
------address #
--------apartment #
I need to provide settings to each apartment, but the data design allows a setting to be defined at the country level and will then "propagate" down to lower levels unless overridden at a lower level.
So, a setting x
could be defined at any level, but the one effective at the apartment will be the one defined closest in hierarchy to it.
So currently, I'm solving this by presenting settings together with an origin
field: When a user selects an item in the hierarchy, any setting defined at that level or above it will also contain a field specifying where the setting is defined (example for one apartment being selected):
setting origin value
deliver mail country (U.S.) xxx
take out trash street (Elm street) yyy
wash the dishes apartment # (3a) zzz
This solution however confuses the heck out of my customer (the manager that ordered the app).
They simply cannot comprehend the design. To put it simply: they would rather enter the same settings for each apartment than deal with this design. They would rather copy settings among apartments than just fix the one responsible for the entire street.
Now, as the ultimate solution, they demanded an Excel export / import that would flatten the entire structure into one spreadsheet because apparently this (flattened) structure is what they can understand.
What better ways do I have to present this data such that my customers will understand it?