Classic Palette under LV 8.0?

[chilly_charly]

LV Pro,

I like very much your image of somebody rearranging all your furniture. My own image was renting a new car every day...

Switching several times a day from 7 to 8 and back is a real pain, and developping the reflex moves that made LV programming so efficient is extremelly slow. I regret to say that a significant part of my pleasure to use LV has been wiped out, and I still not understand why.

I hope NI will not decide now that the wire size and color coding scheme is not "logical".

[Greg_McKaskle2]

I'm jumping in here late, but I feel this could use a bit of airing out.

Reorganizing the palettes wasn't a marketing motivated task. The LV7.1 palettes had something like twenty one top level entries, and when you installed I/O and a few toolkits, you could top thirty. This seemed way too many top level items for the default. So we decided to try some experiments, give them to some internal users, and adopt them if they were well received.

Experiment one was to add the twisties for easier exposure of groups, and to try and have something like seven top level groups. In the end, this number grew, due to feedback from users, but it still allows a quicker way of customizing what you are using without an editor. Not using a group today, twist. Tomorrow if you are using it, but not something else, twist, twist. The popup behavior is a bit tricky since they should be kept smaller, but this navigation extension was experiment one.

Experiment two was to try a functional organization of the blocks. The existing organization had as much to do with the building or floor of the group that wrote the VIs as with what they were used . There were many rounds of input, and this is guaranteed to be a sore point. Many of the more commonly used blocks are buried less deep. Some of the less commonly used blocks are a bit deeper. And hopefully they are in groups that describe what they do. This is a little like rearranging furniture -- in your new house. Or perhaps a better analogy is to look at cars. Everytime you buy a car, they have moved something. The radio used to be these knobby things below the heater, and now it is all buttons, some on the steering wheel, some in a arc to the left of the vent, etc. So "most" people sell their old car and get used to their new one in a matter of a few days. Your case is different. You have kept the last five cars you have owned and drive a different one every few weeks, so these little differences annoy you for more than a few days. But even though your usage is perfectly valid, you aren't anywhere near the center of the bell curve. I predict that you will get used to the new palettes in 8, or perhaps in 8+ as some things get polished and fixed. Then it will be LV6 or LV7 that you can't stand to use. Or maybe not.

I don't know that their is a simple solution. If we had decided to rearrange the palettes, but also keep the old organization, we would still need to modify it for all the new stuff. It would still be different, and it would be buggier as maintaining two or three palettes for every release, every toolkit, every I/O library means way more combinations, too many. So As Christina mentioned, if you want to make some changes to move a few things or reorganize a few things, you can smooth out the worst of the wrinkles, but ultimately, you did upgrade, and that means change. And it is OK to gripe or make suggestions, that hopefully leads to improvements. But it isn't correct to blame marketing for some engineering experiments.

Cheers.

Greg McKaskle

[Jim_Kring]

Hello All,

I just wanted to let you know that OpenG has put the "Fun" back in the LabVIEW 8.0 Functions palette , allowing you to have the good old 7.x feel!

Please see the announcement here, for more info:

http://forums.openg.org/viewtopic.php?p=864#864

Message Edited by Jim Kring on 05-26-2006 01:56 PM

[Odd_Modem]

Putnam needed to vent for a lot of us, me thinks.

[tst]

OK. I just started an evaluation of 8.2 and right off the bat I needed the the data manipulation palette. So I start looking.

Could it be here?        No...

Maybe over there?      Nope...

How about that palette? That could make some sense...       Nada...

Eventually, after about a minute or two I found it in the numeric palette.

Now, I know that a minute isn't a long time for "obscure" functions and I read Greg's explanation about how this new arrangement was more logical and easy to use in the long run and I am willing to accept that, but putting a palette where almost half the functions have nothing to do with numerics into the numeric palette does not inspire confidence in the thought process that went into this.

[daveTW]

Hello tst,
this is funny, because five minutes ago I needed this palette too and thought by myself, that it's good they moved it to the numeric. In 6.1, which I used before I always forgot that it's located in the Advanced-palette, because I didn't find it very advanced to "rotate right with carry". And after a short look I can only find flatten to- & from String and this "request deallocation" has not neccessarily something to do with numerics.
Btw. this "request deallocation" would be more logical in the "Application control"- palette beside "Stop" and "Quit LabView".
Greets, Dave

[tst]

The palette has 12 primitives. 7 accept only numbers and the rest have nothing at all to do with numbers. They are just about data manipulation. Since I normally use the others I really don't see the relation to the numeric palette.

They could have solved it by splitting the palette or by having the numeric primitives in more than one place. For example, the Variant and XML palettes, which were in that palette, were moved elsewhere. Request Deallocation was actually moved to the App Control palette. 

I don't know if splitting would have been a good move, but having it all in the numeric palette is definitely problematic.

[daveTW]

Yeah, I still stick to 8.0, that's why the difference. But I cannot aggree with the number of "nothing at all to do"- functions. For me the "flatten..." & "unflatten..." functions are not stuck to numerics, although theycan be used with them. And the Typecast I use 95% to convert a numeric to an enumerated, to feed it to a case-structure. That's why I think, these functions are mostly used with numerics.
Greets, dave