FileMaker 12 includes significant changes to tab panel objects that make using pop-up overlays far easier to implement. Now, tab panels are “less sticky” and can be moved freely around a layout without the risk of inadvertently picking up objects that were not intended to be contained in the tab panel. Our colleague Daniel Wood over at Digital Fusion offered an excellent detailed description of this new behavior in his blog post Cool things to do with Tab Controls in FileMaker 12.
In particular, I was intrigued with the idea of using invisible tab panels to provide pop-up data entry overlays on FileMaker user screens. Here is an example from a customer database that uses an overlay to display a portal that allows users to select a Contact record and add it to a list of related contacts in a Company record:
Step 1: User clicks the ‘+’ button to expose the data entry UI in a invisible tab panel
Step 2: User selects a contact records from a filtered portal.
Using this design pattern offers some really excellent advantages both for the developer and end user:
- No new layout is required to provide a pop-up window
- Space is saved on the current layout
- User is provided a data entry UI, visually aligned to its purpose
- Opacity features of the object give the interface a clean, modern look
- The interface is intuitive and easy to understand
Of course, no pro/con article would be complete without the ‘con’ side. And in particular, this technique can have the effect of increasing the maintenance burden on the layouts where it is used. As stated previously, FileMaker 12’s improved tab panels can be freely moved around a layout and they will not ‘grab’ objects from the layout. The reverse, however, is not the case. That is, if an object that is within the borders of a tab panel, but not part of the tab panel, is moved – even one pixel – it will become part of the tab panel and from then on move with it. These screen shots illustrate the point:
The Title field in this screen shot is behind the tab panel, but is not a part of the panel. The panel can be moved and the Title field will stay put.
The Title field has lost its independence from the tab panel by moving the Title field 1 pixel.
Further complicating layout maintenance is the fact that objects behind the tab panel are difficult to access without first moving the tab panel. Any modification of the Title field, for example, would require the developer to first move the tab panel, make changes to the field and then move the tab panel back. This adds an additional layer of inconvenience to layout maintenance. And it requires the developer to remember to put the tab panel back in place before shipping an upgrade to the solution!
It is of course possible to access the field under the tab panel without moving the tab panel. This is accomplished by holding down the command key (OS X) or control key (Windows) while in layout mode and using the mouse to drag a rectangle around the object until it is fully enclosed. This method of layout object selection selects only objects fully enclosed within the rectangle and can be used to precisely select single objects on complex layouts.
Given this additional maintenance burden, I would conclude that hidden tab panels used as interface overlays should be used carefully and sparingly. Developers should consider the complexity of the layout, knowing that multiple objects around and behind the tab panel will increase difficulty in maintaining the layout. In these cases, a dialog window may be the best choice for providing this type of data entry interface to the user. That said, simple layouts may be a perfect match for this technique and effective use can enhance the appearance and usability of a layout.
Special thanks to MightyData customer Younger Partners for granting permission to use images from its database.
I use this technique extensively in my designs, and an additional con is a tab panel over a portal will cause the mouse wheel to not scroll the portal.
I like to use a tab overlay to capture data into a global field that overlays the display fields and capture information on a layout that may not reference another TO for adding info ie ( add an additional address to a client address TO from a work order layout.
Thanks for pointing that out. Odd that you can access fields under the hidden tab panel, but can’t scroll. BTW, I am converting all of the popup overlays to popup windows in this solution. Except for the small hidden tab panels that do not overlay other objects. I will use the location of the ‘+’ buttons to position the popup window, so the effect will be similar.
I’m running into this problem as well. Hopefully it’s a bug that will be fixed for v4.
Yes, it can cause confusion for the user to not be able to scroll a portal, or be able to scroll only on part of it.
We are using this technique in a couple of solution, for admin type functions or occasional layout specific reports to keep the UI as clean as possible. It does add a layer of maintenance, but the key for us is consistency with placement and only use it when there is a benefit for design. We have modified the technique by using a strategically placed button that calls a script to open the panel under it. This also adds a security layer. Scripts triggered from the panel, close the panel. We have found that by trying to work a layout to be more “web like” users are quicker to understand the functionality.
Thanks for the additional input, Joe. I could see these hidden overlays as working really well in FileMaker Go applications where you would want to avoid leaving the currently layout to preserve the flow of the user experience.