LabVIEW
What are some of your favorite practices in GUI design?
@BowenM wrote:
On a serious note, what is the solution to this? I started writing a VI that would try to keep aspect ratios and things, but just gave up. I now just lock the size and don't allow users to resize or maximize at all.
I usually spend more time on this then I should. There is no single solution to make this work better but tools like splitters help a lot. If you can have a single control in a pane having it fit to the pane size works well. This is useful for things like graphs, tables and trees. Things that generally you want to grow with the UI. Be sure and have them resize with the window resizing not just when a resize is complete, it is a setting that can't be set programatically but adds to user experience.
Back to subpanels too. Set a subpanel fit to the pane, and then you just worry about how the subVI reacts and not the rest of the UI surrounding it.
Splitter sizing, and origin can only take you so far, and in some cases custom code does need to be written to say how controls should behave. In this case I usually have a subVI that handles what to do, given a pane size as the input, along with any references to controls that it should modify.
EDIT: One of my most complicated UIs has 14 panes, and 13 splitters. It took me almost a full day to get resizing right. At the end of the day I was mad for spending so much time on such a small feature to work right. The next week without me knowing it, some co-workers loaded up my software on two new machines both with different monitor resolutions then I developed. After that I was thrilled I spent the time getting it to work right.
P@Anand wrote:
@dacad wrote:
Hey BowenM, could you provide a link or smething to the vloop vs cluster thread you mentioned. I am going through the basic tutorial on vloop and would like to read this as so far, I am asking myself the same question, why one over the other. Maybe when I get further along in the tutorial it will become clear but reading more is never a bad thing.
Its LVOOP (means Object Oriented Programming in LabVIEW).
My Practice:
- Keep you FP size to an optimum resolution so that you can always take your code to any PC with different resolution
- If you have many boolean controls try to make them the same size and also try to use the same font as much as you can, this will give your GUI a professional look.
- Try to make the String/numeric controls and Indicators flat and also the Graphs/Charts flat so that your total GUI looks like a drawing.
- As suggested try to avoid Tab controls and use sub panels (Sorry PaulG)
- Give Tip strip to the controls and indicator so that the user knows the function of the control/Indicator easily
Remember you are going to give the software to your customer and you are not the one going to use, so make it readable for them.
Comments are welcome.
Seriously i havent followed any of the above in any of my projects.
For me the style rules are:
- Less is more. If you haven't used a control in a while, you probably don't need it there. You might put it in the configuration cluster or even hard code it
- Tip strips are not necessary. If you need a tip strip to explain something, the name, the location of that control or even the whole control needs some serious rethinking.
- Tabs are great
- Use only System controls
- Put between all panels, window borders, buttons and other indicators a distance of one "Shift + Arrow Button". Compact GUI are preferable
- Color all fonts and text fields to the System color (often black, but changing the font color of Windows allows the true personalization in combination with System controls)
- Sliders and knobs look cool, but a normal indicator does already the trick, avoid those things
- Avoid colors and blinking, too much distraction
- Remove the menu bar, Run & Stop button (real quiting is done in the program). The Dialog appearance minus the Modal option is in general the best way to go.
- No scroll bars
- Control and indicator names are in lower case
- Key navigation for buttons (by Enter button) should not be used
P@Anand wrote:
@muks wrote:
Seriously i havent followed any of the above in any of my projects.
May be that is your style
. I worked with the operators who just know where to click by seeing the instruction manual.
or maybe most of our customers will want the GUI in their preferred format and will sit with us till we make it that way...
@Harlequinade wrote:
For me the style rules are:
- Less is more. If you haven't used a control in a while, you probably don't need it there. You might put it in the configuration cluster or even hard code it
- Tip strips are not necessary. If you need a tip strip to explain something, the name, the location of that control or even the whole control needs some serious rethinking.
- Put between all panels, window borders, buttons and other indicators a distance of one "Shift + Arrow Button". Compact GUI are preferable
- Color all fonts and text fields to the System color (often black, but changing the font color of Windows allows the true personalization in combination with System controls)
- Sliders and knobs look cool, but a normal indicator does already the trick, avoid those things
- Avoid colors and blinking, too much distraction
- Remove the menu bar, Run & Stop button (real quiting is done in the program). The Dialog appearance minus the Modal option is in general the best way to go.
- No scroll bars
I agree with these, for the most part. Tip strips are something that I don't do much simply because the GUI should speak for itself. If I get feedback about somebody not understanding what a button does, then I'll concider it. But my boolean text and/or labels are usually desciptive enough that anybody can tell what it is.
@Harlequinade wrote:
For me the style rules are:
- Key navigation for buttons (by Enter button) should not be used
I am kind of torn with key navigation. I have a lot of users who want to abort an operation using either an abort button (NOT the one in the toolbar, they don't see him) or the ESC key. Key navigation is good for that, but I don't like it because I have seen too many people just bump their keyboard in the wrong place. So then I have to have a dialog for "are you sure?"
But here is my exception: my own dialog windows. I also use the tab order for these. There are very few controls and it it obvious where a tab will take you. And people expect Enter to cause the OK and ESC to Cancel. We've been programed that way by Windows.
Obviously to each his own but heres my take on a few things we are talking about.
Useing key navigation is fine as long as you are consistent. I have ESC close any window in my application, stop any running test, and even exits the software if no test is running. We have keyboards in a drawer, or hanging off of the monitor on an arm and I have yet to hear of someone accidentally hitting ESC. Also I have a wizard setup and Enter moves to the next page. Enter also closes any dialogs in a similar way to Windows dialogs.
I've mentioned this before but I'm fine with tabs. The large UI I mentioned with 14 panes, and 13 splitters also has 7 or so tabs. 6 of which don't have their tabs shown and I programatically control them.
I almost never use tip strips but I understand their use and I should probably use them more.
I think "Only use System Controls" is a bit too much. I would rather say keep a common look throughout the application. System controls help with this but there isn't a system control equivalent for every control and you have to make compromises some times.
"No Scrollbars" is also an absolute that you shouldn't live by. Use them when appropriate. I have a list of things to show, and that list maybe more then the screen can hold. Should you not have scrollbars on tables either? Or X axis on graphs?
And why should control and indicators be lower case? What other application conforms to this style? Open Word, or Excel, or Photoshop, or VLC, they all conform to capitalizing the first letter.
