The requirements

My application has hierarchical contexts which are configured via JSON properties.
Those are overlaid to create a single JSON properties file.
Properties can be inherited or overridden based on parent/child relationships.
The user can view or edit the properties within each context.

When working in a context that has a parent, the user needs to see properties that are inherited or overridden.

Example properties files

The source properties, each in it's own context, may look like this:

// Root
{
  "A": "init_a_value",
  "B": {
    "C": "init_c_value"
  }
}

// Child of Root
{
  "A": "override_a_value",
}

// Leaf of Root
{
  "B": {
    "D": "add_d_value"
  }
}

When that is all rolled together (or "composed"), you get this consolidated result:

// Leaf Composed
{
  "A": "override_a_value",
  "B": {
    "C": "init_c_value",
    "D": "add_d_value"
  }
}

The challenge

When the user is editing properties for each context …

How can we make these factors clear?

  • Hierarchical relationships
  • Inheritance
  • Overrides

What we've tried

One idea:

  • Visually flatten the parent/child relationships into dot-separated notation.
  • Show two tables: Inherited (read-only) properties and editable properties at the current context.

In practice, it could look like this:

+----------------------------------------+
# INHERITED                              #
+-----+---------------+------------------+
| KEY |  SOURCE       |   VALUE          |
+-----+---------------+------------------+
| A   | Child of Root | override_a_value |
| B.C | Root          | init_c_value     |
+-----+---------------+------------------+

+-------------------+
# EDITABLE          #
+-----+-------------+
| KEY | VALUE       |
+-----+-------------+
| B.D | add_d_value |
+-----+-------------+

[ + Add new property ]

We could also cross-out an inherited property that the current context itself overrides to show the side effect of adding a property that already exists.

Bottom line

Is there a clearer way to display this data?
Does anyone know of any examples of this in action?

  • Kindly transfer this question to Stack Overflow. This isn't the right community for your question – Shreyas Tripathy Jun 7 '17 at 5:52
  • 1
    If I've understood correctly, the question is about how to design a GUI for editing data in a JSON tree, in which case it's a valid UX question. That said, the Stack Overflow audience might have a better technical perspective. – Matt Obee Jun 7 '17 at 8:35
  • 1
    Yes this is a UX question not an implementation question. I don't know why that isn't clear. Is there a way to petition the hold put on this post? – Basil Jun 8 '17 at 16:31
  • 2
    This is definitely a UX question. Just because the data he's trying to display looks like code (it's not code, it's structured data), it doesn't mean the question is about programming. In fact there's an entire field within UX dedicated to the user experience of programming languages and APIs, so it seem's very naive to put this on the grounds that something which looks like code is involved: sites.google.com/site/apiusability/resources/publications – Joel Tebbett Jun 9 '17 at 12:54
  • 1
    It was definitely not only JSON originally. But thanks to @plainclothes for cleaning it up. The structure of the data is an important factor of how it is/can be displayed to the user so needs to be included. I can't imagine designing a data-management user interface without understanding how the data interacts. – Basil Jun 11 '17 at 18:42

The closest I have seen is the Firefox configuration, which effectively uses a dot notation for the hierarchy. Each property is "user set" or "default".

"User set" values are bolded to draw attention to them.

Firefox config screen

https://support.mozilla.org/en-US/kb/about-config-editor-firefox

  • Upvoted. I've worked on displaying JSON data hierarchically and it's always ended up confusing the user when the hierarchy goes beyond two levels. Dot notation works much better, though don't feel that you have to delimit it with a dot. Arrows or even plain spaces might be more readable. – Joel Tebbett Jun 9 '17 at 13:50
  • If you went this route do you think it'd still be worth supporting arrays? Line 1: A.B.C[0] || 123 Line 2: A.B.C[1] || 456 Seems like that starts to get hairy. – Basil Jun 11 '17 at 18:46
  • An array would be a value, so you would incorporate the array into the Value field in the above example rather than into the Preference Name. How you would display an array is perhaps the subject of an entirely new question :) – Joel Tebbett Jun 12 '17 at 9:13

What we ended up starting with how Sublime Text shows their application preferences: two JSON panels, one read-only on the left showing the defaults, and the one on the right showing customizations. In our case, the left shows the composed inherited data from higher contexts. Unfortunately, this view does not really support showing which context specific data came from out of the box. Maybe later we could add some hover text when pointing at a particular key showing the context that key came from..

Our side-by-side prototype

It's not as sophisticated as I was hoping to get, but it has the benefit of low upfront cost. We can get this in front of our users and see how they use it to better understand how it can be further developed.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.