Introducing LOgiCATOR: A Modular Search Interface for FileMaker 16

We’re excited to announce the release of LOgiCATOR, a new modular search interface for FileMaker. It’s designed as a module you can drop into a FileMaker application and, with minimal configuration, add a rule-based search interface to any number of layouts in that solution. LOgiCATOR is also a springboard for learning about some great new design and integration features of FileMaker 16, like card-style windows and native JSON.

Here’s an introduction to LOgiCATOR 1.0, including a brief background, overview of functionality, and first steps in implementing it in your FileMaker 16 solutions. The download link is in the section “Your Exploration Guide,” below. So, please download — we suggest you read through that section first — and have fun exploring this new search interface. We had a lot of fun creating LOgiCATOR, and hope you enjoy it.

Power Searching in FileMaker

Quick: how do you find all records dated between the 1st and 15th of any month? Did you even know you can do subrange searches on date fields in FileMaker? What about all dates on a Monday; can you search for those? How do you find all records that have a value (any value) in a given field? OK, you knew that last one, but do your users? How do you do “and” searches . . . “or” searches . . . “(First Name = “John” and Zip Code = 61610) or (Job Title = “Supervisor” and “is married”) and not Was Hired on or before 1/1/2016” searches?

Let’s face it. FileMaker’s multi-request Find mode is powerful yet daunting.

Can we possibly make that power more accessible by overlaying a more intuitive interface? That’s exactly what I set out to do several years ago. First, however, let’s look at some examples of search interfaces that inspired me to try.

Search Rule-Based Interface

In my previous life as a medical researcher, I became accustomed to search interfaces that tapped into the massive PubMed database of medical literature. While the exact details varied, the general strategy was this: you’d pick, from a menu, the field you want to search (“Author,” “Topic,” “Publication Date,” etc.), then you’d pick an operator (“is,” “begins with,” “before,” etc.), and lastly you’d fill in the value (“Pasteur,” “Antibiotic Resistance,” “2005,” etc.). You’d build up your entire search by defining successive rules just like that. You don’t have to go plumbing the medical literature to find such an interface, however; similar examples are all around us.

Consider, for example, the UI for defining a smart mailbox in Apple Mail:

Or, the next time you’re in the Mac OS Finder, type Cmd-F to bring up Spotlight’s advanced search window:

You can even set up nested searches:

Several months ago, I showed Vince Menanno, Beezwax’s Director of FileMaker Development, a search UI I had created for a personal project I had started on several years back:

The UI was clearly inspired by examples such as those above, but it was entirely hard-coded to the single table it was designed to search. When Vince tasked me with generalizing and abstracting it so it could work on any table in any FileMaker application, I just wasn’t sure that could be done. As I began working on Vince’s request, I initially envisioned a massive “set-up” table matching the fields in a database’s tables with user-facing field labels, search-rule types (date, text, popup menu, etc.), rule type-specific operator menus, etc., as well as a spider web of relationships between the search utility tables and the data tables. Vince, however, thought more abstractly. “See how much information you can gather from the user’s current layout and context, so that you don’t need that setup table. Make it ‘just work.’” That, plus “give it a cool name” became my marching orders.

FileMaker’s design functions helped me harvest field metadata from the user’s current layout, but I was still a long way from freeing myself from the web of dependencies I was looking at. Once I dove head-first into the task, however, I realized that some of the new features of FileMaker 16 were changing the way I do things along lines that just might make this work. In future blog posts, we’ll explore how card-style windows, native JSON functions, and other new-to-16 features made all the difference, but for now, suffice it to say that, as I worked on this, an additional goal emerged: make this search module a showcase for some of the FileMaker 16 features that made it all possible!

LOgiCATOR: Locate Data with Logical Precision!

LOgiCATOR is a search module you can drop into a FileMaker application and, with minimal configuration, add a rule-based search interface to any number of layouts in that application. Here’s what it looks like, running in the demo database of music CDs attached to this post:

When you open up LOgiCATOR in a macOS sheet-like card window, you start with a blank slate. From there, you add or remove rules, define the logical operator (“all of,” “any of,” or “none of”) for combining the rules within a group, and, if desired, add additional rule groups to build up more complex searches. (Shift-click to add a new rule or rule group above the current one.) Comparison operator menus respond to the type of field being searched, so that if you’re searching Artist Name, the operators include “is,” “starts with,” etc., whereas if you’re searching a number field, you’ll see “is equal to,” “is less than,” “is between,” etc. Date fields offer an especially extensive list, reflecting the extraordinary, if too obscure, flexibility that FileMaker offers within its native Find mode:

Invalid number and date ranges are highlighted:

If a searchable field is associated with a value list, the value list appears as a popup menu in LOgiCATOR, making it easier to reliably search on that field:

As soon as you have at least one valid search rule defined, the “OK” button will become undimmed, or you can execute your search by just hitting the “Return” key; hitting “Escape” will exit LOgiCATOR at any time. Extend and constrain are also supported: if you’re starting from a found set that is less than the entire table, an additional menu appears at the top of the window:

Holding down Control when opening LOgiCATOR will open your last search (similar to FileMaker’s native “Modify Last” command).

Lastly, searches can be saved and reused:

A Brief Look Under the Hood

We’ll delve much deeper in subsequent articles, but let’s get a quick overview of how LOgiCATOR works. All of the UI and most of the code sits in an external file, which greatly simplifies integration with existing data files. When you click the “Find” button in your data file, LOgiCATOR gathers information about all the fields on your current layout using FileMaker’s powerful, but oft-forgotten, Design functions. The LOgiCATOR file opens to its main search-setup layout in a new-to-16 card-style window.

You’re really still in Browse mode at this point, but on a layout tailored for defining search rules, using the field metadata gathered from the data file’s layout, along with customizations specified in the “Open LOgiCATOR” script parameter. Once you’ve defined your search and click “OK,” we gather the search rules together and pass them back into your data file as we close the LOgiCATOR window. There, we enter Find mode and parse your search rules into one or more find requests, and, lastly, issue a Perform Find command. By the way, in case you haven’t already guessed, field metadata and search rules are passed between the two files by another new-to-16 feature: JSON!

Sounds pretty straight-forward, doesn’t it? There are actually a lot of nuances to passing so much information back and forth between two separate files and making it “just work”; we’ve done the work of figuring it all out so that you don’t have to. Nonetheless, we’ll be looking at some of those nuances in the coming days and weeks, as a springboard for learning about some of the great new features of FileMaker 16. In the meantime, feel free to download and explore the demo file.

One caveat: you may be tempted to try integrating LOgiCATOR into your solutions immediately; we recommend you hold off. While this version of LOgiCATOR is mostly ready for integration, our final blog post in this series will deal specifically with integration strategies and gotchas, and will be accompanied by an updated version of LOgiCATOR that will have a few more bells and whistles aimed specifically at facilitating integration (and possibly a few more search-related features that didn’t make the cut for this first post).

Your Exploration Guide

First, make sure you have FileMaker 16 installed. Then, download and unzip the demo file here. Leave the “LOgiCATOR” file in its own folder in the same location relative to the data file (“CD Database”), otherwise the internal file references will not be valid. (We’ll discuss those file references and how to move things around in the article on integration.)

You’ll do all your exploring, at least initially, from the “CD Database.fmp12” file, so open that file and click anywhere in the splash screen. There are only two user-facing data tables in this file, Albums and Tracks. Click the “Find” button above the master portal to open the LOgiCATOR window. Try setting up various searches and see what results come up. Be sure to explore multiple rule-group searches (“Add Rule Group”) to set up more complex queries. There are a couple saved searches; try running one of those, and also saving your own search for posterity.

When you’ve explored the UI and want to look under the hood, a good place to start is with the Find buttons on the two layouts and their script parameters. You’ll immediately notice that the Find button on the Albums layout is highly customized, via its script parameter, so as to provide the most polished experience. (The script parameter? JSON, of course!)

The Find button on the Tracks layout, on the other hand, has no parameter-based customizations. Still, it is able to parse the layout itself for enough information to provide a basic search capability. I hope you’re as amazed as I was at how much information the layout provides, if you know how to look for it. (You’ll learn later how our field naming convention helped in this regard, but even if you name your fields differently, you’ll be able to easily customize the user-facing names via the script parameter.)

The next place to explore would be the two LOgiCATOR-related scripts in the “CD Database” file; they are the only scripts needed in the data file. One kicks things off, gathering up metadata from the layout and melding it with customizations, if any, in the script parameter, before calling a subscript in the LOgiCATOR file and passing it that metadata (JSON again). The other one is, in turn, called by the Perform Find script in the LOgiCATOR file; it receives the rule information (wouldn’t you know . . . more JSON) and parses it into FileMaker Find requests.

After exploring those scripts, open the LOgiCATOR window again by clicking the Find button, and change the menu set to Standard FileMaker menus. Open LOgiCATOR’s Script Workspace and explore the various scripts in that file.

Probably the last place to explore would be to open the LOgiCATOR file directly and pick apart the layered objects in the “LOgiCATOR UI” layout, with the aid of the new Layout Objects panel. Don’t try and actually run any searches from that file, as it won’t know which table in your data file to search in. For the end user, LOgiCATOR really is designed to be opened entirely from within the data file.

Happy exploring!

About the Series

In this series of articles on LOgiCATOR, we explore how we’re leveraging new FileMaker 16 features to give FileMaker’s complex Find mode the user-friendly face it’s always pined for. Future articles will explore some of those new features in depth, starting with Part 2 on “FileMaker 16 Card Windows and Modular Design.” 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. Finally, we’ll look at how you can incorporate LOgiCATOR into your own FileMaker applications and customize it to fit your needs with relatively little effort.

Acknowledgements

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.

References

While LOgiCATOR is all about taking advantage of FileMaker’s powerful Find mode, usually with the goal of precision-tuning the found set of records you are working with, there are other approaches to finding data that may be more applicable to some use cases. Nowadays, some might say it’s Google’s world and we just live in it, at least when it comes to finding information on the World Wide Web. Certainly, the simplicity of just typing a term you’re interested in into a field and hitting Return has an allure and power all its own. When your goal is to quickly find a particular record among a few potential hits, rather than fine-tune your found set, that is the way to go.

FileMaker offers Quick Find, but others have taken that approach to a whole new level. Although no longer available, Matt Navarre’s incredible “fmSearchResults” let you search just that way and then organized the results for viewing. More recently, Daniel Wood added plenty of spit and polish to an interface for a Google-like search technique in FileMaker. Be sure to check both of those out. No single tool fits all use cases, so the more options in our toolbox, the more likely we are to always have the right one at hand.

License

Copyright © 2017, Mark Scott at Beezwax

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The “About LOgiCATOR” window and layout, unmodified or minimally modified only to re-style buttons, including original credits and this unmodified copyright notice and license, shall be included in all copies or substantial portions of the Software, and shall be accessible to end users from the main LOgiCATOR search-entry view via a menu command labeled “About LOgiCATOR” and/or a button on the layout labeled “About.”

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The LOgiCATOR name, “Locate data with logical precision!” tag line, and reading-magnifier logo are trademarks of Beezwax.

Beezwax is available on a consulting basis to help integrate LOgiCATOR into your FileMaker application. Find us at www.beezwax.net.

2 thoughts on “Introducing LOgiCATOR: A Modular Search Interface for FileMaker 16

    1. Hello,

      Glad you like LOgiCATOR! Since LOgiCATOR uses FileMaker’s native Find mode to perform the search and then presents its results as a traditional found set, global searching across multiple tables would be a rather different paradigm. If you decide to tackle it, you’ll have to think about how to scrape multiple layouts for the list of fields to search (or otherwise develop that list) and then how to present results that span multiple found sets. We’d love to hear what you come up with!

      For a different approach, have you seen Matt Navarre’s fmSearchResults? I’m not sure whether it’s still available, but it might be closer to what you’re looking for.

      Have fun exploring.

      Mark

Leave a Reply