Inheritance Properties Dialog Box

[jgcode]

I have LabVIEW Classes of the same name in two separate LabVIEW Project Libraries (e.g. for namespacing reasons) in the same LabVIEW Project.

When I go to configure the Inheritance of the a Class, the All Class In Project list just shows the Class names.

These names can be the same and it is not immediately obvious which Class is the correct one.

The only way to pick the correct Class is by looking at the Selected Class Path on the right.

Does anyone think it would be helpful to show the full Namespace of the Class in the All Class In Project list?

The flip-side to this is that the name get long and hence messy if the Class is nested in a Sub-Library(ies).

Thoughts?

Class in Library Inheritance Name LV2009.zip

[Daklu]

Yeah, I've noticed that before too.

In general I get a bit annoyed when fully qualified namespaces are used--most notably when I drop objects on a front panel. I almost always go back and delete the namespacing and the .lvclass extension from the object's label. (Maybe it wouldn't be so bad if all the library extensions weren't used...) My main issue with including the fully qualified namespace in the dialog box is that sometimes the names get pretty long and the dense text could be hard to read. However, there are definitely times when I want a better way to select the correct class to inherit from.

Maybe providing an alternate way to view the classes would help. Instead of just listing them alphabeticly have the option to include the libraries and show the classes nested in the correct .lvlib file? Or maybe instead of showing the fully qualified namespace just show enough of the namespace to distinguish between like named classes? (Either way I'd rather keep using the path than have to wait even longer for LV to respond.)

[jgcode]

Glad someone else has noticed...

...include the libraries and show the classes nested in the correct .lvlib file?

I like this way the best - it would match the LabVIEW Project and be most logical IMO.

Either way I'd rather keep using the path than have to wait even longer for LV to respond.

Hopefully this will be faster in 2010. I haven't benchmarked it in the beta tho (am yet to fire up v3).

[Aristos Queue]

It's not a wide dialog, so we decided to just list the unqualified class name there. I take it the path is a less usable solution than you'd prefer... We could also display the qualified name at that point. Would that be helpful? Or would you just prefer that we bite the bullet and allow the horizontal scroll bar? MS Visual Studio has decided to take that approach and show fully qualified name in all dialogs, even if it means horiz scroll. It's a usability trade off, and we could do whichever the community feels is most usable.

[jgcode]

It's not a wide dialog, so we decided to just list the unqualified class name there. I take it the path is a less usable solution than you'd prefer...

I guess only because its not "in your face - obvious" as the eye is drawn to the list.

We could also display the qualified name at that point. Would that be helpful? Or would you just prefer that we bite the bullet and allow the horizontal scroll bar? MS Visual Studio has decided to take that approach and show fully qualified name in all dialogs, even if it means horiz scroll. It's a usability trade off, and we could do whichever the community feels is most usable.

I would obviously prefer a qualified name although I like the idea of it being nested, I think that would be nicer than one long name?

Regardless I have posted this an an Idea

[PaulL]

My thoughts:

I haven't frequently had classes with duplicate names in the same project--although it has happened in some of my projects and probably will happen more often--so on the rare occasion when I have seen this I don't mind just looking at the Path. Nonetheless, I agree it would be easier to see this information in the tree view.

It's worth noting that classes can only have the same name if they are in different namespaces (e.g., they are in different .lvlib files) so maybe the browser could arrange the classes by .lvlib namespace first? (I don't really know if that will work, but I think it might work pretty well.) [Edit: Ah! I see that jg-code already suggested this as part of the posted idea.]

Or perhaps there could be a check box to show or not show the fully qualified namespace in the tree view. (Which do we want? Both! Yeah, that would definitely make AQ's life more difficult.)

Anyway, I haven't encountered the situation much so that's all I've got.

[jgcode]

Or perhaps there could be a check box to show or not show the fully qualified namespace in the tree view. (Which do we want? Both! Yeah, that would definitely make AQ's life more difficult.)

Haha! I was thinking this exact same thing when I posted up the Idea - but I wasn't game enough to write it

Kudos for balls!

[Aristos Queue]

Haha! I was thinking this exact same thing when I posted up the Idea - but I wasn't game enough to write it

Kudos for balls!

Yeah, that's the sort of "option" that ultimately makes things less usable -- most people toggle it once if ever, it clutters the screen, taking real estate away from other elements, and it opens a source of bugs for a rarely tested code path. Every usability guide you'll ever read will condem this sort of option, and if you doubt, you can run the usability studies to confirm it. Data presentation in a dialog should be something you commit do and do, not something you waffle over. Even if a few customers find the result less optimal than another option would have been, the net is still more usable than introduction of the option.

[jgcode]

Yeah, that's the sort of "option" that ultimately makes things less usable -- most people toggle it once if ever, it clutters the screen, taking real estate away from other elements, and it opens a source of bugs for a rarely tested code path. Every usability guide you'll ever read will condem this sort of option, and if you doubt, you can run the usability studies to confirm it. Data presentation in a dialog should be something you commit do and do, not something you waffle over. Even if a few customers find the result less optimal than another option would have been, the net is still more usable than introduction of the option.

Do you have a personal preference over which display method would be ultimately advantageous - or are you happy from a user perspective of the current implementation?

[Aristos Queue]

Do you have a personal preference over which display method would be ultimately advantageous - or are you happy from a user perspective of the current implementation?

Personally? I would prefer the fully qualified name be displayed, as in "X.lvlib:Y.lvclass" and alphabatize the list by the entire string. The dialog is as it is today from feedback from various and sundry when it was created X years ago, where X is receeding further into the depths of memory.

[PaulL]

Personally? I would prefer the fully qualified name be displayed, as in "X.lvlib:Y.lvclass" and alphabatize the list by the entire string.

I think that's fine. I hope classes not in .lvlibs appear before or after, not intermingled, though.

[Daklu]

I second Paul's request.

We could also display the qualified name at that point. Would that be helpful? Or would you just prefer that we bite the bullet and allow the horizontal scroll bar?

If you do go this route, can you please, please, please make the dialog box resizable and have the size persist between calls? And maybe strip out the .lvlib and .lvclass extensions from the diplays? I imagine the extension might be useful if I have a class and library with the same name at the same spot in the namespace, but that happens so rarely (I've done it once) that they're usually just noise.

Yeah, that's the sort of "option" that ultimately makes things less usable...

I agree. Figuring out those things is part of what makes UI design so hard.

Showing the full namespace in the tree view strikes me as redundant, but having a button on the dialog box to switch between a flat alphabetic view with full namespace and a short name tree view would be worthwhile.

[Aristos Queue]

I think that's fine. I hope classes not in .lvlibs appear before or after, not intermingled, though.

Nope... they'd be part of the alphabetization if I had the lone vote. That's actually kind of key -- you'd look it up by its qualified name. Otherwise things get messy -- would you want all the 2 level names before all the three level names?

A.lvclass

B.lvclass

Z.lvclass

X.lvlib:C.lvclass

Y.lvlib:D.lvclass

X.lvlib:A.lvlib:E.lvclass

X.lvlib:Z.lvlib:F.lvclass

Y.lvlib:Z.lvlib:G.lvclass

That's mighty strange. This is the order I'd want them in:

A.lvclass

B.lvclass

X.lvlib:A.lvlib:E.lvclass

X.lvlib:C.lvclass

X.lvlib:Z.lvlib:F.lvclass

Y.lvlib:D.lvclass

Y.lvlib:Z.lvlib:G.lvclass

Z.lvclass

[Daklu]

In your example I actually find the first one easier to read, though it would be harder to find a specific class. The different length lines in the second example make it harder to find the class name, which is what I'm usually looking for. How about this? (I still don't understand why you insist on cluttering up the display with the file extention. Everything in parenthesis must be a library, and everything not in parenthesis must be a class.)

A

B

C (X)

C (Y)

D (Y)

E (X:A)

E (X:B)

F (X:Z)

G (Y:Z)

G

Z

I pulled a Homer with the earlier suggestion of using a tree view to show namespacing. The inheritance dialog box already uses a tree view to show the inheritance hierarchy. (Go figure.) How are you going to have a tree view within a tree view? D'oh!

[Aristos Queue]

Everything in parenthesis must be a library, and everything not in parenthesis must be a class.

At the moment this is true... ideally that would not be true. A class is a library and should be able to contain other classes. There's a technical difficulty we have in LV (dumb design on our part) that keeps that from happening. My hope is that this can be overcome in a couple years when we finish a larger refactoring effort.

I pulled a Homer with the earlier suggestion of using a tree view to show namespacing. The inheritance dialog box already uses a tree view to show the inheritance hierarchy.

Yeah, I didn't comment on that earlier. Tst on the NI forums summed up the problem nicely:

So far, I don't remember placing classes inside .lvlibs, so I can't really comment on this, but I think that if you do it nested it will be confusing, because you're combining the inheritance hierarchy and the ownership hierarchy in the same tree.

[Daklu]

At the moment this is true... ideally that would not be true. A class is a library and should be able to contain other classes. There's a technical difficulty we have in LV (dumb design on our part) that keeps that from happening. My hope is that this can be overcome in a couple years when we finish a larger refactoring effort.

I remember previous discussions about that and I look forward to seeing that happen. In the meantime, can you please strip the extensions from the namespaces on labels and other elements that show namespaces to the users? (Dialog boxes, context help, etc. I don't mind it so much in the project window.) I understand keeping track of the extension internally as you need to distinguish between a class and library with the same name. But really, I know my code well enough to understand which modules are libraries and which are classes.

(Can you share any details about the refactoring effort?)

Yeah, I didn't comment on that earlier.

I hope it wasn't for fear of offending me. I'd much rather have people point out my stupid ideas than let me continue on in ignorance.