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:
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:
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.