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
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).
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.
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)?
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.
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.
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.
@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…
“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:
“Password” protect or force a verification when certain fields change
Have an email sent to a supervisor when certain fields change
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…
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.
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>?”
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
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.
We have just seen an issue with this, so here is a good example. On Order Entry, Header, Manifest Info, the COD checkbox you must click directly on the checkbox to change the state.
For Customer Shipment Entry (and all the shipment entry sheets), Manifest Info, there is a large space to the left of the checkbox that if you click in that space, the checkbox changes state.
Because 1 team enters orders and another team ships packages, each group wants to blame the other for an incorrect selection. I suspect the change to the COD value was an honest mistake by the shipping group (due to the large size of the clickable space for the checkbox on their forms) and they don’t even realize they made the change. Another possibility is that a shipped sales order (that has not yet been invoiced) can be reopened, and the COD checkbox can be changed and then the order can be closed (I did not think this would be possible, but I tested and it is).
If we did not setup tracking for this specific checkbox, is there any way to determine which user changed the COD checkbox (we are Public Cloud)?
If you aren’t tracking the field, there is no record of who made the change.
If that specific field is an issue, a small customization can unlink the label from the checkbox.
We also found this same thing can occur in Part, which is very unsettling. The selectable area for a checkbox is waaaaaaaaaay bigger than you would expect, causing folks to change part settings just by selecting the form.
