free label format

[theanalogkid]

How often do you find the need to orginize data into a table format while documenting your vi?  I for one, could & would use it all the time!  Creating a resizable table free label we all use in word & excel seems like a simple task and would aid in organizing and documenting data into a more readable format.  A ctrl+double-click or shift+double-click could serve as an easy access method, tab through the contents, and resize rows and colulmns vis a cursor change while hovering at the specific borders.  Free Label, New type, table format, organize data, rows, columns. 

[AristosQueue (NI)]

theanalogkid:

You start with this first idea. Then someone suggests we should also have alignement controls. And bullet point lists. And mathematical notation like super and subscripts. And... and... and... and eventually perhaps we should build a whole word processor into the comment node? Every one of those requests requires a UI to enable them and edit them.

Speaking solely for myself, I do not believe that is a good expenditure of LV R&D time. We are not experts in buidling a wiki-editor or a Microsoft Word.  If the comments on the block diagram are insufficient, add a URL that links to a more complete document, which you can write with a tool made for producing such documents.

Note that I do not speak for all of R&D... this idea might be carried forward, especially if it gains kudos among other users. For myself, I think it would starve LabVIEW of far more important and useful features to even start down this road.

No kudos from me, but we'll see what others have to say.

[theanalogkid]

Based on the negative tone of your response, perhaps readers of your comment will think twice before wasting time sharing any ideas?  The suggestion was not to include all the crazy features, just a slightly smarter free label.  But thanks for trying to make it into something it's not.

[AristosQueue (NI)]

Part of my job is explaining where the downsides are on ideas that initially seem good, or even those ideas that would be great with an infinite budget of time and effort. Posting the downsides of an idea does not mean the idea will not happen. Knowledge of the downsides is critical to deciding what makes the idea worth doing. This is a forum where R&D and users can negotiate back and forth to find a good balance for features. If I only say, "Yeah, that would be great, let's do it!" and then it just doesn't happen inside R&D because of all the unstated downsides, that doesn't do anyone any good.

I'm not really concerned about discouraging ideas on the Idea Exchange. There are plenty of ideas where I've said, "That's a great idea." And there are always more ideas coming in than we can ever edit.

I do not believe that I oversold your idea. Even just the table format that you're requesting is a substantial investment in UI design, requiring a whole bunch of editor gestures to be developed. LabVIEW is frequently criticized for building only half of a feature, so when we add a feature these days, I believe that we have to implement it with gusto, such that people do not casually hit the limits of the feature. So, for example, if we were going to implement your table, we would need gestures for setting the alignment both on a table-wide basis and on a row-by-row and on a cell-by-cell basis. There is a lot of complexity that goes into building the UI for a table... I've used too many web sites that have poor table editing interfaces. If the LV interface for building a table isn't robust, no one will use that interface, and then we've wasted time building a feature no one uses. That's no good for NI and no good for our users.

Your idea falls into a category of ideas that I believe are simply bad ideas for NI to even start working on. These include:

• Build a full HTML-string-parser control for the front panel
• Build the Icon Editor up to where it is a rich graphics editing application

Both of these have smaller features that are regularly requested. "I just want a string control to recognize the <b> tag and automatically format the text as bold." Not an unreasonable request on its face, but look at the Description & Tip feature of LV ... our help window there supports the <b> tag... and only the <b> tag. We frequently get frustrated users who want italics, underlining, etc. The same would occur immediately with a string control. Similar slope exists with the Icon Editor.

Obviously we have to have *some* amount of function in these areas. The trick is balancing the minimal functionality to be useful against the maximal functionality at which point it becomes a distraction to the main thrust of LabVIEW itself.

I firmly believe that we should not even start down the road of augmenting the comment blocks for formatting. Each of the small requests is fine by itself, but it creates an expectation of robust formatting that I do not believe is a good thing for R&D to spend substantial time on. I do not believe that the frequency of use of these features will justify the amount of effort put into developing and maintaining them. Others within R&D may disagree. I supported making URLs in the comments be clickable links specifically so that you could link off to more complex documentation.

So, yes, I am negative on this idea. Convince me otherwise. Would you prefer to have this feature over most other features on the Idea Exchange? Do you believe that this will be used by the vast majority of users on a regular basis? Do you think the absence of this feature is seriously limiting the ability to document VIs? Can you suggest a UI for table editing that is both pleasant to use and not a significant amount of code to develop?

[GregSands]

I'd settle for the free label accepting a "Tab" character with a simple left-alignment.  That would seem to satisfy the core request here without any expectation of heavy-duty formatting.

Marginally more work would be to size each column based on the maximum text length (+ a space) in that tab.  OK, that's a little more work as you need to know something about the font used.

For anything more complicated, I would tend to paste an image, though that's not easily editable (no click-thru to open the original program for example).