Feedback on OpenG MD5 Library 4.1.0.8 Release

[Jim Kring]

I know it's only been about 5 minutes since the OpenG MD5 Library version 4.1.0.8 was released, but I was so excited that I had to try it out and wanted to make a couple suggestions to continue this wave of improvement

Place Hexadecimal MD5 instance by default

When the MD5 Message Digest is dropped from the palette, the Binary MD5 instance is placed, since this is the top-most instance of the Poly VI. I'm not sure if this is by design. I expected that Hexadecimal MD5 is more commonly used and that this should be the default instance when dropped.

Use Instance VI Icons to distinguish instances

There is currently no difference between the Hexadecimal MD5 and Binary MD5 instance VIs. One can only tell the difference if the Polymorphic VI Selector is visible and many people like to hide that, since it takes up a lot of space. If the Use Instance VI Icons option were enabled and the two instances' icons were different (to reflect the output MD5 encoding), then it would be really helpful.

[jgcode]

Thanks for the feedback Jim.

Place Hexadecimal MD5 instance by default

When the MD5 Message Digest is dropped from the palette, the Binary MD5 instance is placed, since this is the top-most instance of the Poly VI. I'm not sure if this is by design. I expected that Hexadecimal MD5 is more commonly used and that this should be the default instance when dropped.

This was a design decision based on backward compatibility. In polymorhizing the API, anyone's code calling the original MD5 Message Digest (Binary) will not be broken, as it will default to the top of the polymorphic list (Binary) given the connector pane of the two VIs (Binary and Hexadecimal) matches (which is normally not the case).

Its was very important to maintain this with this change (although I agree Hexidecimal will be more popular).

Use Instance VI Icons to distinguish instances

There is currently no difference between the Hexadecimal MD5 and Binary MD5 instance VIs. One can only tell the difference if the Polymorphic VI Selector is visible and many people like to hide that, since it takes up a lot of space. If the Use Instance VI Icons option were enabled and the two instances' icons were different (to reflect the output MD5 encoding), then it would be really helpful.

This was requested in the review that the icons be of polymorphic instance.

Other API's use the selector by default e.g. DAQmx.

You should have chimed in at the review

But if it is causing an issue, it can definitely be changed.

[asbo]

Thanks for the feedback Jim.

This was a design decision based on backward compatibility. In polymorhizing the API, anyone's code calling the original MD5 Message Digest (Binary) will not be broken, as it will default to the top of the polymorphic list (Binary) given the connector pane of the two VIs (Binary and Hexadecimal) matches (which is normally not the case).

Its was very important to maintain this with this change (although I agree Hexidecimal will be more popular).

This was requested in the review that the icons be of polymorphic instance.

Other API's use the selector by default e.g. DAQmx.

You should have chimed in at the review

Oops, I missed Ton's message too. I'm with Jim on this one, there's a lot of icon real estate that's unused, so I think it makes sense to use the polymorphic instance icons. I don't think it will "cause issues" per se, but it's painless and if it will save some organization grief down the road, why not? WRT DAQmx, typically the icons are already pretty busy, and it would be difficult to convey the multitude of choices adequately in the icon (DAQmx Read, for example). Just my two cents.

[jgcode]

Oops, I missed Ton's message too. I'm with Jim on this one, there's a lot of icon real estate that's unused, so I think it makes sense to use the polymorphic instance icons. I don't think it will "cause issues" per se, but it's painless and if it will save some organization grief down the road, why not? WRT DAQmx, typically the icons are already pretty busy, and it would be difficult to convey the multitude of choices adequately in the icon (DAQmx Read, for example). Just my two cents.

I gots no dramas with it given:

1. It's not a functional change
   
2. If is the more popular way to go etc...
   
3. That building and releasing packages is so painless in VIPM 2011 I am happy to do it now.
   
4. That is what the fix version number was made for
   

So I just need the following two questions answered:

1. Are you happy with the current VI icons (they are do exist in the released package they are just not shown)?
   
2. Do you want the poly selector on by default still (personally, I don't see the point anymore if we do the above)?
   

[Jim Kring]

1. Are you happy with the current VI icons (they are do exist in the released package they are just not shown)?

I'm not in love with the current icon, but there really isn't any sexy way of saying "MD5 DIGEST"

2. Do you want the poly selector on by default still (personally, I don't see the point anymore if we do the above)?

Yes, I think we should keep the Poly Selector, because the poly instances change between string encoding, not data type. This means:

1) You can't change between implementations by wiring up different input data types.

2) there's really no other good way (besides the Poly Selector) to convey to users that it's a poly VI with other implementations and let them choose between the different implementations.

[jgcode]

I'm not in love with the current icon, but there really isn't any sexy way of saying "MD5 DIGEST"

Should we call in vugie?

[Jim Kring]

Should we call in vugie?

I don't see anything wrong with having well-designed icons for OpenG VIs, as long as they all look consistent -- right now I think that the font of "MD5" doesn't really fit with the icon designs of other OpenG VIs.

[jgcode]

I don't see anything wrong with having well-designed icons for OpenG VIs, as long as they all look consistent -- right now I think that the font of "MD5" doesn't really fit with the icon designs of other OpenG VIs.

FWIW, I didn't change that one - it has been there before my time

I just added the Binary and Hex down the bottom.

We can update them in a future release if anyone wants to contribute sexier ones

I was also thinking that if we move to .lvlibs (?) in the future, we could utilise the banner feature in certain situations (Modules/APIs etc...)

[Jim Kring]

FWIW, I didn't change that one - it has been there before my time

Ya, I wasn't blaming you

[jgcode]

The Message Digest Polymorphic VI should show instance icons item can be tracked here: ID 3421698