The Block Diagram should be the central VI component (not the Front Panel)

[GregSands]

From considering a number of other ideas (see below), I want to suggest that the Block Diagram is the only item initially created when defining a VI, and becomes the place where ALL VI functionality is defined.  The BD is the place where dataflow is specified and the functionality of the VI is determined.  So it makes sense that the con-pane should be linked to the BD rather than the FP -- it defines the data interface between calling VIs to this VI.  Similarly the icon often provides a visual clue to the VI functionality, rather than its FP look.  So both con-pane and icon are natural components of the BD window.

From the BD, it should then be possible to define one, or more, Front Panels which provide user interfaces to the data.  These FPs may contain some or all of the variables in the con-pane (why ever show Error In/Out?), along with some or all of any other controls/indicators used in the block diagram.  In fact, the Probe Window is already almost an additional FP - just allow several data indicators to be grouped on a single window, and you essentially have a Debug Panel.  It would be great to be able to save the Probe window (or several of them) with a VI. 

Yes, there will be problems, not least that I'm sure some existing code assumes that an FP (and only one) exists if a BD exists.  And that every control/indicator must have a FP representation.

Here's a rough mockup (though the Probe points could be "virtual indicators" instead):

Other related ideas:

Be able to link to the connector pane in Block Diagram

Sub VI without Front Panel

Custom Probe Watch Window

We need to uncouple the "edit mode" FP size from the "run mode" FP size

and one trying to address the same concerns, but in a way I don't like:

Add Data layer for VIs... 

[GregSands]

Sorry, the Custom Probe Watch window link should be this: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Custom-Probe-Watch-Window/idi-p/1399814

[BASE10]

Yes Yes Yes. The front-panel centric scheme probably made perfect sense when LV was born, but I think the block diagram is where it's at now. All those front panels floating around getting in the way! At the very least it would be nice to be able to close front panels and keep the block diagrams open.

Not good UI design

[GregSands]

Here's yet another post requesting controls to be hidden at run-time which would be made simpler if the BD was the main component (for programming and wiring), and the FP only showed what was necessary for the end-user.

[GregR]

Did you happen to check out the LabVIEW Web UI Builder before posting this idea? This is an early access release so it is a subset of the language, but it shows an editor that is capable of building subVIs without ever touching the panel. The environment can be configured to start on the diagam and there is a "VI Data" tool window that shows all the pieces of data that are available to the panel, even if they are never created. (In the current build this does not update for subVIs unless you manually switch the subVI to run mode. That is just another piece of incomplete functionality.)

[GregSands]

> Did you happen to check out the LabVIEW Web UI Builder before posting this idea?

No, I've never looked at it or how it works.  But that's interesting if it behaves in a similar way, being a "redesigned" product.  I get the hint from your comment that it may overlap more strongly with LabVIEW in the future - not sure why, but I'd always had the impression that it was something completely separate.

[GregSands]

Here's another related idea which is based on the Web UI Builder design.  I think I still prefer mine 🙂 - for the way I tend to work with LabVIEW anyway.

[ekb1]

This concept is really good and would be helpful for users transitioning from Simulink.

[evan1138]

I'm fairly new to LV and the FP-centric model seems to cause me lots of tedium and physical effort -- yes, 100 extra mousings a day is work! I agree with Base10 that LV's FP-centricity feels like a result of early decisions based on early needs. But the internal implications of today changing LV to be BD centric may be beyond extreme. Even putting together the work statement might take calendar years. Then making the changes and having them not break existing code might never actually happen. This is not even considering re-written and debugged documentation, and maintaining two different mindsets basically forever. Scary.

My main difficulty, however, is just the practical one we all seem to share. I view the BD about 5x-10x time as much as the FP. For starters, I just want to visually suppress the FP w/o having to minimize, which leaves clutter anyway. I may be wrong, but it feels like there would be only incidental obstacles to adding this feature to the editor, mostly concerning the mechanics of opening and closing vi's for edit/save.

This is such a consistently voiced topic -- a simple search turned up the same issue in 2003 (http://forums.ni.com/t5/LabVIEW/Can-I-just-open-block-diagram-only/td-p/89563) -- that I wish there were at least a FAQ devoted to this question so we wouldn't have to continue bringing it up, time after time.

[AristosQueue (NI)]

GregS It looks to me like we should mark this idea as complete in NXG. Please take a look and let me know if there's some key aspect of this idea that NXG didn't implement.

[GregSands]

AristosQueue Yes, NXG does have most of this - I hadn't realised that you could define a GVI completely on the Diagram, and leave controls unplaced on the Panel, including setting the connector pane - that's actually really nice.  The one aspect of this idea not covered in NXG is the ability to define more than one Panel per Diagram, where you might save different Debug or Probe views of the same VI.  But that's a secondary part - I think the main concepts are indeed implemented, so I'd be pleased if this was closed off.  Makes me look forward to using NXG a little more now 🙂