Don't Disable Enum Properties Move Up/Down Buttons

[d.w.b]

On the Enum Properties dialog, Edit Items tab, there are Insert, Delete, Move Up, Move Down, and Disable Items buttons. Multiple Items may be selected, but the Move Up and Move Down buttons are disabled unnecessarily. They should be enabled. There is no reason multiple items shouldn't be able to be moved up or down.

[AristosQueue (NI)]

I'm pretty sure they're disabled because they're ambiguous. I've seen the up/down buttons disabled elsewhere, both in NI software and other company's software. If your list is

A

B *

C

D *

where the asterisks indicate "selected", when you click "Move Up", what is the result? Is it:

B        B

D   or   A

A        D

C        C

? The first one is what you would get in a drag operation if you had multiple select and you dragged them all to a position in the list (and we treat "A" destination as the target for everything). The second one is what you get if you do a move up on each individual element.

To avoid the ambiguity, UI designers gray out the buttons in those cases.

[wiebe@CARYA]

Not sure if it's the reason, but the selected items don't need to be subsequent. If they are not, moving them could be weird.

Don't get me wrong, I'd prefer the sometimes weird behavior over the lack of it.

EDIT: That crossed AQ's post...

[d.w.b]

I appreciate AristosQueue's feedback but it seems worthless to disable the buttons altogether. In my case the selected items were adjacent which is not ambiguous. They could be disabled only if not adjacent. But why? Pick one or the other implementation (either to be consistent with drag/drop or to be unique). I'd choose the later to have another tool at our disposal. Kudo if you prefer some functionality rather than a hand-slapped.

[AristosQueue (NI)]

I am not saying whether this particular dialog should change behavior or not. But I am going to highlight the general issues that come up in these discussions to explain why this isn't just a "slam-dunk NI should make this change" idea. 🙂

Disabling a button/menu item/etc sometimes and not others: how complex can you make the rule for disabling before the times when the feature is available vs not appears chaotic to the user and generates more net frustration than is solved by sometimes enabling it? An endless UI debate.

Then there's the "we should just pick one of these two ambiguous options to make some people happy" vs "if it is ambiguous, we should disallow it until it isn't ambiguous." Does a user notices when it does something they didn't expect? How likely are they to notice? How easy is it to undo to their previous state? If they can undo immediately, good, but if they don't notice until a little later when they've committed the edit, it's harder to undo. Another endless UI debate.

Devs go back and forth all the time. I've been in endless meetings that often come down to who is the actual implementer or which side surrenders first. You'd think user data would come to the rescue to help us decide, but, no, more often than not, users are just as divided. And that's how you get the third group who says, "Ok, then make it a Tools >> Options setting!" and you end up with the endless checkboxes for the tiniest features.

Maybe this one should change. Maybe not. I'm not saying one way or the other... just highlighting the issues.

[d.w.b]

> if they don't notice until a little later when they've committed the edit

Surely not applicable in this case.

> How easy is it to undo to their previous state?

Very easy with the second implementation. Press the opposite to undo if not what expected. And those that like how it works will utilize it and those who don't will just leave it alone like they do now--happy or content.

[wiebe@CARYA]

---

@d.w.b wrote:

> if they don't notice until a little later when they've committed the edit

Surely not applicable in this case.

---

It is very applicable in this case. User selects some things, moves up\down. User thinks A happened, while in fact it was B. User presses OK, and (days later) finds out A did not happen.

[d.w.b]

Then we will disagree. Very unlikely. Move by one, their eyes will be on their selections. They are doing it to accomplish something they have in their mind; they'll notice. Very rare if they don't.

[AristosQueue (NI)]

*grin* And thank you to Wiebe and DWB for providing exactly a demonstration of my earlier posts. *grin*

Guessing the frequency of X, or the percent of users, or the severity if rare case Y occurs: too often, these cannot be measured (not even with skilled UI teams that can do sophisticated user testing). Even when testing shows that in 99.9% of cases, the UI designer has to ask, "But is the inconvenience of the 99.9% worth it to save the poor user who ends up in that .1% for whom it is an absolute disaster?" Actually, it's not just UI designers -- it's any system designer or lawmaker who is establishing a system for general use. When do you favor the majority vs the minority?

DWB: I am strongly inclined to recommend NI reject this idea. The behavior was decided long ago. Nothing has really changed about the dialog that would bring new data to the table that the designers didn't have when it was first written. The effort is non-zero, and I have a hard time seeing that it would be a significant gain. I'll leave it open in case it accumulates kudos, but I'm not seeing a compelling case for changing. But that's just me, and maybe others at NI would see it differently.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.