Hey All,
We have an app that is used to manage jobs at each machine. One of the things this app tracks is the # of good parts created and there is a manual override so this can be updated if for some reason it is incorrect (restarting a job, etc). To do this we go to a separate step where they can enter the new value.
This is where it takes them:
The annoyance is it will always show the current value in this cell, so the operator needs to struggle to select it and delete it on a touchscreen to update it. It would be really nice if on number entry objects there was an option to ‘hide current value’ so it would appear just as a blank box when they hopped into this step.
The only current workaround would be to have a separate app variable for ‘new count’ and set that to blank until they click submit and at that point update the app variable. This is probably fine for 1 variable, but if we want them to be able to change any of 40 different variables, this is less than ideal.
Thoughts?
Hi Peter – I am not sure about masking the value of the variable. I feel it could be misleading to the user of what is being stored to analytics vs. what is seen on the screen and may flag some data integrity issues with our regulatory teams
We can try and be creative though - one suggestion is that you could add +
and -
buttons to the left and right of the value. The triggers behind this would be to increment the value up and down. This could get around some of the UI issues with having to select the value on the screen.
What do you think about that?
Hey Sackly,
The + and - buttons are an ok solution to this problem, but not a great one because often we are often changing the values by hundreds or thousands, so + and - buttons arent great.
As far as data integrity - I certainly understand how people could use this functionality wrong and get confused about the cells actual value. This isnt something I had seriously considered.
Wondering if there is a fix around this that wouldnt require tons of duplicate variables and added complexity.
Thanks,
Peter