How best to present origin in a hierarchical settings structure

Question

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?

Answer 1

It sounds like you're offering an affordance that the users would benefit from, but you're explaining it in the terms that make sense to you. Rather than using the concepts of propagation and hierarchy, I'd set it up to use the more familiar "apply to everything like this" pattern, which commonly shows up in applications and OS functions.

Your presentation of the feature would sound something like this:

1. Here's the interface for entering an apartment.
2. Here's how you can set a setting for the apartment.
3. Look, there's a neat feature where you can select the city, enter a setting, and press the button marked "apply to all apartments in this city."
4. Don't worry about losing settings you already put in. The program will ask whether you want to change the settings for every apartment, or only the ones where this setting is currently empty.

This is less elegant from the backend. Rather than a CSS-style solution where multiple settings exist and are ranked by specificity, you would walk through the hierarchy at that moment and apply the setting to each individual apartment. It means more work for your users because the new setting won't become a default for new apartments added within that hierarchy.

However, it sounds like this would be much less cognitive work for them, because it's more in line with their expectations and doesn't require them to learn how to think in terms of inheritance. If they're pushing back this hard against your current proposal, then this might be a good compromise.

---

Another point is that your "settings" look like things I would call "tasks" or items." To me, "setting" refers to a configuration option. You might want to see if this is causing additional confusion.

Answer 2

My first thought would be stealing a page from Google Dev Tools view of CSS style hierarchies. It was designed to show the exact same thing, all the applied settings of an elements ancestors in order of scoping precedence. To do this they simple list this they simply list the settings starting with the applied setting (highest specificity) followed by the inherited settings from all higher levels crossed out.

Now obviously this exact design is very technical and bare, it would have to be adapted and cleaned up. But you can quickly and easily see that the blue setting at the apartment level is overriding the state level green setting and the country level red.

Answer 3

Either hardcode default values for each or add a "setup" page to allow the user to do so (i.e. deliver mail=xxx, take out trash=yyy, and wash the dishes=zzz).

When viewing an apartment, list each with its value and some indication of the level the value was override. While I use text below, consider using an icon, and consider leaving blank if using original default value.

• deliver mail: xxx
• take out trash: abc (overridden at address level)
• wash the dishes: zzz

If the value of "take out trash" is clicked, a dialog is displayed. If the value or the "empty" indicator (I am using --) on the dialog is clicked, allow the user to inline edit it.

TAKE OUT TRASH

• country: yyy
• city: xyz
• street: --
• address #: abc
• apartment #: --

Answer 4

It depends on the amount of customization required by the USER.

1. If the customer requires high level of customization even for the lowest level, then a tabular approach which is already presented serves the purpose.

2. If there is low level of customization i.e. few exception at the lower levels then a grouping approach for hierarchy has a benefit. An example for implementation is as attached. An excel based tabular approach might not be that convinient. Sample XML file