By Daniel Wood, 18 July 2017
FileMaker is no longer simply a database development tool.
With FileMaker edging closer every day to being a fully fledged mobile and desktop application platform, as developers we should be striving to build the best user experience possible. That means building controls that both look and behave to the same standards as if they were developed in any other platform.
Until recently this has been quite a challenge in FileMaker. We have been restricted by controls that were limiting in their functionality, and often needing to resort to plugins or simply putting things in the too hard basket.
It is my belief that as FileMaker developers we should no longer be settling for "just good enough". We need to step our game up and become great designers and developers of applications, not just databases. If we can build controls that are easy to drop into a solution and use (even if they are complex underneath it all) then we should be doing this for the betterment of the user experience. After all - what we build is for people to use all day every day.
We have covered these types of menus in the past. A couple of years ago I wrote an article about how they can be built using sliding panels. That article went a little over the top by having the menu open/close simply on a mouse-over action through the use of a plugin and tooltips. The technique while workable had some limitations - the plugin on FileMaker Go and WebDirect being one of them.
Recently I began development on a large client solution and decided to overhaul this technique and make it both easier to implement, and more usable and reliable. The menu was to work on both FileMaker Pro and in FileMaker Go.
I wanted the drawer to look and feel as native as possible, and leverage all the tools that FileMaker provides to give the user the most native experience.
We always try to build easy and user friendly demo files for our articles and this one is no different. You can download the demo file that accompanies this article below. Have a play round, explore, learn how it works. Make sure to try it on all platforms such as FileMaker Pro, iPad, and iPhone.
The menu setup is quite simple. It comprises of a sliding panel object with 3 panels:
So that's it, pretty simple huh! This panel object can be placed on your layout wherever you want the menu to be (typically the left edge). There are a few other design considerations for the panel:
There is a single script responsible for either opening the menu, or closing it. Under normal circumstances, the script does not accept a parameter, and the default action is to toggle the menu on or off.
The script keeps track of whether the menu is open or closed by way of defining a global variable - $$MENU.STATE. When it has a value of 1, the menu is on, otherwise it is off.
Recall our object has three panels. When using a left of screen based navigation the following actions are done to open and close the menu. First, for opening:
and to close:T
Our demo file is built on the basis of the menu opening from the left of screen. If you instead wanted a right of screen menu, you simply reverse these actions. To open the menu you would start on the first panel and go to the second. To close, you go to the first panel. In fact, the right-of screen menu only requires 2 panels, not three.
While the above menu script & processes are great, they are for toggling a menu on and off through using an action such as the user pressing a menu button on the screen. But you can take this so much further and make the menu so much more usable by leveraging script trigger functionality.
Consider other ways the usability could be enhanced:
We can do all this, and it's easy!
The first three actions can all be done by using an onLayoutKeystroke script trigger with a corresponding script. These are leveraged for FileMaker Pro where keystrokes are used. In the demo file this script is provided and used. The script needs to check a few things, but its basic operation is:
So simple and yet so effective! Check the demo file and try these for yourself.
The sliding drawer while a great desktop control, really shines on the iPad and iPhone due to these devices limited screen real estate and extra usability features we can leverage. It is a control you commonly see in a lot of native iOS applications, so users are familiar with how it works, and there is a certain level of expectation also that goes along with a drawer as to its behaviour.
The following FileMaker tools have been leveraged to give the complete user experience:
The onPanelSwitch script trigger captures the target destination panel. If the menu is open (on panel #2) and the user has swiped to the third panel #3, then they have swiped their finger to the right in a motion where the expectation is they are minimizing the drawer. Great! We can just run our navigation script to toggle the menu to close, done!
It is also interesting to note that swipe gestures work on the mac desktop in FileMaker Pro if you use a trackpad or mouse capable of having swipe gestures.
For the onGestureTap script trigger, it's a little more complicated, but once you understand how this trigger works it's simple!
The function Get ( TriggerGestureInfo ) returns us lots of useful information about the users tap:
The importing aspect here is whether the user tapped with one finger, and where in the horizontal axis of the layout did they tap.
Why do we care about where they tapped? If you look at the behaviour of most sliding drawers on iOS, a tap within the menu does not close it, yet a tap on screen outside of the menu area will close. So that is the behaviour to be replicated.
Again, more simple leveraging of the tools at our disposal.
The panel object has been defined, and all the panels are named. So the GetLayoutObjectAttribute function can be used to get all the information needed:
So knowing the right edge of the menu and knowing the coordinate where the user tapped, the script simply needs to compare the two values. When the user tapped a coordinate greater than the right edge we know they tapped outside of the menu.
This menu works great and it's a beautiful modular control you can throw on your layouts. With just a few scripts and controls you can have it up and running in your own solution. To make it more usable, consider building the contents of the menu via a context which is universal (accessible from all other layout contexts). This allows you quick copy/paste of the control onto other layouts for use and you don't need to worry about changing field and portal references.
Because the panel control sits on your layout, it can be often annoying trying to work in layout mode with it present. There are 2 options at your disposal:
Remember, the panel control should be at the top of your layouts ordering so that it sits on top of everything else - you don't want other underlying layout objects to appear in front of it!
Finally, it is recommended to use a fill coloured rectangle to replicate the actual menu background, as opposed to simply filling the colour of the panel itself. In our example, we have attached a single "Exit Script" script step to this rectangle object.
This is done so that if the user is clicking or tapping on the menu, they are not inadvertently clicking on any underlying field on the layout. If you do not do this, there is potential for unexpected actions such as entering a field or clicking a button under the menu object, as shown below.
Panel is not the front-most object
While we are forever getting closer to perfect implementation in all circumstances, there are still some limitations to this technique. One of which is FileMaker's inability for objects to span vertically across layout parts. If your layout uses a top navigation or header, then putting this control in that part will not work as it chops off once it hits the part below. Actually in the solution I developed for this was the case, but it was quite easy to simply sit the navigation below the top navigation part in the body and it still works great.
This control doesn't work in list view or table view for similar reasons to those mentioned above. Hopefully one day FileMaker will give us horizontal layout parts so that the side of our layouts are a separate space for controls such as these.
Finally, the navigation control works great in WebDirect, but it comes with a caveat. In WebDirect, any object overlaying another will prevent the underlying object from being clickable as a button, or enterable as a field. In this case, the navigation panel sits at the front of the layout object ordering, preventing the user from clicking what lies underneath. In order to implement for webdirect, introduce a hide condition on the panel. Recall the use of the global variable $$MENU.STATE to keep track of whether the menu is open or closed. Simply add the hide condition of "not $$MENU.STATE" to work around this issue.
The demo file has been built to work on both FileMaker Pro, iPad and iPhone. If opening on a phone, it should open on a separate appropriately sized layout. On the iPad and Desktop, you'll end up on a larger layout. This demo is suitable for FileMaker Pro and FileMaker Go versions 15-16.
Feedback and comments are always appreciated!