Checkboxes clickable area extends beyond just checkbox

ERP 10
#1

I’ve got some fearful users in that they recently discovered that if you click on the label near a checkbox and sometimes the area extends further out past the label the checkbox toggles. The fear is that we have random checkboxes toggled that we didn’t mean to toggle which lead to Fear, Uncertainty, and Doubt(FUD)…

After asking why you would click near a checkbox if you don’t intend to toggle it the responses were:

1.) To gain focus of a screen in the background(I advised them to use the alt+tab or click the bar at the top of the window)

2.) Nervous habit they’ll click as they are thinking, but the expectation is I’m in a “safe” area to click(I advised don’t do that :slight_smile:

Just curious if anyone has experienced this or has any suggestions / feedback so I can help calm my users down that this isn’t a bug, I believe this really is a UI design feature and not a “feature”(the old joke about developers that claim bugs are features…). As an example I tried to find a .Net page explaining this feature but couldn’t find one(I don’t know myself if it’s a .Net feature or specific to Epicor). Who knows maybe there is a knob somewhere I can toggle to disable this(you have to click right on the checkbox to toggle it).

Any feedback would be appreciated.

#2

I actually prefer that you can click on the text next to the checkbox to select it. This is true with radio buttons too.

If you really need to prevent it, unlink the label from the checkbox or radio button. And check the size of the checkbox control. Shrink it to 20x20.

FWIW - the bigest UI issue my users have had was when a drop-down list covers other controls. And users would double click the item in the list. The first click would select the drop-down item, the second would toggle a checkbox that was under the drop-down list when it retracted.

2 Likes
Epicor Security - Only give access to certain people to certain screens
#3

Not as big a problem in the E10 client, but on websites I’ll use the mouse wheel to move the page up or down. If a drop-down list currently has the focus, it will change the selected item.

Possible future issue with Kinetic UI?

Also on the UI front, does the the Mobile interface or Kinetic support touch events like LongClick(), gesture scrolling (using 2 fingers to scroll/pan)?

#4

Additionally, the checkboxes can be more than 19x19 square. If they are wider, then the “empty” space next to it can be clicked and you would actually be clicking on the checkbox object.

1 Like
#5

@Jason_Woods if we wanted to minimize the clickable area for all checkboxes is there a way to do this programmatically or is it a manual task?

#6

There are topics on here for “walking through” all the controls on a form. While doing that, you could check the control type, and change its size if it is a checkbox.

#7

I would be very curious about what specific items are being clicked “accidentally”. I would want to ensure it is an accident and not something else before heading down that road.

1 Like
#8

@Jason_Woods Great thinking, but how could you know this what caused the issue other than asking people that made the change?

Here is what typically happens - something is wrong and we track is down to a part setup issue. Typically things like the part is stocked but it’s marked as non-stock. We check the changelog and see who changed it and when, and ask them why they made the change and the response is - Epicor is buggy it changes checkboxes when I don’t intend to. My boss / ownership is also frustrated saying well Epicor is just really buggy… We need to lock it down more so people have less chances of accidentally checking checkboxes they don’t mean to.

I think it’s one of those things where this has never happened to me, I’ve never seen my name in a changelog accidentally changing a checkbox so I can’t relate but most of our end users are upset saying it’s an Epicor bug…

#9

“Buggy” may not be a good description. More likely, they made a change that had unintended results. There are bugs, but not like the one you are mentioning. I would offer that if the user changes values on fields that should be reviewed, you can setup lots of ways to review and verify the results.
Ideas:

  1. “Password” protect or force a verification when certain fields change
  2. Have an email sent to a supervisor when certain fields change
  3. Use a dashboard to show exceptions
#10

@Jason_Woods thanks so much for the ideas.

We currently use the email approach when important fields change, don’t know why I didn’t think of that… I don’t understand the idea of a dashboard to show exception, could you explain more maybe this is something we could benefit from?

Agreed buggy is not a good term, but unfortunately that connection has been made in most of my end users minds including ownership and changing the perception hasn’t been easy…

#11

Totally understand. “It couldn’t be my fault, it must be the system”…
For an exception dashboard, it would list parts that don’t conform to some norm.
However, you may want some special part class or product group (or some other field) that the part cannot be non-stock unless it is one of those other values.

#12

You could make a BPM that looks for seldom changed fields (like Non-Stock, Type:Pur/Mfg/Kit, etc…). Fields that are usually only set once - on initial entry. And if any of these change, throw up a message saying “Did you really mean to change <field name>?”

#13

if the user happens to click on the label by the checkbox, the checkbox gets checked.
We had the problem happen so frequently that for the Part Entry form we “disconnected” the labels from the checkboxes when the form loads

#14

As a habit, when activating a form, I click in an area that has no data. Interestingly enough, one of my associates this week asked why Epicor doesn’t automatically default to the indexed field when you load a form.

I don’t have a good answer for that…