# suggestions for dealing with multi-dimensional hierarchical data

We are designing a price calculation tool, for which every property adds a percentage increase/decrease in value of the object. Properties in combination with each other can have shared impact on the percentage increase/decrease.

An example:

our object is a laptop,it has a make, a type, memory, cpu, hard-disc (we have 13 such properties)

``````the make if it is "msi" has a 5% value increase
the type if it is "gx740" has 0% value increase
the memory if it is "8Gb" has a 0% value increase
the memory if it is "16GB" has a 5% value increase
the cpu if it is "8-core" and the memory is "8GB" has a 0% value increase
the cpu if it is "8-core" and the memory is "16GB" has a 5% value increase
the hard-disc if it is "ssd" has a 0% value increase
the hard-disc if it is "hdd" has a -10% value increase
if the make is "msi" type is "gx740" cpu is "6-core" has a -6% value increase
``````

Simply put we can materialize the full matrix from the direct increase/decrease of the properties and replace the percentages of impact of shared properties in the matrix.

Current ideas:

1. We create a form for each of the properties and allow the user to set the increase/decrease. We create a filterable grid-view with the materialized combinations and allow the user to fine-tune the specific combined combinations.

2. We create a form for each of the properties and allow the user to set the increase/decrease. We create a form in which the user can choose properties and set values for the selected properties and their state We create a list of selected properties so the user can go back later and modify the selections

The problems we have with our approach (1):

Each property will have a multiple possible values, the memory can be one of "4GB", "8GB, "12GB", "16GB",... Materializing such a big matrix is (i think) overwhelming. Lets say 10 states per property, which will give a total of 130 columns per row.

We have to create some intuitive method of editing a column within a selection instead of forcing the user to edit all rows by hand.

We have to somehow show to the user the reason why a property, if it differs from the default increase, is changed (is it because of a combination, of a column, or just a manual edit based on current demand)

The problems we have with our approach (2):

There now needs to be a way of allowing the user to choose which property or combination will take precedence over other modifications to such properties.

This solves the problem of the huge grid editing, but the materialized grid is still required to display the result of the created rules. A mouseover a value could be used to explain the steps used to calculate that value.

Context:

The system is not yet created, so no examples of how it is now are present. The user editing the values is a staff member in a admin environment, based on the matrix other users "appraisers" can make valuations for secondhand computers being offered from companies and consumers. The side of the system for the "appraisers" is just a form where they input the specs of the computer. The real use-case of the application is not for computers, but to make it easier to understand than just abstract hierarchical data and matrixes I have put it in terms of a computer.

The question:

Given the problemspace it will probably always be complex. We are asking for suggestions, and do not expect a solution for the system as a whole. There will only be one or two uses editing the data

• Can you please provide some context? E.g. Is this for an online store from which consumers will be ordering computers, or is it for internal usage within an organisation for staff quoting on products? Or something else altogether? I assume that the system isn't just being designed only for the users editing the data. Also, have you got any diagrams or screenshots you can share re your two current ideas? Commented Feb 17, 2016 at 23:40
• @Monomeeth i edited the question, sorry for the confusion. Commented Feb 18, 2016 at 15:24

Perhaps I'm just not getting it, but your two options sound confusing. My approach would be something different.

Using computers as the example, let's say you have three different main models of computer, all of which are configurable at the point of ordering. We'll call them A, B, C. Let's also assume that each model has three base models, based on the CPU.

So the user decides they want to buy a 'B' computer. They select that option and are presented with three columns. At the top of each column is a photo of the computer and below that a heading. The heading would be something like "2.0 GHz Processor". Within each of the columns you'd display a summary of the specs. Below is a mockup I've done:

Once the user selects the model they want, that's when they get taken to the configuration page. If we assume they pick the 2.0 GHz model in the above mockup, then the configuration page could look something like:

Notes:

• From a user perspective, use actual dollar amounts rather than percentages. It's much easier to understand.
• The layout on the right-hand side provides a much better user interface for users to navigate their options. It's very clear what they're choosing and the value difference.
• The shading highlights what they've chosen, thus providing reassurance to users.
• The dollar value at the bottom to the left of the 'Select' button updates as the user makes their choices. That is why the mockup shows \$1200 even though they originally selected the \$1250 option. This is because in the mockup the user has upgraded the processor (+\$150), kept the memory (\$0 change) and downgraded the storage (-\$200).
• And the summary under the main image updates to indicate the current configuration as selected by the user

My mockup is obviously only one example of how to visually present this multidimensional hierarchical data to the user, but the main thing is the logic of that presentation.

In your case you just need to work out what the base is to differentiate the computer columns (in my example it was the processor, but it could be the storage, RAM or perhaps even a combination of the two) and then presenting an easy user interface to manage the various configurations (easily defined choices, \$ values instead of % change, something clear to indicate the choices made, and a response to the user of the overall change in terms of the overall \$ value and perhaps even a summary).

Finally, if the context around your question was something totally different (e.g. a pricing tool for salespeople, etc) then the point of my mockup was just to show how you could manage your data. By using some sort of base parameter, you can effectively pre-filter your data in a meaningful way. In my mockup, reducing the complexity for the user was done by initially presenting them with three base options instead of one base option that would have required a lot more configurable choices for them to make.

• You have to define a "baseline" for each product. I would define it with all the options that have no value increase or decrease. If there are multiple options that do not have an increase or decrease pick the most popular option. If you don't know the most popular option with no increase or decrease, select the first. The customer should decide every increase or decrease to give them control.
– Bob
Commented Feb 23, 2016 at 20:04

Even the basics look like a challenge here:

• Without any combinations, the admin user already has to fill out 13 properties x 10 states = 130 percentages. (or 13 x 11 if each property would also need an "unknown" state).
• Each of these is a delta increase/ decrease from some base value. No simple task for even an experienced user to determine what the right number is to fill into whatever form/ grid is in the UI.

Some thoughts on how to help the admin user in the basics:

• For each property, provide some autofill. E.g. When percentage at the highest (e.g. 64Gb memory) is filled in (e.g. 10%), autofill all values between that column and the 0% column (e.g. 8Gb memory).
• pre-sort the 13 properties from most impact on value (such as amount of memory) to least impact (such as number of function keys): it is very likely that the user devote most thought and attention to items at the top of the list

The additional task of tweaking percentages for combinations looks even more daunting.

Some rules that seem to be suggested in the question:

• only combinations of 2 properties are allowed (not more than 2 properties, so no rule for "if 8Gb mem AND 8-core AND msi-type, then +8%")
• combinations are exceptions, so it may be expected that out of 130 percentages, only small part will have exceptions to the rule

If these rules are correct, then the 13 x 10 grid could be a way to display + let user set/ manage exceptions.

A UI approach could work somewhat like this (variation on direction 1 I think):

• Grid shows percentage for each individual property state (e.g. memory 8Gb: 0%).
• By dragging from one cell to another (e.g from mem 8Gb to 8-core), the UI shows diagonal line between the two cells, and the default combined effect (calculated combined percentage), allowing the user to override this with an exception (or remove a previously set exception and revert back to default).
• As soon as an exception is set, a graphic indicator (little orange triangle on top-right corner or similar) appears at both cells to convey that they have an exception defined.
• Clicking (or mouse-over) a exception indicator, will reveal all exceptions set for this cell (by showing lines from this cell to all other cells where the combination has an exception).

As far as I can deduce, there would never be a need to determine "precedence" of exceptions: there can only be one exception set to the combination of "8Gb AND 8-core", which would override the default of the combined individual percentages. This expection is not affected by any other exception of 8Gb in combination with another parameter.

UPDATE: here is a crude mockup of solution described above.

download bmml source – Wireframes created with Balsamiq Mockups

PS: The suggested solution above, as the question, assumes that the model with property-state-percentages is the right mode to determine value. This has some inflexibility of its own. Real life (and real users) may require other flexibility in model + UI. The current model and UI do not allow for rules such as "if housing = aluminum, value = + 100\$".

I've recommended this in another answer - but Apple's iPad pro method of vertically going through options accordian fasion and listing what you've selected in the titles of previous selections above is one of the best ways I've seen of dealing with this.

• the problem is at the "admin" side, eg where the percentages are inputted. The "user" side of this application is actually just an API and does not need any other interface Commented Feb 23, 2016 at 9:21