User login methods on shared iPad?

[HALBURN]

I have a factory with multiple users and multiple iPads that are accessing a networked solution running on FMS12A.

The Goal: Have a secure solution that is easy for users to quickly log in and out of so they can enter their tasks into a production schedule. The users are sharing iPads, grabbing whichever one is the closest to them.

Current Solution I am using a launcher database that is installed on the iPads. It has a complex password and it is set to automatically enter the user name and password on launch and open another database that is running on the server. After solution on the server opens it takes the user to a login layout which has a custom keypad and (password hidden) field that represent the access code is being entering.

The Problem: The custom login keypad is executing a simple "Set Field" script when the user taps out their access code. The problem is that FMGO 12 does not let the user trigger a script if another script is already being run. It pops up a warning that asks the user if they want to cancel the script that is already running. This is very problematic. The users are trying to enter their codes very quickly and they are getting frustrated with the script warning that keeps popping up. It's particularly bad when the user has an access coded that has a number that repeats (e.g., 2210, 5688).

Does anyone have a good solution to this problem? I need a solution that provides very fast access.

Thanks.

[Vaughan]

Do the users really need to log-in (as in re-authenticate) or does the business process only require them to *identify* themselves?

[HALBURN]

I need to prevent users from accessing other users accounts. (timeclock, tasks, etc.)

[RodSierra]

Perhaps along the lines of what Vaughan is alluding to:

We use a pin access system that allows for quick change between operators in a semi controlled environment, such as a production floor. When a user logs out all that happens is they are taken to an internal log in screen with a keypad. Upon re-login the current user id in the admin table is then set to the new user, and is verified along with the privilege set name the system is currently running under via a simple script. This has worked great for years for us in production environments where many users need to get quick access for short entries and data checks. A logout button nulls the current user id for that station and takes them back to the login screen. I'd recommend you combine a simple user pin with a privilege set check, that way they cannot access a time clock, which should have a separate privilege set name.

[Vaughan]

Sounds like they need to re-authenticate. Just pop-up the native Login, trap for errors, and run a script to reset everything if the login authenticates.

If there are complaints that this is too hard to too time consuming then you'll need to reduce the requirement that the users only need to identify themselves. This could be as simple as selecting their name in a global field.

[HALBURN]

Perhaps along the lines of what Vaughan is alluding to:

We use a pin access system that allows for quick change between operators in a semi controlled environment, such as a production floor. When a user logs out all that happens is they are taken to an internal log in screen with a keypad. Upon re-login the current user id in the admin table is then set to the new user, and is verified along with the privilege set name the system is currently running under via a simple script. This has worked great for years for us in production environments where many users need to get quick access for short entries and data checks. A logout button nulls the current user id for that station and takes them back to the login screen. I'd recommend you combine a simple user pin with a privilege set check, that way they cannot access a time clock, which should have a separate privilege set name.

Yes, this is exactly what we are doing. It's fast but apparently not fast enough to keep up with the speed of the average user's entry speed. We have been using the solution for a couple of days and I have been flooded with messages complaining that they keep errors while trying to log in unless they type very slow. I have witnessed it myself and it is indeed a legitimate complaint.

[HALBURN]

Sounds like they need to re-authenticate. Just pop-up the native Login, trap for errors, and run a script to reset everything if the login authenticates.

If there are complaints that this is too hard to too time consuming then you'll need to reduce the requirement that the users only need to identify themselves. This could be as simple as selecting their name in a global field.

I was trying to avoid using the built in keypad but we may have to resort to something like. Unfortunately the script triggering/performance problems are starting to be an issue almost everywhere in the solution. The entire interface is designed around the idea that the user will be rapidly tapping through a series of departments and tasks, drilling deeper and deeper into the solution. It's not a problem if there is lag but its a major problem if the user cannot trigger a script until the previous script has completed. Especially when they have no idea when a script has finished.

[RodSierra]

Not a long term solution, but you could set a global busy flag upon entering one of the effected scripts, and clear that flag at the end. Then add a loop at the front end of the scripts that waits for the busy flag to clear to continue. If doing this I'd put a timeout out counter on the loop and throw an error if it timed out.

We tested a similar keypad on an Ipod touch back when we tested our solution to transfer it from touch screens to IPads on FM11, we did not see any problems, but have not implemented it fully, as everyone is quite happy using touch screens now, and we have no plans to go to FM12 for quite some time.

[Vaughan]

I was trying to avoid using the built in keypad...

So use an external keyboard. The iPad will work with USB keyboards (with the camera kit to provide the port) or with bluetooth wireless keyboards.

[IdealData]

I too have been using a PIN code authentication system now for many years, and I did look at the iPad as a data entry terminal - but performance on scripted buttons was too slow (I eliminated the keyboard in my app), in fact slow enough that 'shoulder surfers' could easily see the PIN code being entered. In the end I went with various touch screen tablets running FMP.

FWIW, IWP performance is faster in iPad.