Unbundle by Name: Optionally Dim Items Already Unbundled

[Mr._Jim]

Since it was introduced, I have zealously adopted the "In Place Element Structure."  In addition to its warm-fuzziness to those with memory usage paranoia, I am a huge fan of the manner in which the "Unbundle / Bundle Elements" terminals assist in keeping track of which elements have already been used by dimming them.  Granted, it's intrinsically necessary due to the way the structure functions, but I also think it's generally helpful.

I think it would be great if this dimming functionality was available on the plain old "Unbundle by Name" function.  Since you wouldn't want that functionality all the time, I suggest that it might be an option selectable from the context menu.  (Right click on the function and select "Dim Items Already in Use" or some such option)

While I'm at it, I might as well suggest the same for the "Bundle by Name" function as well.

[RavensFan]

Nice idea.  But I think it may complicate wiring things.  If you drag down on the block, you get more of the elements in order.  But supposed you want your next one to be an item that was already automatically filled in at a lower position.  You can't because it would be greyed out.  Likewise if you want to swap positions of elements in the list.  You can pick one and select the other item you want because the item is already picked in a different position.

[Mr._Jim]

Hmm...  Ravens Fan, I understand your reservations about it, but I respectfully disagree, and for what I believe are good reasons:

Sure, it does "complicate" things in most cases, but in certain instances it makes things overwhelmingly easier.  (Besides, I'm suggesting that it's an option that's off by default) Here's an example of how I just could have used what I'm suggesting:

I'm writing some code that assigns a cluster containing a bunch of digital outputs with long names to a Boolean array that's written to hardware.  Because this is an R&D application, someone else periodically changes the ordering of the physical wiring.  Consequently, I need to carefully keep track of what I've already assigned when I unbundle.  In this case it's a real pain when I have to scan through the whole list to find what I'm looking for every single time.  On the in place element structure, I can do this unbundling job in half the time because each time I use an element it's dimmed, and my eyes only have to scan through a waning fraction of the list each time.

Does this make sense?  If I thought this was some obscure thing that only I would use I'd refrain from suggesting it.

For all the nitpickers out there, the coercion dots are due to strict Boolean type definitions.

[JackDunaway]

>> Because this is an R&D application, someone else periodically changes the ordering of the physical wiring.  Consequently, I need to carefully keep track of what I've already assigned when I unbundle.

This is ancillary to the Idea, but that example might be a good candidate for an additional abstraction layer, where IO routing is managed based on a configuration file, not the "physical" block diagram (or a name-value collection rather than discrete indexing). Another thing that may help is using "Short Names" rather than "Long Names" on the Unbundle by Names.

I agree with Ravens that this introduces the same IDE usability issue that the IPE structure exhibits. Rearranging Bundle/Unbundles on an IPE is difficult because you must collapse a member if you want to bring it up somewhere else. The structure would be more usable to allow duplicate member accessors with the penalty of a broken run arrow, rather than the IDE prohibiting duplicate member accessors on a structure.

... later ... 

I would not object to a visual indication the element has been used (italics, for instance), but I am against disabling-and-graying the selection.

... later ...

Come to think of it, I like a simple visual indication. This Idea should be applied to both normal Bundle/Unbundle by Name and the IPE structure - they meet in the middle by visually indicating which elements have been used, but the IDE does not disallow the selection of duplicate members.

[AristosQueue (NI)]

Instead of italics, would a glyph of some sort next to the already-used items be ok? I think a glyph might be something that could more obviously tell a new user what it means, as opposed to italics that doesn't instantlly convey to my eyes why the menu item is italicized.  Thoughts?

[Mr._Jim]

Brilliant.  Sometimes the obvious isn't obvious!  A visual indication would be a perfect fit, eschewing the annoyances of rearranging clusters in the IPE.  I agree that glyphs are better, too.  We could keep it simple with a check/tick mark, or we could use the addition of an exclamation mark when items are used twice or more.  Would that overcomplicate things?

>>This is ancillary to the Idea, but that example might be a good candidate for an additional abstraction layer, where IO routing is managed based on a configuration file, not the "physical" block diagram (or a name-value collection rather than discrete indexing).

It's funny that you should mention that, because I'm working on an IO editor.  Yeah, I should probably use the short names more often.  (But we digress)

I love how ideas get refined in this forum.  Thanks for helping me think through this further...

[JackDunaway]

>> I think a glyph might be something that could more obviously tell a new user what it means, as opposed to italics that doesn't instantlly convey to my eyes why the menu item is italicized.  Thoughts?

Support for glyphs for context menus in general would be great.

My vote between font style vs. glyph is going to favor the indicator that has the better long-term usability, rather than fostering a new user's intuition. If an informationally-dense glyph is intuitive yet a little distracting, maybe italics font would be better. If the glyph is intuitive yet subtle, I might favor the glyph. There's a balance, but I prefer the scales tip toward long-term usability.

[Mr._Jim]

Glyphs, italics, other font tricks... I'm happy so long as the functionality is there.

[AristosQueue (NI)]

> If the glyph is intuitive yet subtle, I might favor the glyph.

I was thinking an animated emoticons showing a happy face clicking on a Bundle node. Would that be over the top?

(Just kidding.)

[Mr._Jim]

Oh, man that is so cool.  Animation is definitely crucial to the visual awesomeness.

Wait... it's smiling, but is its thumb pointing down?!  That's not intuitive.

[dthor]

I'm for this idea, as long as the greyed out (or glyphed or itallics) lines are still able to be used a 2nd, 3rd, or nth time. Sometime it makes for a cleaner diagram if you have two of the same nodes on an Unbundle by Name.