One of FileMaker 17’s most exciting new features is the ability to configure portals to display records from the current table. This allows us to easily create master-detail layouts.
What Is Master-Detail?
Master-detail is a very common and powerful UI design pattern. The basic idea is that a single screen or interface displays both a master list of items as well as the details for the currently selected item. While it is most common to see the master list at left and the selected detail at right, the two sections can also be arranged vertically or even stacked. Master-detail interfaces are used for all sorts of applications and functions: email and calendaring applications, media players, file browsers—the list goes on.
Past Trouble with Master-Detail in FileMaker
While master-detail is a well-established and familiar design pattern, it has historically been hard to construct in FileMaker. To start with, we can only configure a layout for list view or detail view, but not both. And while we’ve been able to use portals to display a list of records in a detail view layout, portals could only display records from a related table occurrence.
For example, say we want to build a screen that displays a list of contacts on the left side and the detail for a selected contact on the right side. We would typically approach this by creating a detail view layout based on our Contacts table and then adding a portal on the left to display our master list of Contact records. However, since portals could only display records from a related table, we had to create a separate table occurrence as well as a relationship to it, and then base the portal on that TO. This could be done using a self-join, a virtual list, or some other technique; but in all cases, additional development was required to handle navigation to the selected record in the portal as well as to keep the portal in sync with the found set and sort order of the current table. Lots of folks in the FileMaker developer community have gone to considerable effort to create elegant solutions for the master-detail design pattern, though with that came lots of extra code to maintain.
Native Master-Detail in FileMaker 17
All that trouble has been eliminated for us in FileMaker 17. We now have the ability to have portals display records from the current table:
Note that when Current Table is selected in the portal setup dialog, the options for Sort and Filter are grayed out. That’s because this new type of portal comes with its own special behavior. The portal sort order automatically matches the sort order of the current found set, and the records displayed in the portal also automatically match the list of records in the current found set. Essentially, the current found set is the portal filter. An additional new behavior we get with this portal configuration is that simply clicking on a portal row will make that the current record, with no button setup or scripting required. So, we get a simplified relationship graph, sorting, filtering/searching, and navigation, all for free. Pretty powerful stuff!
Designing for Master-Detail
Since it’s now so much easier to build master-detail interfaces in FileMaker 17, we can spend less of our development time on the nuts and bolts of the basic design pattern and more of it on additional features to deliver more value to our users.
In the below example, I added selectors for sorting and filtering directly above the portal to mimic the kind of options commonly found in an email client. The pop-up menu fields have OnObjectModify script triggers that perform customized sort and find scripts. Because the portal automatically reflects the current found set and sort order, there’s nothing else to it!
There is a new function in FileMaker 17 that we can use in conjunction with master-detail portals: Get (ActiveRecordNumber), which returns the number of the active record, regardless of the calculation context. This differs from Get (RecordNumber), which returns the record number within the context of the calculation; this may or may not be the active record.
This is illustrated below. I’ve added a button to the portal row which sends an email to the selected record. I only want the button to appear on the selected portal row, so I have a hide condition set on the button for Get (RecordNumber) ≠ Get (ActiveRecordNumber). This works because Get (RecordNumber) returns each record’s sequential record number in the found set (e.g. row 1 = 1, row 2 = 2, etc.), but Get (ActiveRecordNumber) returns the number of the active record, regardless of the row the calculation is being evaluated on (e.g. if the active record number is 5, row 1 = 5, row 2 = 5, etc.).
Note that Get (ActiveRecordNumber) can be used similarly with a list view layout.
Designing for Mobile
Master-detail interfaces are just as common on mobile devices as they are for desktop and web-based applications. The smaller amount of screen real estate just means that the relative arrangement of the master list and detail sections might be a little different. On an iPhone, for example, they might be stacked such that you only see one section at a time, with the other section revealed on demand.
Here is a different version of the above example that’s been redesigned for FileMaker Go on the iPhone. Instead of having the master and detail sections side by side, I have them in different slide control panels. The master portal is in the first panel; I then have a transparent button in the portal row that simply switches to the second panel which displays the detail section. Because tapping on the portal row natively makes that the current record, no additional code for the navigation action is necessary. Once in the detail view, the user can swipe left to return to the master list.
I thought it would be interesting to see how master-detail portals perform with large tables or over a slow network connection. Would there be a noticeable delay in the portal refreshing to reflect a new found set or sort order? How about scrolling the portal or selecting a record? To test this, I set up a file with tables containing 1k, 10k, and 100k records, hosted it on FileMaker Server, and opened it over a WAN connection.
I found that while the basic searching and sorting actions performed as expected—slower with larger record sets—I didn’t notice any additional slowness for the portal to refresh. However, I did start experiencing a slight lag in response with scrolling and selecting in the portal with a sorted found set of 10k records. This behavior became much more pronounced at 100k sorted records. Interestingly, there was no lag in either case with an unsorted found set, so sorting appears to be the culprit.
It’s worth noting here that if you have a table with 10k or more records, the master-detail design pattern may not be a good idea in the first place (more on that below). But for tables containing up to several thousand records, performance is a non-issue.
When It’s Not a Good Fit
As we saw above, when we configure portals to display records from the current table, we don’t get the options to sort or filter the portal records. In addition, allow deletion of portal records is required, allow vertical scrolling is required, and the initial row number is locked at 1. These “locked” settings make sense as they naturally reflect what we would expect for a master-detail design pattern. That said, if you have a situation where you want to have a master list that doesn’t reflect the current found set—for example, you want to limit the total number of records displayed in the portal, or you want to have additional filtering applied—you would need to use other, pre-v17 techniques for configuring your portal and handling the associated functionality.
More generally, the master-detail design pattern becomes less of a good fit for tables containing more than a thousand records (and some would argue much less than that). While it can be fun to do as a developer for testing purposes, a user is never going to want to scroll through thousands of records in a portal. If that’s your situation, you’ll better serve your users by exploring other design patterns.
We’re excited about the new master-detail portal feature and feel like it opens up new possibilities for FileMaker interface design. It will be fun seeing how the FileMaker developer community begins using this feature in the months ahead.
Stu Dietz is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.
About Skeleton Key
Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business.
In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.