Highlight changed items in the data-driven category editor

[Mike]

It would be nice to see at a glance which value differs from the default of the data-driven category editor.
Both the name of the group and the individual entries could e.g. have a different color.
So we would quickly recognize changes even if a group was collapsed.

In the sample: we changed something in "Formatting" and "Value Splitting".
Because "Formatting" is expanded, we directly recognize that "Use RAW value" is the changed element.
The used color is only symbolic, it could be a different one, or a different kind of annotation.


Basic Setting
Enabled
Automatic Update
Based on
...

Formatting
Data type
Use RAW value
Trim
...

Unify
Auto-group
Value Splitting
Hierarchy
Replace and Filter

[Mario]

If you really need this often enough to require a feature for this, why not just make a screen shot (<Alt>+<Print>) of a 'clean' setup for reference?
You can compare this with what you see after you did all your changes, if you are unsure about what changes you've made.

Let's see how many other users would see a need for this.
I'm sure this is doable somehow. I just don't want to make the effort until a suitable (aka 5+) number of users tells me that they would see this as a good enhancement.

[Mike]

why not just make a screen shot (<Alt>+<Print>) of a 'clean' setup for reference?

Direct feedback simplifies perception and speeds up action.

I think this could not only help those who use it more often, but also help beginners by being less overwhelmed by the number of fields. Even comparisons between the structure of different categories could also be made easier, because the relevant values would jump to the eye more quickly. As always, it's just thoughts, not expectations    A screenshot can also be a solution.

PS: I find data-driven categories very useful and versatile. It looks like I'll be using them a lot more often, even as a kind of foreman to facilitate more detailed actions later.

[Mario]

PS: I find data-driven categories very useful and versatile. It looks like I'll be using them a lot more often, even as a kind of foreman to facilitate more detailed actions later.

Data-driven categories are a very powerful tool to solve all kinds of problems. From automatically categorizing or clustering files to identifying metadata problems, consistency issues etc. They have been a great help during many migration projects.

I've looked into your request. I like the idea in general, but I don't want to spend a week to somehow implement this.
So I've made a quick check to see if the 3rd party user interface toolkit used for this grid to see if it offers some sort of "change indicatior". And, surprisingly, it does.

Two problems:

a) Their implementation is buggy. Sigh.
b) They can only compare the value that was in the grid when the grid was created (you open the properties dialog) and the values now in the grid.
This means you see only indicators for fields you have modified since opening the dialog. Not really useful, in this context. Somewhere else, maybe.
c) No indication is possible for empty fields (when they had values before) or fields with a value, which have an empty value as the default.

But the grid is filled from an underlying data structure maintained by IMatch. And this data structure knows the defaults (which is why you can just press the "Default" button in the dialog to reset all properties back to their default values). I could utilize this fairly easily this to indicate changes made to the data-driven properties compared to their original default values. c) is unsolvable.

This may be useful for some. Or not.
Since this was never requested before, I doubt many users have issues with this dialog.
But new users bring in new ideas, and I like to improve things in IMatch.
This is how the dialog looks now:



Maybe I do the same to some other critical grids.

[Mike]

I don't think such dialogs / grids were necessarily a problem, but optimizing for faster actions has its advantages. I am glad you think so too.
The faster and more relaxed users can use filters, categories, formulas, etc., the more likely it is that they are ready to use/test their full potential and work beyond the basic functionality.

Back to your new solution: It looks helpful! Still, I wonder if "c)" is really unsolvable because it would complete the feedback so well.

I have some experience with interface design, but not with programming. My amateurish question: Would it be possible to replace the concept of "real emptiness" of a field with a certain value / character which - by convention - means the same thing to iMatch? So IMatch would know the "truth" while the third party thing would work with "fake news" thinking that there is always value and be able to highlight changes? ... no idea whether and if so, how much effort it would cost.

To the user, the fields could still look empty (e.g. because the special character is hidden), or the sign would be at least visually inconspicuous.

PS: It is a good idea to also think about other critical grids in this context, as you said.

[Mike]

Today I finally managed to install the new update and saw the data-driven category settings dialog.

It's much better and more relaxed to work with. Thank-you!