Advice on GUI needed

HHMeyer · ‎06-07-2011

Since I am not a real GUI and usability guy, I'm looking for advice on the GUI for a part of an application I'm currently writing.

Background:

We have power supplies that we control remotely using LabVIEW applications via a serial connection (developed in-house, the power supplies as well as the applications). These power supplies have built in 60 memory banks which can store the user accessible settings like output voltage, output current and so on (about a dozen or so values per memory bank). The power supplies allow the user to concatenate these memory banks into sequences. The length of a sequence is only limited by the internal memory of the controller of the power supply and goes into the hundreds of possible steps. The arrangement of the used memory banks within a sequence is only limited by the imagination of the user. The duration of every step within a sequence may vary within the range from 0.5s to several hours. So far these configurations have been made using a 2x16 character display and a few buttons on the front panel of the power supplies, but that is not very handy. My task is to produce a LabVIEW application with easier to use user interface.

My ideas so far:

The GUI for a sequence: Since a significant part of a sequence is the time, I think about having a window or a part of a window that allows for scrolling horizontally to represent the time on the x-axis. Into this scrolling area I would like to put representations of the memory banks in the appropriate timely order for a sequence. The representations should indicate the number of the memory bank used and ideally a few key settings. A pictorial representation of the memory bank in question would suffice, maybe with some information about the major settings in the bank in the image. Since I also do web authoring, I have the the idea of using a so-called carousel linke the ones used for the display of a subset of a range of images on websites, like this one here:

The GUI for the configuration of a memory bank: I would go along the lines that evolve from the solution of the upper problem to make the two interfaces as consistent as possible. Since it is most probably impossible to display all the available 60 memory banks in in standard window, offering a subset of all memory banks of them to the user and allowing him to choose one memory bank to edit seems appropriate. Again the question for a scrolling interface comes up.

Obstacles to overcome:

presentation of a table with 60 sets of about a dozen keys
editing of said table
presenting a timeline with an unknown number of representations of memory banks in a sequence
allowing to edit/rearrange the order of used representations of memory banks in the timeline of a sequence

The first to points I can do technically. But the last two points are giving me a headache because so far I did not see anything like it in the examples or elsewhere.

Any suggestions on the look and feel and the implementation thereof are welcome.

Regards, Hans
PS. I'm using LabVIEW 8.5.1

F._Schubert · ‎06-07-2011

I'd just use a multicolumn listbox that displays the main parameters of your memory banks. If necessary, use the scrollbar.

Then you could either display more detailed access on the current selection on a second pane or use the double-click event to display a configuration dialog.

Felix

HHMeyer · ‎06-08-2011

I'll look into multicolumn listbox and see, what I can do with them.

Hans

JCC_(SK) · ‎06-10-2011

https://decibel.ni.com/content/docs/DOC-13901

drjdpowell · ‎06-13-2011

My advice would be to first make sure you understand how the Users will be using the power supplies. In particular, do they care about "memory banks" or the fact that there are 60 of them? And are all the dozen parameters equally important?

For example, if I were using a power supply, I might describe my use as: "Go to 300V and hold for 10 seconds, then increase the current to 10A (while always maintaining a safe voltage limit of 1000V) for 1 hour, then turn off." I would not want to have to configure 60 sets of 12 parameters, or even look at a table of 60 lines. I might want to have some parameters that are set globally (like safety limits), and others that change so often that they should be displayed graphically (like a graph of programmed voltage and current versus time).

What I'm saying is that your description of your UI idea is mostly about details of the hardware implementation (memory banks) rather than about the User needs. If your Users are like my Users, they wont care about the exact details of the hardware control.

-- James

HHMeyer · ‎06-15-2011

@drjdpowell wrote:

My advice would be to first make sure you understand how the Users will be using the power supplies. In particular, do they care about "memory banks" or the fact that there are 60 of them?

Our users asking for the possibility to program repetitive sequences is a major reason we implement this.

@drjdpowell wrote:

And are all the dozen parameters equally important?

No, they are not. And that is why think that a pictorial representation of a memory bank (like an icon), with just enough information for the user to distinguish one bank from the others, would suffice. Some of the values in a bank depend on others or are limited by global settings, some of them may not even be accessable to the user. Some of these the user could override with values that are more restrictive than the default values

@drjdpowell wrote:

For example, if I were using a power supply, I might describe my use as: "Go to 300V and hold for 10 seconds, then increase the current to 10A (while always maintaining a safe voltage limit of 1000V) for 1 hour, then turn off." I would not want to have to configure 60 sets of 12 parameters, or even look at a table of 60 lines. I might want to have some parameters that are set globally (like safety limits), and others that change so often that they should be displayed graphically (like a graph of programmed voltage and current versus time).

Quite often our power supplies are used in testing environments where sequences with 20 steps within a few minutes (or even a shorter time) are common. I use a tabbed GUI for the main VI and one of the tabs ist only for the memory banks, another one for the sequences. A user that doesn't want use the banks or the sequences doesn't have to look into them. But for the one who does: I agree that having to look at a table with this a mount of information would be overwhelming and , this is why I came up with the idea of the two-step abstraction in the first place. One interface to configure the banks one by one as needed, another interface to arrange the available banks into sequences while showing only representation of the banks.
As for the monitoring of the power supply I implemented the display of the the current values as numbers and graph, like you suggested.

@drjdpowell wrote:

What I'm saying is that your description of your UI idea is mostly about details of the hardware implementation (memory banks) rather than about the User needs. If your Users are like my Users, they wont care about the exact details of the hardware control.

Our customers who are interested in memory banks and sequences want to use the power supply in combination with the software to control their hardware. A lot of them even write their own software in LabVIEW based on a library we deliver with our power supplies. Our users are not consumers but engineers and they want to know and decide what our stuff does to their stuff.

Hans

drjdpowell · ‎06-15-2011

@HHMeyer wrote:

@drjdpowell wrote:

My advice would be to first make sure you understand how the Users will be using the power supplies. In particular, do they care about "memory banks" or the fact that there are 60 of them?

Our users asking for the possibility to program repetitive sequences is a major reason we implement this.

Hi Hans,

What I was trying to get at is that there are two levels to designing a control program for hardware such as your power supply:

1) a UI to allow the User to specify what they want the power supply to do, and

2) a "driver" that controls the power supply via the hardware-specific control method.

Sequences of power parameters such as Voltage is the connection point between the two levels, but "memory banks" are very much an internal detail of the driver level. Imagine, for a moment, that someone came to you and said that they would like to start also using a new type of power supply that is controlled through a text-scrpiting language instead of memory banks ("V300Wait10000A1...", or whatever); this new supply can do exactly the same sequences as the old supply, but it's control method is different. You wouldn't want to have to totally change your UI for this new supply, just write an alternate driver that can be plugged in. Similarly, if some other programmer wanted to adapt your power supplies into a different UI, it would be much easier for them to be able to use your driver without having to understand what a "memory bank" is.

In your posts, you seem to freely mix terms from the "power-supply-UI" and "specific-power-supply-driver" levels ("sequences" versus "memory banks"). I worry that you may be about to write a "UI for setting memory banks of this specific supply" rather than a "UI for controlling a power supply" and a "driver to control this specific power supply (via memory banks)". It's an easy mistake to make, as I know from painful experience, and it could limit the future flexibility of your software. Though it is possible that your Users are really interested in all the details of this specific supply (it being in-house and all) and thus really do want a UI for setting memory banks. Now is the time to be sure you understand your Users; "I want to program repetitive sequences" is not necessarily the same as "I want to program the memory banks".

-- James

As for the monitoring of the power supply I implemented the display of the the current values as numbers and graph, like you suggested.

A trick I use is to display dashed lines for what the hardware is programmed to do, with solid lines of the same colour showing the actual values as they occur. As the User changes parameter values, the graph automatically updates the dashed lines to give instant visual feedback of what they are telling the hardware to do, while during execution they can easily see at what point the process is at by comparing the solid to the dashed lines.

LabVIEW