What are some of your favorite practices in GUI design?

[Hooovahh]

Radio buttons are like enums and tabs. You can't add or remove items at runtime.

[johnsold]

You cannot add or remove but you can disable and gray out the buttons.

Lynn

[dacad]

Funny,  Tab Controls have become a main staple for me in laying out my UI.  For my purpose, I find them easy to use and a time saver.  Also makes the change between pages seamless for the user.  I have actually added tabs three layers deep and it works great for what I am doing.

The benefit here is that to change the view, I change only a single control value as opposed to addressing lots of property nodes.  Since the value is menu driven, the user has no idea there are tabs there.

Another great little UI tool I found on this forum is a vi that lets you click on an element in an array display and it selects that item to let you use it with whatever action comes next.

[paul_cardinale]

Use as many colors as possible, especially bright, clashing colors (and make sure they're not coordinated).

Use as many fonts as possible (and make them extra tiny).

Use words instead of glyphs, and use a language different from the native language of the end users (of better yet, use symbols that are puns in a different language, or that don't make any sense at all).

Put as many controls and indicators as you can on the front panel (this is easier to do if you don't use any tab controls).

If you do use tab controls, put the tabs on the left or right so the words are sideways (and use confusing wording).  Do not use a tab control like the one attached.

Scatter the controls randomly over the front panel.  Overlap them so they're hard to use.

Make your boolean indicators look like buttons.  Make your pushbuttons look like LEDs.

Make the front panel bigger than the screen.

[PaulG.]

---

@mikeporter wrote:

There is absolutely nothing irrational about disliking tab controls. I, for example, consider them to be a Great Evil on the order of Vogon poetry and "Very Brady" Christmas specials.

...

So to sum up:

Tab Controls -- Bad
Subpanels -- Good

Mike...

---

Are you trying to start a Holy War? 

I use tabs quite often. I have no trouble keeping my code organized. Maybe the problem is your heretical beliefs. 

[dacad]

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.

[Hooovahh]

---

@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.

---

Here is the thread.

https://forums.ni.com/t5/LabVIEW/What-is-your-tolerance-for-placing-things-into-clusters/td-p/287199...

[BowenM]

---

@paul_cardinale wrote:

Use as many colors as possible, especially bright, clashing colors (and make sure they're not coordinated).

Use as many fonts as possible (and make them extra tiny).

Use words instead of glyphs, and use a language different from the native language of the end users (of better yet, use symbols that are puns in a different language, or that don't make any sense at all).

Put as many controls and indicators as you can on the front panel (this is easier to do if you don't use any tab controls).

If you do use tab controls, put the tabs on the left or right so the words are sideways (and use confusing wording).  Do not use a tab control like the one attached.

Scatter the controls randomly over the front panel.  Overlap them so they're hard to use.

Make your boolean indicators look like buttons.  Make your pushbuttons look like LEDs.

Make the front panel bigger than the screen.

---

All of those are fantastic ideas. In fact, I think I'm going to do them all at once to really make my interface shine!

[Hooovahh]

---

BowenM wrote: 

All of those are fantastic ideas. In fact, I think I'm going to do them all at once to really make my interface shine!

---

Oh is that what we are doing no.  Saying things we hate in a UIs.  How about when controls get disabled, but not greyed out.  So you have no visual way of knowing that a control that you normally can use, no longer works.

How about mixing Silver, System, Modern, and Classic controls.

How about not handling window resize and just using Scale All Objects on FP.  Which usually ends up with controls over lapping and moving around.

How about allowing the user to close, but not handling the close panel event, so operations never clean up or stop running.

Leaving the toolbar in a built EXE so users can run continuously, or abort.

Making all VIs modal.

[P@Anand]

---

@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.