LOgiCATOR, Part 2: FileMaker Card Windows and Modular Design

In Part 1 of this series, Introducing LOgiCATOR, I mentioned that LOgiCATOR grew out of a search interface I developed for a project several years ago. In ways we’ll briefly consider here, it wasn’t extensible, but all that has changed. As that early search interface grew into LOgiCATOR, it made a quantum leap in context independence. The reason we were able to accomplish that can be attributed to a powerful synergy of FileMaker card windows, JSON, window improvements, new functions, and the Layout Objects window — in short, FileMaker 16!

Visit the LOgiCATOR page at Beezwax.

Here in Part 2, we’ll explore how card windows made a huge difference, providing a whole new way to think about modularization and application architecture in FileMaker. We’ll also look at 16’s other window improvements, two new functions, and the new Layout Objects window, all of which helped me develop LOgiCATOR and polish its UI.

We’ll save describing the central role that JSON plays for Part 3, Ready, Set, Integrate…into your FileMaker apps.

In that early search-UI incarnation, I used a transparent popover to simulate a macOS-style modal sheet, and placed a portal in that for adding search rules. The upside was that the user never left the context of the table they were searching, so from a coding standpoint, there wasn’t much need to pass serialized data around, and from the user’s standpoint, they remained comfortably rooted on the layout they were searching.

The BIG downside, however, was that the search-rule list had to be shown in a portal. That meant that there had to be a relationship from the main data table to the tables that facilitated the search setup. That wasn’t too bad when I was only using a hard-coded interface to search in one main table, but it would be another thing altogether to develop a solution in which that same search interface could be called up from any of dozens of different layouts and contexts.

Card Windows in Depth

When Vince Menanno suggested I revive that dormant project and turn the old search interface I had showed him into a module that could be used in other FileMaker applications, it occurred to me that using the brand new card-style windows in FileMaker 16 would allow me to continue to present a UI styled after macOS sheets, but free me from portals and relationships. Why? Because card windows, while they may feel like yet another layout object, are . . . well . . . windows. Like any window type, they have their own context, which may be different from the parent window. Also, instead of being limited to showing records in a portal, I could use a traditional FileMaker list view. Goodbye, tangles of relationships! Adios, UI limitations of portals!

I was instantly excited, because that meant I would be able to drop the LOgiCATOR tables into a FileMaker application and wouldn’t have to hook them up to that solution’s data tables — a big step toward modularization. Then fellow bee Lon Cook asked me why I wasn’t just keeping this as a separate file, so that you wouldn’t have to copy the layouts or most of the scripting into the data file at all. I must admit that my mind briefly rebelled: a card window feels so much like a layout object, on par with popovers and slide panels, that I found myself wondering if you really could show an entirely separate file, in a card window. Well of course you can; it may not have the chrome of the other window types available in FileMaker, but it’s a window nonetheless. Let’s briefly review the available window styles, and then take a look at some features of card windows.

Before 16, FileMaker had three window styles: Document, Floating Document, and Dialog. A Document window is the “standard” window type; it is nonmodal — you can interact with other windows while it is open — and while it opens as the front most window, it naturally falls behind other windows as you switch focus away from it. A Floating Document is similar: it, too, is nonmodal, but remains visible in front of other FileMaker windows even as you interact with other windows in the application. Were it not for the unfortunate requirement for an initial click to switch window focus, it would be perfectly suited to inspector-like palettes.

A Dialog window, in contrast to the two document styles, is modal, preventing interaction with other windows while it is open. The description in the “New Window” Options dialog that accompanies the “New Window” script step in FileMaker 16 adds a bit of explanation not seen in previous versions, describing the dialog as a “window that is modal to the application.” That last part is an important differentiator between these and the new card windows, and means that a dialog window prevents interaction with all other windows that may be open in your FileMaker application.

The new kid on the block is the Card window style. The description in the “New Window” Options dialog describes it as a “window that is modal to its parent window.” This means that the user can interact with other open windows in their FileMaker application, but not the parent window from which the card was directly opened. You may remember several macOS versions back, Apple introduced a dialog style called a “sheet,” which appears to drop down out of the window’s title bar. Sheets are used in many applications for presenting Print, Open, and Save dialogs, among others. In every case, a distinguishing feature of sheets is that they are modal to the parent window from which they are opened.

Safari Print Sheet

The modal-to-parent behavior of FileMaker’s new card windows, along with the absence of chrome (title bar, borders, etc.) makes them ideal for presenting sheets in FileMaker, and instantly became the obvious choice for the main content view in LOgiCATOR:

LOgiCATOR Card Interface

The options for card windows are limited:

New Window Options

You can opt to include a close button (an icon button with an “X” in it near the upper left of the window); if you leave this unchecked, be sure to include your own button on the layout to close the window, or force-quitting the application will be the user’s only way out. And you can choose to dim the parent window. To my eyes, the dimming goes a bit far — they could almost have worded it “blacken parent window” — but it’s useful for directing the user’s visual focus on the card’s content.

Unlike other window styles, there are no options for resize, menu bar, or toolbars. This is consistent with the minimalist, chrome-free nature of cards. That said, we find ourselves hoping for future versions to allow corner rounding, transparency, and maybe even blurring of content behind the card window, for a truly polished, iOS-like experience. Also note that card windows are not compatible with WebDirect. But don’t let these issues dissuade you from discovering the great uses to which card windows can be put today in your FileMaker applications.

It’s worth pointing out here that card windows (being windows, after all) can extend beyond the borders of the parent window, or even be positioned entirely outside of the parent window. (See “Other Window Improvements,” below, for tips on sizing and positioning card windows.)

One setting in which you should consider using card windows is as an occasional replacement for popovers. Each has its strengths; the following table may help you decide which one is right for a given use.

Popovers vs Card Windows

Window styles can be thought of in terms of which style can be opened from which parent style. The following table summarizes the possibilities.

Window Types Table

Note that you cannot open a second card window directly from a card window, but you can open a second card window from a document, floating document, or dialog which was itself opened from a card window. Confused yet? Remember them like blood types: document and floating document are “universal parent” windows (i.e., any style of window can be opened on top of these), whereas dialog is the “universal child” window (i.e., it can be opened on top of any other window style, including another dialog window).

Just the Beginning!

Sheets and popover alternatives are just the start! As LOgiCATOR exemplifies, the ability to use a card window to show content from a different context, and even an entirely different file, is going to open up a whole new avenue for providing modular widgets and functionality, as well as new paradigms for thinking about application architecture. (Check out John Renfrew’s excellent “CalPick” date-picker module for another pioneering example.) This is going to be an exciting era for FileMaker developers!

Other Window Improvements

You may have spotted a couple other changes in the New Window Options dialog above. First, you can now specify the target layout directly in the New Window dialog, rather than requiring a separate step: a small but useful addition, which nicely prevents the firing of triggers on your current layout.

Second, if you choose card style and specify a layout, the height and width options default to the selected layout’s dimensions — an automatic “resize to fit” (a nice touch!). If you don’t specify top or left settings, the card will open centered relative to the parent window (another nice touch!); if you do specify either of these settings, they are measured from the edges of the parent window, not the screen. As mentioned above, card windows can extend beyond or be positioned outside the parent window, so sometimes the top and left measurements will be negative values. Note that, for card windows, Get ( WindowTop ) and Get ( WindowLeft ) return the card’s position relative to its parent window, not the screen. That makes sense, but can catch you off guard if you’re trying to position a dialog window on top of a card window, as the Top and Left settings for the dialog will still be measured relative to the screen.

Another welcome window change is the removal of 1980s-era zoom and mode-selection widgets at the bottom edge of the window. The window bottom (all styles!) now comes chrome-free for a clean, modern look. Among other things, that finally lets us create professional looking dialogs and move away from the limits of Show Custom Dialog once and for all. The “Save Search” dialog in LOgiCATOR provides a simple example.

Unique Values and Sort Values

These are two functions are likely to slip under the radar for a lot of devs, given all the other great new stuff, but both are as useful as they are overdue. Feed them a return-delimited list of values and they will do just what their names claim, supplanting the need for recursive custom functions or ExecuteSQL calls to do the same. Note that these join Left/Right/MiddleValues and FilterValues as functions that append a trailing return to their result. I made use of UniqueValues in LOgiCATOR to weed out duplicate field names after scraping the layout for fields to search, in order to generate the final field list that shows up in the first popup menu in a search-rule row.

Layout Objects Window

Around the Beezwax office, I’m known for waging a (minor) war on complex layouts with deeply stacked and seemingly infinitely grouped objects. Performance issues aside, I break out in hives when I have to maintain those things. Unfortunately, I couldn’t entirely avoid object stacking in LOgiCATOR, especially if I wanted to show the contextual operator menus and value-entry widgets that are such a critical part of its UI.

Luckily, FileMaker 16 has a new feature to help wrest some order out the chaos of complex layouts. While it’s not perfect, the new Layout Objects window is to FileMaker 16 what Script Workspace was to 14: once you use it, it’s painful to go back. If you’ve ever used Illustrator, Photoshop, Sketch, or Omnigraffle, each of which offers some means of layer organization, the Layout Objects window will feel instantly familiar.

Not only can you select objects and change their stacking by dragging to a new position in the list, but by right-clicking on an object in the list, you can opt to hide all objects in front of it (or even hide all other objects across the layout, for true, Zen-like focus) or edit an object’s triggers or conditional formatting. Those latter two capabilities don’t require any ungrouping to act on an object inside a group. You can also filter the palette’s list either by object type, via the filter menu up top, or by object name via the Search box, helping you quickly locate objects on a complex layout.

If you sometimes find yourself stymied by objects that appear to be — but aren’t actually — inside a portal or panel control, looking them up in the Layout Objects window will quickly provide your answer. Here, however, is where you’ll start to come up against some of the feature’s “v1” limitations. You can’t actually drag an object into or out of a panel or portal once you locate it in the list. Nor can you move or resize an object inside a group without ungrouping. We’re hoping that these issues get addressed in a future version. That said, the last thing I want to do is leave the impression that Layout Objects is anything short of a huge time-saver, even in this debut iteration.

I hope I’ve whetted your appetite for exploring a few of the fantastic new features in FileMaker 16. Feel free to pick apart the LOgiCATOR demo you downloaded in Part 1, as a springboard for seeing these features in action. Next up: JSON! Until then, happy exploring.

About the Series

FileMaker’s Find mode is powerful, yet daunting to the average user. “Find” or “Omit”? “=” or “==”? “*” or “@”? Multiple requests? Extend? Constrain? Why does it have to be so hard to find the data you need?

Leveraging some great new features of FileMaker 16, LOgiCATOR is a slick, yet powerful module that can easily be integrated into a FileMaker application to present the user with a familiar and intuitive search interface like they’ve used in Mail, iTunes, and elsewhere. Best part is it’s free; we built it for the FileMaker developer and power-user community to add into their own applications. But we also built it to show off features of FileMaker 16.

In this series of articles on LOgiCATOR, we’re exploring how we used those features to build the module. Part 1 provided an introduction to the genesis and features of LOgiCATOR itself. Here in Part 2, we begin to look in depth at some new FileMaker 16 features, such as card windows, that made it possible to modularize our search interface. Part 3 will explore another essential FileMaker 16 feature used in LOgiCATOR: JSON. This is an important release for the FileMaker platform; our wish is for you to come away from our articles excited about using the new features in your own projects. In the final part, we’ll cover strategies for integrating LOgiCATOR into your own FileMaker applications and customizing it to meet your needs. (Spoiler: we’ve made it easy!)

By the way, if you enjoy LOgiCATOR, consider liking or bookmarking it in the App Innovations space at FileMaker Community. Thanks.


Thanks to the following who contributed and inspired:
Vincenzo Menanno, Beezwax Director of FileMaker Development, for prodding me to abstract a mostly hard-coded search interface I had previously developed, for suggesting we gather as much information as possible from the user’s current layout, for insisting that it have a cool name, and, most importantly, for providing me the space to work on this; Julian Nadel, Beezwax President and Founder, for supporting the effort (“Onward!”); Jay Gonzales, Beezwax Technical Project Manager, for ever-helpful guidance; Michael Cinkosky, Prinicpal, Third Street Software, for long-ago but not forgotten discussions about what makes a great search interface; fellow bee, Lon Cook, for pointing out that keeping LOgiCATOR as a separate file would make integration much easier;
…and to all beez for the daily inspiration to do excellent work.

Leave a Reply