Build Eye-Catching GUIs (from NIWeek)

[SimonH]

Hey guys, really interesting discussion here and I'd like to see what you guys think about a few things and what we really want for LabVIEW in the future.

I've heard that people want resizable controls similar to the ones I've been creating and posting to the community (and FYI -- I am an NI employee).  Perhaps I'll give this a try for my next round of controls -- LabVIEW supports EMF and WMF which are both vector graphics formats.  I've been using PNG (bitmap) since it's easier for me and in all honesty I rarely resize the heavily customized elements like gauges.

If we packaged some more control options (perhaps the ones from the community, perhaps another vector theme) and made LabVIEW default to system controls and colors instead of the modern controls and darker gray front panel would that help?

I've heard a couple of people say that C# offers more for the UI developer.  I've used C# with both WPF and Windows Forms and agree that you can create some pretty sweet looking UIs.  However I generally find that I can create an equally sweet UI in LabVIEW with the same or less effort (although a lot more effort that I'd typically put into a LabVIEW front panel).  Any nice looking C# app probably has a fair amount of C# code, XAML code, custom imagery and possibly 3rd party controls behind it's pretty exterior - nothing comes for free (at least in the world outside of LabVIEW).

One of the huge benefits of LabVIEW is how quickly anyone can throw together a front panel for use in the lab or on the production floor.  Are these the VIs we need to be making nicer?  Gradients, drop shadows, 3d etc look nice but often come at the expense of readability compared to the more spartan, industrial looking defaults.  I see more of a case for better looking UIs for those of you who are creating applications or systems for other groups or clients to use but I feel that people have more time and desire to customize when their VIs are being distributed further afield.

Is there specific functionality that we are missing in LabVIEW or is it the case that since you are doing everything yourself in C# you might as well make it look nice?  I don't believe it is included controls since LabVIEW actually contains a superset of what either WPF or Windows Forms provides by default. 

• Are you using 3rd party controls? 
  • If so are these free or paid for packages?
  • Have you tried bringing the .NET controls into LabVIEW?
• If you aren't using 3rd party controls I'm assuming you are making your own
  • Is the process easier than in LabVIEW?, if so how?  What could we do to make it easier in LabVIEW?

2 of these are .NET (1 WPF, 1 WindowsForms) and 2 of these are LabVIEW - can you tell me which?  All use only default controls, all are equally scalable.

Beyond these basic controls .NET really relies on you drawing things yourself using GDI or other graphics interfaces.  Is there functionality we could add to the picture control and 3D picture control to make this easier in LabVIEW?

The Microsoft Charts API (and the similar Gauge package available from Dundas) have been sold as visualization tools for creating rich performance dashboards.  Essentially an off-line, infrequently updated way to visualize business metrics.  Even in C# if you put these graphs in a tight loop and throw a ton of DAQ data at them you will reduce your system to a crawl.  How are you currently using the graphs and charts in LabVIEW - in a loop with frequent (>10Hz) updates or after a test/acquisition run?  Would slower rendering but prettier looking be a good alternative for you?  If you spend your time doing a lot of off-line analysis and reporting you might actually be better served by DIAdem than LabVIEW for the "show the data to the boss" type scenarios.

Sorry for the long post but there is clearly some passion here and I want to be sure I help guide our future development in a way that makes sense for the LabVIEW user base.

~SimonH, LabVIEW Product Manager

[Matthew_Kelton]

Simon,

I am one that is strongy supportive of NI updating the controls pallette.  I didn't realize LabVIEW would import WMF and EMF, so I will have to try that at some point.  The resizing can get to be quite tedious, especially when it comes to buttons.  I agree with you that I often don't have to resize something that I modified.  But buttons often get resized in one or more directions.  I had a customer who really liked Vista styled buttons, and wanted that look.  I found a great tool to make these buttons, but I had to do this for every different sized button I had because the shading wouldn't resize properly.

It also becomes diffiult to really have a suite of standard controls if they do not resize.  If I make this pretty guage for one project, and the next project I can reuse it, but I want it to be twice the size, I basically have to redo it again.

I don't expect customizing controls to be child's play, and don't wish to become a graphic deisgner to be able to do some of these things.  And as you mentioned, the prettier you make these GUIs, the more CPU or GPU you use.  I have not done any time trials on it since LabVIEW 6.1, but we had a series of tests we ran using the first PXI controllers.  The video chipset used was subpar and it showed in test time.  I had a 3:15 test that running it over MXI with a slower PC (but better graphics chip) decreased my test time down to 2:45 with no change in code.  I had LabVIEW stop popping up the test windows, basically running silently, and the test time went down to 1:30.  The amount of time spent by LabVIEW to draw the screens was tremendous.  In that GUI, I had layered several decorations behind indicators, so LabVIEW was doing a LOT of redrawing.  So your point about presentaion vs. efficiency is a good one.

I think some of the issues we run into is that a lot of LabVIEW programmers aren't programmers of other languages, so addng in the .NET graph is very complicated (as you mentioned) with all that code.  And while the control ediotr gives us some low level access to change things, there are several times where I have reached an impasse with the ediotr because I cannot add an item, or LabVIEW will not let me change the scrollbar of a plot to another scrollbar.

I would like to see a true, scalable system style suite of controls on the system pallette.  I would also like to see the ability to access the theme colors in Windows (submitted here http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-support-for-Windows-Theme-colors/idi-p/978989#M2143).  The color picker still is limited to a tiny fraction of what is available in the theme colors.  I made a "System" version of the plots (an example at http://decibel.ni.com/content/message/7728#7728), and it does OK until the theme is changed (which one of my customers happened to do).  The "system" buttons I have on the graph buttons don't change.  My border color doesn't change becuase I had to do a screen capture and use a color picker to determine what the color of the border should be.  The Windows colors avaiable are from the Windows95 or 3.1 days I believe, and Microsoft has added so much more since then that we don't have easy access to.

While I agree that front panels can come together quite quickly for lab or test purposes, LabVIEW is used for so much more than that now.  I certainly wouldn't want to lose the ability to quickly slap something together, but I cannot get away with delivering that to my customers.  As I said, filling out the system pallette with the missing controls which have the system feel and properly get updated to theme changes would be a big help.

I have always wondered about theming/skinning inside of LabVIEW.  I have never been a big fan of it (especially in the type of applications I do), but could see benefits in having the users be able to setup their color schemes and have it apply to the whole panel automatcally.  I saw a link several months ago to a presnetation made at NI week where they have revamped the Web Interface and skinning (or something like it) is occurring.  I know you can't comment on it, but I was curious if that was the direction LabVIEW was going to go in general, because it looked very inetresting and promising.

I can tell which windows are in LabVIEW because I can see the icons in the top left corner!  I have no issues with the existing system controls.  I think the plots/graphs are probably the biggest single thing missing from that pallette, but I have also made custom controls for an array container, a cluster container, the color picker, and the timestamp.  At some time, I have had to have these on a front panel.  I have had to use the Microsoft calendar control since one customer didn't like NI's timestamp GUI.  None of my customized controls will port correctly for the non-standard theme.  Some come really close, but becuase I am not tied to the theme color, or I had to use a bitmap of a system button instead of an actual button, things just don't work quite right.

I definitely don't think that the modern set of controls should be the defaults anymore, but I can change that on my own.  I actually need the classic controls still more than the modern controls.  I use simple string and some of the deocrations quite often.

Matthew

[shew82]

Hi Simon,

First of all - thanks for the EMF/WMF tip! that will certainly make life a little easier. After reading your posts, I have a couple of points:

1. Even in industrial and lab uses, *users* (ie not just developers) are expecting more from their software. We're surrounded by rich, high color GUIs that are perfectly clear and easy to use (as long as the effects are not overused), so why shouldn't users expect the same from their test systems that somebody spent either many hours working on or many $$$$?

2. Its true there are some system controls in LabVIEW, and where they exist, they can go a long way to making a LabVIEW application look more like it was developed in 2010 instead of 1995, but it seems to me that the number of available controls doesn't always cut it. Spending a bunch of time with the transparency brush or dropping a .NET container is normally a handy work-around, but the amount of effort it takes to make a .NET control work with LabVIEW makes things like this prohibitive even for regular LabVIEW users. In addition, a lot of the examples of how to work with Windows Forms controls presume somebody has access to the Visual Studio toolchain where a number of the controls properties are available in menu form, as opposed to stringing property nodes together. Is there a reason why NI can do this for ActiveX controls but not .Net?

3. The biggest problems with the picture control (And derived controls such as the Polar Plot) are that (a) it is not anti-aliased, (b) once you put data into it, (b) its slow as hell, and (c) you cant get the data back out unless you wrap the data and picture control together in an xcontrol.

[minnellac]

I'd be worried about the cross platform aspects of using WMF or EMF images in your controls, but then again, if you aren't on Windows they won't look right anyway. Changes to the defaults may be in order. Many developers don't even know about the system controls, and don't bother to change colors when developing a front panel. I know that we have managers here that don't realize LabVIEW can be used to make a "Windows-standard" looking GUI, and that does effect their selection of development platform.

I have used ZedGraph (free/open source .NET) to make better looking graphs in LabVIEW (particularly bar graphs). I also tortured myself making an xcontrol that could display plots with transparent fills. Both links contain example code.

I typically don't update any graph more than 10 times/sec. It's not just the 3rd party controls that blow up with that. More often than not I display high sample rate data 1/sec. One thing that is definitely an advantage to LabVIEW is the ease with which a user can manipulate the graph during runtime. I have seen very few graph controls packages that let you change scales or other plot attributes as easily. This is ideal for the engineering user who wants to examine data, but less important for the business user who just wants to see a static plot/chart.

as an aside, why can't I control anti-aliasing programmatically?

Interesting discussion.

Chris

[CrystalTech]

Thank you Simon,

This is the first serious indication of interest I've seen from an NI representative since I've been bringing this issue up (for many years).  I will only speak for myself here.  I'm not critical if NI gives us the appropriate tools to easily (relatively) create our own control designs, or if you give us several pallettes thate are pre-made "and resizeable".  Like LabVIEW code, I'd expect NI to give me something I can come up to speed on without having to learn other applications and graphics to get what I need for the LabVIEW Front Panel.  I don't think "over the top" designs are necessary as long as they are clean for data and have a modern edge to them.  Note: sometimes I prefer the original controls because they have cleaner lines.  I posted some ideas last year [84 Kudos] which also listed some controls that need to be added to the list (I made these controls using Adobe Flash, with vector graphics).  Other users have also given very good suggestions.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Update-Front-Panel/idi-p/1020307

Again, I thank you, and the users that replied.  I hope this gets the ball rolling.

[Thoric]

Simon H,

Firstly, thanks for the tip on WMF and EMF support, this could make a big difference to my development of custom controls.

The System controls selection is far smaller than the plethora of standard LabVIEW controls and it's not in NI's interests to effectively divert new users' attention from these. Instead of making the System controls the new default, perhaps instead distribute the System controls amongst the standard ones so people can immediately see, and hence consider, them when perusing their options.

You are right, it does take some coding in C# to produce the nice slick GUIs that we see, it's never going to be simple to produce  flashy user interfaces. But to me it always seems many more options are accessible, including simple things such as the Marquee progress bar. Currently, I have to embed this into a Windows Form in a NET container (and hope it doesn't crash out).

One downside of continually resorting to .NET in LabVIEW sees to be the panel update rate. There appears to be an unavoidable lag between updating a .NET control property and seeing the affects on the front panel. Take the Microsoft Chart Controls (here). When ran, one can see how long it takes to set up the chart. In C# this all happens in a blink. This makes it difficult to justify including so much .NET when there is a constant worry that that system will reduce to a crawl. If more of these .NET features were natively available in LabVIEW, I could avoid using .NET in this way.

Certainly, throwing a front panel together quickly and knocking up some sample code to operate it is a huge advantage when bidding for business, and showing off the "Power of LabVIEW". But, as Matthew said, this ultimately would never do for a customer. The benefits of fast panel creation are primarily useful for basic testing, and users in labs who need something quickly and don't especially care for the look and feel. I work frequently in a University for students who have tremendously poor looking front panels and block diagrams, but couldn't care less so long as their code acquires the data and controls the machinery as they need it to. Clearly the ability to knock something up quickly is a critical (and winning) selling point.

You make a fine point in showing four similar panels (and yes, the LabVIEW logo is visible in two of them), but these standard controls are not the full picture. Quite often I need much more than this, including customised controls, especially with applications that are destined for tricky customers. The ability to override a system's default drawing behaviour is easy in C#, but typically not possible in LabVIEW. For example, I couldn't easily create a table within which the third column was a progress bar. Not without going through the pains of a complex XControl design with system control mimicry.

In summary, the existing approach NI has to targetting LabVIEW is solid, and ought not change. For software engineers who need to take their front panels that little bit further, like myself, it all too often seems lacking in the fluidity and ease with which everything else can be achieved. The addition of more resizeable controls would alone make complex interface development easier, and could presumably be created at anytime by NI and made available for download and install to appear in the Controls palette. That would be sufficient to satisfy me (for now ).

[rex1030]

Here is my wish list:

1. All the controls and indicators being vector based scalable graphics. Of course labview should default to this!

2. The control/indicator editor being overhauled to work more like a graphics program for editing the controls to make using these new controls and designing sexy sharp front panels "labview-easy". This includes all new chart and table options that would allow us to make these look how we want. It should support the importing of multiple graphics types and should be able to vectorize non-vector graphics types. Go into popular programming environments and see the options they give for editing the UI (*cough-.NET-cough*) use that as inspiration for the options to give. Editing controls needs to have so many more options available.

3. Controls and Indicators should be based on a style sheet template system (skins). The appearance and functionality of controls and indicators should be totally seperate. We should be able to apply style templates to existing VIs and change the look of the VI at whim like you can on the web with css style sheets.

4. Improvements to the UI should be an ongoing thing from now on with updates in every future version of Labview. UI Graphics isn't something NI can set and forget like they have for the past decade. This means that an expandable, forward-compatible foundation for front panel graphics needs to be adopted and the clunky old vi versions would have to be 'converted' to be used in future versions. LabView is a graphics oriented programming language! They should be pushing the envelope of UI development, not reluctant to catch up to everything else.

All of these changes should have been made 5 years ago. Improving the integration of .net stuff might be nice but that doesn't do those of us that have never used .net much good. This stuff needs to be intuitive and labview easy, with the option to get as advanced with UI development as we want without bending over backwards. You are right that one of labview's strengths is how fast you can make and modify a front panel, that shouldn't change with these options being implemented. It should be easier to get a good looking front panel quickly.

Also I agree with everything Matthew Kelton and everyone else has said. I was just trying to keep my post two those 4 basic goals. Somehow I picture you and two other guys at NI pushing for this and your managers rolling their eyes. Please tell us thats not true. Feel free to push NI to slap bandaids on the problem, like downloadable vector graphic packages, for the year or more it would take to implement and release these changes

[SimonH]

Thank you all for the insightful posts -- we certainly appreciate the detailed feedback.

Obviously I can't comment on future product direction. I can tell you that you we are listening and your input is helpful as we continue expanding the capabilities and functionality of LabVIEW.

[Matthew_Kelton]

If it weren't required for LabVIEW to create the custom controls, I could easily live without having a graphics editor in LabVIEW.  With free graphics editors online such a Paint .NET and GIMP, and so many other options, I would rather NI spent more time on other features than trying to design a graphics editor for the control editor.  So if we could use a graphics standard and imprt mulitple items/layers and have it scale properly, I could live with havign to open another program to create some things (I've been doing it for years already).  But I could see the issue coming up, especially with gradient fills and highlighting (the big issues that caused my Vista-style buttons I references above to not scale properly), where it may have to be done in LabVIEW.

I had forgotten about my annoyance with tables and listboxes and how limited modifying them can be.  Although I cannot recall specific tasks I was trying to perform, I know on multiple occasions I have been unable to accomlish the change I was trying to make.

I actually ran across an annoyance yesterday.  I was creating a custom button control.  I wanted mouse-over highlights, so I had to start with the system control.  Well, the two colors of my images were different enough, I wanted the text color to change between ON and OFF states.  Not a big deal for the modern or classic controls, but I could not get it to happen with the system control.  It wanted that color to stay the same, no matter what.  And of course, since the system button is the only boolean I know of which supports the mouse over highlight, I was stuck deciding which feature I wanted more.  Fortunately, the button was going to be used as an idicator and it was very simple for me to change the color of the caption when I set the value of the button.  But, it should not have come to that.

[Steve Sexton]

Something like the icon editor but for controls would be nice. 

Several themed sets done by professional graphic artists woud nice also since most programmers - engineers aren't artistic.