Integrating Kiosk Mode into your Solution

Kiosk mode is a cool way to run a FileMaker database in a full screen environment where users are prevented from accessing the other functionality of the operating system. But what if you have a normal FileMaker solution and wish to use kiosk functionality in certain areas only?

In this article we illustrate how a typical FileMaker solution can be enhanced with a kiosk component for carrying out certain actions. We use the article example file to help illustrate this. We also give some information on what kiosk mode is, and things to watch out for when developing for it.

So what is Kiosk Mode?

The majority of FileMaker solutions run in what could be called a normal windowed environment. Upon opening a database, it appears in its own window on a mac - or within the FileMaker application on windows. Users are free to use the rest of their operating system whenever they wish.

Kiosk mode is a little different in that it prevents users from interacting with the operating system, and keeps FileMaker open as the central and only application they can interact with. The term "Kiosk" is used because the functionality resembles that seen on kiosk machines in places such as restaurants, museums and so on.

How do you create a Kiosk file?

A FileMaker file by default has Kiosk mode disabled. Enabling is done by using the Developer Utilities dialog that is build into FileMaker Pro Advanced.

Select the file(s) you wish to enable Kiosk mode in by using the Add button, select the output folder also. You then want to click on "Specify" under Solution Options.

In here you want to tick the Kiosk mode option. Upon hitting the "Create" button on the main dialog, a kiosk mode version of the file will be generated.

Developing or Using a Kiosk File

Now that the file has had kiosk mode enabled, it is important to know how to access your file for either the purpose of using, or developing.

FileMaker help has this to say:

Kiosk mode is ignored if the solution is opened by accounts with the Full Access privilege set, a privilege set that allows management of extended privileges, or a privilege set that allows modification of layouts, value lists, and scripts.

This factor is key. If you want to develop your file, always remember to log in as a [FULL ACCESS] user. If not, you will inadvertently end up with the file open in Kiosk mode if your login account meets any of the criteria above.

If your file does open in Kiosk mode, then you have to provide a means for yourself, or your users to close the file. There is no native close option, so without a button or some other means to close the file, you will be stuck in the file and have to resort to other means to get out of the file - such as force closing the file on Server, terminating the FileMaker Pro application via remote login, or restarting your machine. Neither option is really nice so be sure to provide a way to close the file!

Now with that all out of the way, time to get into the guts of this article:

The whole point of this article is integrating kiosk functionality into a regular non-kiosk database. We know that a kiosk-enabled file will open in kiosk mode under certain conditions, so having a single file is not going to cut it because we cannot guarantee all users will have the required account level to open in kiosk mode always.

The solution is to build a secondary kiosk file that links to your main database. The kiosk file is called into action whenever that functionality is required. The overall process is not too difficult, but there are a number of things to take into consideration.

A basic example: Kiosk file for taking tests

One great use of the kiosk functionality is for users of the database who are required to take tests. If someone is taking a test then you would not wish for them to have access to things such as their web browser! Kiosk mode would be great for this given it restricts the users access to these things. For anyone who has ever taken the FileMaker certification exam, we are aiming for a similar feel here.

We will use the attached example file as the basis for the example in this article, so it might be a good idea to download it if you haven't already.

Step One: Link your main file to your kiosk file

This part is achieved by setting up external data sources in both your main file and kiosk file. Each file should have a reference to the other file. One way to think of the kiosk file is merely an extension of the main file. It doesn't need to contain its own tables or data, it is purely for kiosk functionality for the main database.

Step Two: Setup a Full Access, and non Full Access user

This is done in the kiosk file. This file requires a [FULL ACCESS] account so you can modify the file if need be. However to make use of kiosk mode, it will require an account that is not full access.

Here we have a full access account, and another setup as data entry only. The "Test User" account is the one that will be used by everyone who accesses the file for taking tests.

Here, we have set the Kiosk file to automatically login as this Test User.

A very important thing to take note of here is how FileMaker will attempt to log a user into a file that opens from another file. Lets say a user is opening File B from File A. Upon launching File B, FileMaker is going to try and find a matching user account in that file, and if one is found, log the user into File B with that account. In this situation we don't wish for this to happen. The reason is that if a user is logged into File A with [FULL ACCESS], and there is a matching account in the Kiosk file, then they would log into kiosk with [FULL ACCESS] and as such, the kiosk functionality would not work - they would log into it as if it were a regular file.

For this reason, it may be good convention to make the [FULL ACCESS] username and password in the kiosk file something entirely different from any [FULL ACCESS] account in your main file, that way this scenario will not occur, and everyone will open the kiosk file with the Test User account.

Step Three: Enable Kiosk mode

At this point it would be a good idea to enable Kiosk mode on your kiosk file if not already. Refer to the start of the article on how this is done, and some of the things you need to be careful of once the file becomes kiosk enabled.

Lets take a breather, where are we up to..

At this point we have the following:

• A main database file
• A kiosk enabled file with [FULL ACCESS] and non [FULL ACCESS] users.
• Kiosk file is set to login with non [FULL ACCESS]
• Both files are linked to each other via external data source.

The next steps will involve initialising the kiosk file from the main file, some issues that can arise from this process, and how we can resolve them.

Setting the scene for what we want to achieve

In the main file we have a portal of 10 test records as shown below:

When a user clicks on a test record, we want that test to open in kiosk mode. The user would then fill out the test, and when they are done, they would close the test and be back where they started. Sounds simple right?

Step Four: Initiating the Kiosk File

The kiosk file is closed at all times, other than when it is being used. We don't wish for it to appear in the FileMaker Windows menu, so we open and close it explicitly when we begin using it, and when we are done.

The above script is run when the user clicks on a test in the portal. At this stage we are still in the main file. The script is passed the ID of a test record, which will eventually be passed to the kiosk file.

The last script step here calls a script over in the kiosk file and passes it a test ID. This is how the kiosk file is initiated.

Step Five: Correct setup of Kiosk File

A script has now been called in the kiosk file which is going to open the file and initiate it. There are some very important housekeeping things that this script must do first in order to ensure that kiosk mode is watertight and prevents the user from getting out of it.

When a kiosk mode file is opened, and there happens to be other databases and windows also open, then these other database windows are also visible whilst in kiosk mode. In fact, if you click on one of the other databases it will switch to it and take you out of kiosk mode temporarily.

From a testing perspective this is bad news, if a user can get to another database open, then they can reveal their dock and get into their browser and so on.

The solution here is to ensure that when you open up the kiosk file, that its window dimensions are set exactly to that of the screens dimensions, so that the layout takes up the entire screen real estate, thus hiding any other open window underneath.

(Note that prior to this, we had used scripts to hide and restore all other windows upon opening and closing the kiosk file, these work fine, but simply making the layout size full screen is much easier and less scripting!).

Here is the start of the initiation script in the kiosk file. The freeze window helps the startup go smoother visually.

You'll notice we do a very brief pause of 0.1 seconds. The reason for this is that when the kiosk file opens, it very briefly opens in a normal windowed mode, before entering kiosk mode. Without the pause, our next script step that sets the window position and size actually happens while it is still in a windowed mode, and this makes it near on impossible to correctly set the window to full screen size (due to issues arising with docks and such).

The pause gives us just enough time to enter kiosk mode, so that when we set the window dimensions to Get(ScreenWidth) and Get(ScreenHeight) We are getting the full dimensions of the screen.

Step Six: Closing Kiosk File

When you are finished with the file and wish to return to the main database, you need to close the file by issuing a Close File script step command. Because kiosk mode has no exit or close command, you need to provide a means of closing the file by way of button.

In this case our big finish test button simply closes the file.

Some things to watch out for

While kiosk mode is a great way to present a full screen layout to a user (for purposes such as taking a test) - it is not 100% secure in keeping the user locked out of their operating system. While developing this technique for a client solution I realised there are some applications out there that are able to dump you out of kiosk mode temporarily. The one application I noticed that did this was Tweetdeck. Whenever this application sent a notification of updates, the resulting popup caused kiosk mode to exit.

As you can see above, we have kiosk mode running the file, yet the dock became visible.

So you need to be careful if using this for things such as testing, the computer should be setup with no other applications running that might interfere.

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is provided to help you fully understand what is going on in this article, and to let you experiment in FileMaker with this solution.

Download Example File

NOTE: Test_Kiosk.fp7 file has been set to login automatically as a non-admin user for the purpose of demonstrating kiosk mode. If you wish to access the file to have a look inside, hold down the option (shift in windows) key while opening the file:

Username: Administrator
Password: (no password)