3

I've just inherited an application where there is a form.

It opens, in the unlocked state it is like

enter image description here

If I click the padlock toggle button, the form will look like enter image description here

The arrows at Up Position and Down Position are active control areas which when clicked make the Knife drawing go Up and Down; this is also reflected in the text over the "Above the belt text".

The only thing that the padlock button locks are those arrows. They come red when inactive and do nothing.

Questions:

  1. The only tool types that will allow moving up and down are Knife and Pen. Will it be beneficial to put the locking control in the respective tab?

  2. Is putting the arrows red the best solution to say that arrows functionality are not available? For me it seems a more "vivid" color than black (used when they are active)! Or not showing them at all? But this could mislead the user that the Knife and Pen Tool have not "Move Up"/"Move Down" functionality, which is false!

  3. The padlock button suffers from the old problem of a toggle button with two states, in which you don't know where the drawing you see is the current state or the command that it will do when clicked (Please, share documentation on this). I've been tasked to add a label to it, but it seems to me that is not enough. If I do the labeling to be dynamic depending on the state, I will violate the principle of "visual inertia" (a minor annoyance).
    Would it be better to change it to a checkbox and loose the graphic beauty of its icon?
    The best way I think the problem I described on this point starting is solved is by using Android like toggle switch controls. As the Application has been built over MFC / Microsoft Visual C++, as far as I know, those type of switches are not available. If somebody knows more on this, I will appreciate the knowledge sharing.

  4. As the only thing the padlock locks are the arrows, wouldn't it be better they were nearer the arrows? If I put them near the arrows, then another problem begins: the pad lock will be only near to one pair of arrows, but it will really block the two pairs! How can I put the control seeming it locks the two pairs by becoming close of all arrows?

UPDATE

  • After doing some higher priority things, I turned back here. Now, looking at the code, I discovered the Lock button does not lock anything. What it really does is to change the step of how much will move each time an arrow is pressed! To turn things even more strange, the Red arrows mode is a slower movement than the Black arrows mode!
  • The controls for the cutting speed looks a little bit confusing to me. What does the '0' represent and is there a reason why the '1.25' label overlap with the image of the blade? – Michael Lai Mar 10 '16 at 1:11
  • @MichaelLai: No. I think three is no reason. And if the form was designed by me, it would not happen for sure. – sergiol Apr 1 '16 at 18:09
1
  1. Yes, unless you also have other parts of the application where you can lock entire windows (now or in future releases), then you'll have to figure out a way to do both without making it confusing.

  2. I think it is interesting that they have chosen to highlight the inactive state rather than the normal convention of greying out for a disabled state with normal colours in the active state. But if the users are familiar with this pattern then perhaps it is not a good idea to change.

  3. This is a common problem with toggle buttons, and there are lots of previous questions and answers about best practices. In summary you should not combine states with actions (i.e. lock as the action and unlocked as the state), so if you separate those things and apply the label appropriately then it shouldn't be an issue. I think it is better to have a button with the label as an action, and use the padlock symbol as the status indicator instead. Toggle switches can be a little bit annoying to use on desktop applications, but you still need to apply the same principles to design the labels and state indicators.

  4. I think rather than trying to re-arrange the entire interface (perhaps save this for the overhaul of the whole tab), perhaps another way out is to add more details to the label for the lock feature (e.g. lock knife position), then you don't have to reposition it and there's no confusion about what it does.

  • 2. I think they've choose the red color, because it conveys a message of forbiddenness. – sergiol Mar 10 '16 at 19:51
1

The only tool types that will allow moving up and down are Knife and Pen. Will it be beneficial to put the locking control in the respective tab?

On the principle of "group related controls together", I would say yes, here, though the placement of the lock within the tab should be consistent. In its current position, the "Lock" icon suggests that it will lock the entire tab (or possibly the entire form).

(It is not clear to me why these controls in particular need to be lockable; if there is a reason for that then the UI should convey that reason.)

Is putting the arrows red the best solution to say that arrows functionality are not available?

Absolutely not.

The first problem here is that it is not at all clear that those arrows are interactive; they appear to be part of the illustration. The controls in your form are split between standard old-school Windows UI buttons-with-borders, and pictorial controls like these arrows and whatever's going on in the "cutting speed" section. Keep the illustrations if they are familiar to your users, but switch the interactive controls to standard UI buttons and sliders. And, in keeping with that metaphor, they should follow the ubiquitous convention of "dimmed means disabled".

The padlock button[...] you don't know where the drawing you see is the current state or the command that it will do when clicked

The problem you describe is common for toggle switches, but the padlock represents a physical object and as such should show its current state -- a locked padlock means currently locked, an open padlock means currently unlocked. Common usage reflects this, as in OS X for example:

enter image description here

There'd be nothing wrong with adding supporting text (as, again, in OS X) but I'm not sure it's necessary. Changing those "Arrow" buttons from #1 to the standard "dimmed when disabled" will further reinforce this, since their dimmed state will also indicate the lock state.

Would it be better to change [the lock] to a checkbox

No; that would be much less clear.

As the only thing the padlock locks are the arrows, wouldn't it be better they were nearer the arrows?

Generally yes, though you would of course need to rearrange that portion of the control surface to make room for it rather than simply blocking some of the arrows as you suggest. You'd also need to take care not to too closely associate the padlock with one set of the arrows but not the other, as that would be equally misleading.

One quick-and-dirty possibility (I've done a hack job of it here, but note the "well" grouping the padlock with both images, similar to the well grouping the slider controls at right):

enter image description here

the Lock button does not lock anything. What it really does is to change the step of how much will move each time an arrow is pressed!

Well, that's just plain a bug. Some developer who didn't care very much about usability was in a hurry, one assumes.

(There are other, obvious, layout and usability problems in this form which you haven't mentioned -- just to hit a highlight or two the gap between the tabs and the controls is far too large, and the text overlap in the center block is... not good. I have no idea what the imagery under "cutting speed" is supposed to represent -- if that triangle thing on the left is supposed to be a slider, please change it to a normal form control; the graphics aren't helping communicate here at all.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.