Beautiful and Easy Drawer Menus for Desktop and Go

Stepping up your design game

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.

Sliding Drawer Menus

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.

Jump right in and have a look!

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.

Download the Demo File!

The Basic Structure for the Menu

The menu setup is quite simple.  It comprises of a sliding panel object with 3 panels:

• The first panel (default) is empty and unused, it just happens to be the one the user ends up on by default.
• The second panel (on) is the panel that contains the actual menu and contents.
• The third panel (off) is again an empty panel, but is used to close the menu via a swipe gesture on FileMaker Go.

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:

• It has no fill colour so that you can see the underlying layout
• The navigation dots are hidden as they are not required.
• Swipe gestures are enabled so that the user can close it via swipe on FileMaker Go

A single script for opening and closing

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.

The basic way we open and close

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:

• The script goes to the third (off) panel
• It then animate going back to the second (on) panel.

and to close:T

• The script goes to the third (off) panel.

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.

The beauty and power lies within Script Triggers

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:

• What about opening the menu using the right-arrow key?
• What about closing the menu using the left-arrow key?
• What about using escape to close the menu if it is open?
• What about using a swipe-gesture to close the menu?
• What about tapping on an area outside of the menu to close it?

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:

1. If the user has the mouse cursor in a field, or a layout object such as a button has focus, it will not trigger the menu.
2. Otherwise, if the user pressed the left arrow key, close the menu.
3. If the user pressed the right arrow key, open it
4. If the user pressed escape key, close it
5. Otherwise just let the keystroke proceed as normal.

So simple and yet so effective!  Check the demo file and try these for yourself.

Taking it to the next level with FileMaker Go.

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 existing panel control & navigation script
• Enabling of Gesture Swipes on the panel object
• The onPanelSwitch Script trigger to capture the user swipe & direction
• The onGestureTap layout level script trigger to capture user tap on screen.

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.

Tap tap tap!

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:

1. The string "tap" indicating a tap was done - we don't care about this.
2. A value containing how many fingers were used - we will only trigger with 1 finger.
3. The X coordinate in the document where the gesture occurred - we want this!.
4. The Y coordinate in the document where the gesture occurred - we don't care about this.

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.

How to tell if the user tapped off the menu

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:

• GetLayoutObjectAttribute ( "menu.on" ; "right" ) gives the right-edge coordinate of the menu, where "menu.on" is the panel object name.

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.

Some other considerations when implementing

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:

• Just drag it off the edge of the layout while developing, OR
• Use the new layout object inspector in FileMaker 16 to hide the object while in layout mode. 

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

Limitations

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.

Demo File Download

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.

Download the Demo File!

Feedback and comments are always appreciated!