Overview
This technique uses filterable portals contained in FileMaker 13’s new Popover object to provide user-friendly pop-up menu behavior.
Download
1. Each pop-up menu field is non-enterable, and overlaid with a popover button.
2. The popover button is included in the layout’s tab order; the underlying field is not.
3. Each popover contains a filterable portal of related records.
4. The user may use mouse or keyboard commands to select a list value.
5. Selecting a list value sets the corresponding pop-up field to that value.
The same could be accomplished in FileMaker 12 using pop-up windows with a filterable portal, but popovers are better integrated into the layout for an improved user experience. The strength of this technique is to allow a user to open a menu, find an item, and select that item, all without moving their hands from the keyboard.
(I’m considering only keyboard navigation on a desktop computer. FMGo’s pop-up menus present a different set of advantages and challenges. In theory the behavior should be the same on WebDirect, however there is currently a bug by which the button on the portal row does not return the correct value.)
Opening the Menu
Fields with pop-up menus can be included in a layout’s tab order, but when a user tabs to the field, there is no keyboard command that will open the pop-up menu, and neither is there a way to do this programmatically. The user must employ their mouse or trackpad to disclose the menu.
In contrast, popover buttons are activated by a Space or Enter keystroke. By overlaying a non-enterable pop-up menu with an enterable popover button, the technique allows a user to tab to the object then open it in stride with Space/Enter.
Popover buttons and the resulting popover objects each have their own panel of OnObject script triggers, providing a great deal of flexibility for pre- and post-events. I might want the popover to open automatically when the user tabs to the field (not demonstrated here, but it’s possible by going to a unique field or object name on the corresponding popover object), or insert the user’s cursor in the filter field once the popover is open (as this demo does).
Closing the Menu
Hitting the Escape key closes a pop-up menu. In this demo, Escape clears the filter if it has a value, and closes the popover if the filter is empty. While the filter is empty, Space and Enter also close the popover, allowing the user to quickly open and close a popover using the same key.
Clicking outside the popover natively closes it. In this demo, an OnObjectExit script trigger cleans up after itself, clearing the filter and any instantiated name-spaced global variables.
Protecting the Data
Pop-up menus offer a few hidden ‘features’ that allow a user to circumvent the value list. With the pop-up menu field selected, the user may hit their Delete key (or shift+select the current value) to clear the value. Permitting a null value is often a requirement, but this isn’t the obvious way to empower a user to achieve it. Preventing a null value requires a script trigger and/or field validation.
With the pop-up menu field selected, a user may paste their clipboard into the field. In almost all cases this is undesirable behavior, polluting the field with unsanctioned values. Again, script triggers and/or field validations are required to prevent the behavior.
The popover technique disallows direct access to the field, sidestepping both issues and forcing the user to select a pre-approved value. (A separate ‘clear’ button would allow the field to be cleared.)
Displaying Values
Dynamic value lists (aka ‘Use values from field:’) provide pop-up menus a single-purpose, one-dimensional list of unique values from an indexible field, and with available values only as dynamic as the underlying relationship allows. Let’s unpack that.
1. Single-purpose. The only method by which a user may interact with a value in the list is to select it. Sometimes a picker list needs more than that. In contrast, a popover’s portal supports nearly the full range of layout object behavior, including adding/deleting values, and interacting with existing values to get more information (e.g., via tooltips or buttons).
2. One-dimensional. Value lists display exactly one field in a single column. If I want to display multiple fields, I must build a concatenating display field. Even then the secondary field data will smash up against the primary field data, rather than aligning into its own column. By using a portal, the popover technique may add additional display fields, and segregate them into their own columns. Judicious use of conditional formatting and tooltips can add non-columnar information to the list as well.
3. Unique. Dynamic value lists ignore duplicate values. If two underlying records share the same value, the value list will only display the first of these. This behavior is fine if the value list is using only a single field, but if the display field differs from the field whose value is actually inserted by the value list, the user might think they are selecting Person B, but actually end up inserting the ID for Person A (whose name matches that of Person B). The popover’s portal allows us to show duplicate values. By adding additional columns, tooltips, and other information we empower the user to distinguish between two similar entries.
4. Indexible. A dynamic value list won’t display values from an unindexible field. In most cases, and especially for performance reasons, that’s fine. But occasionally I want to display an unstored calculation, or even container fields (e.g., helpful icons).
5. Limited dynamism. A dynamic value list that shows all values from a table has an advantage over the popover’s portal in that no relationship is required. For any value list that should show only a subset of the data, however, using a portal filter can be much more effective at constraining the data (see Filtering the List, below). Portal filters can filter on unstored calculations and use ExecuteSQL, and two filtered portals can share the same generic relationship, whereas each unique value list must either have its own relationship, or share a join with flexible logic built in.
Both techniques rely on a sort field built into the relationship. The popover technique has the added advantage that the sort field and the display field need not be the same. This is useful when I want the data to appear in non-alphabetical order. In the movie example, the portal is sorted by a shadow field smart enough to ignore some common articles, such that “The Lord of the Rings” is sorted under ‘L’, whereas a value list would slot it under ‘T’.
Filtering the List
Pop-up menus support typeahead, advancing the menu as the user types. For long lists, the user might need to type a long string before advancing to their target value, or move their hand to the arrow keys to manually advance the list. (Option+up/down advances to the first/last value in the list; Command+up/down pages through the list). The popover technique assumes it is better to constrain a list than to traverse it. Portal filters aren’t new to FileMaker 13, so I’ll just quickly reiterate that they can incorporate compound searches (ANDs and ORs), ranges, multiple fields, calculations, ExecuteSQL, searching on hidden fields and just about any other technique that would help a user isolate a desired value.
Another strike against typeahead is that it only looks for a character match against the beginning of the display field. A filtered portal will search whichever field I want, and by whichever method I choose. This demo uses Position, which my colleague Donovan has shown is much faster than than PatternCount when I only care if the string appears at least once (e.g., filtering for ‘light’ will yield ‘Twilight’).
The popover technique tries to emulate the pop-up menu’s native keyboard commands. Up/down highlights the previous/next value, with added intelligence to wrap around from the top of the list to the bottom, and vice versa. Even better, tabbing and shift+tabbing selects the next/previous value, without having to remove my hands from the home position. Option+up/down highlights the first/last value in the filtered list. This demo doesn’t support paging, and neither is it smart enough to bring a selected row into view (e.g., if the user advances to the last value in the list), but both could be rigged up. (At a recent DIGFM at FileMaker Inc., Matt Navarre stressed that Google is training our users to refine their search until the desired result appears on the first page.)
Selecting a Value
Similar to the pop-up menu behavior, the user may click the desired value, or, with the value already highlighted, hit the Enter key. If you’re willing to maintain a list of object names and a static tab order, you could even extend it to support something like shift+Enter to not only select the value, but then immediately open the next popover in the tab order.
Performance
This demo tests portals displaying 100, 1400, and 3000 records, all with snappy results, even when connecting to a remote hosted file via wifi.
Value Lists become sluggish with 10,000 records, and FileMaker crashes at 100,000 records.
Similar to value lists, at 10,000 records the popover’s portal becomes sluggish. At 100,000 and 1,000,000 records FileMaker crashes. So neither method solves the problem of picking a value from a massive data set. For anything more than 10,000 records, the better technique would be to leverage a Find.
Gotchas
The concept of “previous/next” in a list is tricky. The portal is filtered using FileMaker’s Position function, and sorted using a relationship. When I determine ‘previous’ or ‘next’ for purposes of highlighting a value, I use SQL’s LIKE function, sorted by ORDER BY. It’s conceivable that the two different methods could disagree about which records to return, and in which order to sort them, causing unexpected behavior when tabbing/arrowing through the list. So far, though, they seem to be in agreement.
It’s visually confusing when I reverse navigate to the last item in the list but the list doesn’t advance to show my selected value. With some extra work, a developer could approximate advancing the portal row.
Pop-up menus support paging. It would be extra work to support paging in a portal. But again, it might be better to just train the user to rely more on the filtering, and less on traversing the list.
Value lists and pop-up menus will typically behave as expected in Find Mode. The popover’s filtered portal does not support searches in Find Mode.