User interface design for editing large configuration parameter set.

[cbfsystems]

I am working on an application that will have a large set of front panel controls to view edit configuration parameters.  Handling all these controls is causing some frustration and complicated code and I'm hoping for an infusion of wisdom from some more experienced/smarter people out there.

The application controls several pieces of test hardware and has a configuration file that comprises I/O channel assignments and calibration parameters for the various inputs and outputs.  The file has about 100 configuration parameters.  The user should be able to view and edit the configuration parameters.  There are obviously too many parameters to view simultaneously without scrolling.  I have been working toward an implementation with the parameters divided up between various views.  

In the past, I have handled this type of situation using tab controls.  Each parameter had an associated control and the many controls were distributed across the tab pages.  The user experience was okay, but the block diagram complexity got high because of the large number of controls.

I have been trying a different approach lately using the actor framework and a subpanel.  The many controls are divided up between various actors.  To show different parameters/controls, the front panel of the appropriate actor is inserted into the subpanel of a managing VI.  The user experience with this approach is almost the same as with the previous use of tab controls.  This doesn't seem to have reduced the code complexity though, in fact it seems worse.  Any single VI is simpler, but there are now many actors and message paths.  One actor manages the complete configuration parameter set so that it can save/load parameters to/from a file and it holds the subpanel.  It sends messages to each actor that displays a subset of the parameters and each of these communicates back to the managing actor when the user changes a parameter.  The VIs are multiplying!

It seems that one reason this subpanel/actor approach is getting so complicated is because the various subsets of configuration parameters are not really independent - they are related to and have to communicate with the managing actor.  Maybe the controls should not be divided up between different VIs (actors in my recent implementation).  Here's another idea.  I could use the a single actor (the managing actor from the previous scenario) with a tab control to display the parameters, but group all controls on each tab page into a single cluster for that page.  This would reduce the number of controls on the block diagram.  An event loop would hold the complete set of parameter values in a shift register and would update these whenever a control changed.  It would also send a message to the actor core, notifying it when the parameter set changed.  The actor core would handle saving/loading configuration parameters and would communicate with the event loop.  There are still some messages to send, but fewer than in the multiple actor case.  There are not a lot of event cases because the controls are grouped in clusters.  

I'm leaning toward the last solution at the moment, but but look forward to some advice from others.  Maybe one of the methods I have described is preferable, maybe there is a way to tweak one of the methods to improve it, or perhaps there is a completely different way of handling configuration parameter editing.  I look forward to people's suggestions.

[PalanivelThiruvenkadam]

Its Better to attach the existing FP Snap so that it gives a clear view on how an alternative solution can be given.

[cbfsystems]

Here are a couple of screen shots of the front panel in the current, multiple actor, implementation.  The user selects which subset of the configuration parameters to edit using the listbox at the bottom left of the screen.

[aputman]

I use the Options Dialog Framework which is based on the code used in the Options window within the Labview IDE. 

[paul_cardinale]

Consider a structure like this.

[cbfsystems]

Could you provide your file in LabView 2015 version?  Thanks.

[RavensFan]

---

@paul_cardinale wrote:

Consider a structure like this.

---

No. No. No.  Don't use that.  The front panel is just fine.  But the block diagram with a event structure buried inside an event structure is asking for problems.

[cbfsystems]

This is interesting and I am looking into it.  More specifically, the link to the Options Dialog Framework led me to another framework that has my interest:  the Configuration Editor Framework http://www.ni.com/example/51881/en/  The CEF is intended for hierarchical configurations.  My application includes a fairly complex, user configurable, test configuration which is like what the CEF seems to be aimed at.  The problem that I described in my initial question is simpler, but could be handled by the CEF also.  This is probably going to take a bit of work to figure out, so I will report back later.

Thanks for the suggestion.

[paul_cardinale]

It's a good architecture that makes sense in this case.  While nested event structures can be susceptible to problems, it's not hard to debug such problems.

Admonitions such as "Never do this", "Always do that". are bad.

[cbfsystems]

I'm interested to take a look at the architecture with the event structures, but don't have LabVIEW 2016 installed yet.  Could you post screen shots or post the code in LabVIEW 2015 version?