Custom Keyboard Use and FileMaker Go
One of the most frustrating aspects of developing for FileMaker Go has to do with the iOS keyboard. At times, the keyboard can be unpleasant to use and restrict the usable space on your layouts. The following technique of using a custom keyboard can be used as an alternative way to enter data.
Developing for FileMaker Go presents the developer with some unique challenges that are not always obvious at first glance. Some normal layout techniques may not work well with a touch interface and you really need to put some thought into the workflow and how the user will interact with your layouts. Other things like button and font size need to be increased for better use and fidelity. The challenge that I would like to focus on today is data entry. When using FileMaker Go, upon entry into a field, the iOS keyboard rises up and consumes a tremendous amount of space on your screen. The effect is more noticeable in landscape mode; the keyboard takes up nearly half of your screen! This is a constant source of frustration for me when developing for FileMaker Go. To make matters worse FileMaker Go sometimes has issues with keeping the field in focus within the viewable area of the screen. I have not been able to find a complete solution to getting around the keyboard issues. But using a custom keyboard can allow bypassing the use of the iOS keyboard for data entry.
This article is going to make some assumptions about your current knowledge of some advanced FileMaker techniques and functions. I will not spend time explaining these techniques as they are not necessary for what I am going to show. For more information I would recommend reading up on Virtual Lists and the ExecuteSQL function.
Filtering With the iOS Keyboard
In the following example you will see a fairly standard picker. I am using a popover to show related virtual list records in a portal. A filter field that uses the iOS keyboard is included in the popover to filter the records shown in the portal using a scripted process to find and populate the virtual list using the ExecuteSQL() function.
Now let’s say we want to filter the portal. By tapping into the filter field we get a nice view of the iOS keyboard. The popover is reduced in size which also means that our total viewable results are limited. This is not what I would consider a great user experience.
There are a few options that may help with the above problem.
- You could use the iPad in portrait mode when entering data.
- You could resize the portal to fit better within the available screen space.
- You could make your displayed fields smaller.
None of these really solve the problem of reduced screen real estate when the keyboard opens.
Filtering With A Custom Keyboard
Now isn’t this interesting? By presenting the user with our own custom keyboard we can totally bypass the need for the iOS keyboard. Sure, this is somewhat a duplication of functionality but the results are worth the effort. I’ve found that using a custom keyboard for simple data entry, such as filtering records, makes for a much smoother and more user friendly experience.
If you don’t believe me, just try the custom keyboard demo file on an iPad. I’m sure it will change your mind!
How The Custom Keyboard Works
I simply made each letter a 40×40 px button and attached a script that gets passed a value that corresponds with the button label. This value is then set into the filter field and the normal search script is then triggered.
There are a few tips that help make this work.
- Make sure you remove all objects in the popover from the tab order. For some reason FileMaker goes to the first ‘enterable’ field in the tab order when opening a pop-over which causes the iOS keyboard to open. This will still occur even if you have Field Entry in Browse mode unchecked!
- Disable browse mode for Field Entry on the filter field. The same problem above can happen when the user taps on the field when the Field Entry: browse mode option is enabled. Disable this option unless you would like the user to be able to enter into the field with the iOS keyboard.
Check out the custom keyboard demo file and feel free to use this custom keyboard technique in your next FileMaker Go solution!
Click here to download the Custom Keyboard Demo file.
Calvin Cooper is a FileMaker Certified Developer at Skeleton Key.
About Skeleton Key
Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.