Fun with FileMaker Button Bars: Check Please

Fun with Button Bars, The Series

In recent years, design, has become such an important aspect of what we do; luckily FileMaker has responded with a much improved design surface. With themes and styles, conditional visibility, SVG icon support, and new layout objects, we can now use design and color to communicate with users in ways not previously possible (see, for example, the “Priorities” example in the accompanying demo file).

When I first saw the button bar demoed, I was a bit underwhelmed. It’s not that it didn’t look potentially useful to have a new layout object type that keeps a group of buttons permanently joined at the hip, but that’s about all I thought it did. Once I got my hands on them, however, I discovered the nuances that make button bars far more than just a permanent grouping of individual buttons. This series will explore some surprising uses for which they’re particularly well-suited. In the end, you’ll not only see how you can improve your users’ “user experience” (UX), but, by letting your design communicate effectively, possibly even their efficiency.

So, let’s get started learning some ways button bars can provide a better user experience in your solutions.

Part 1: Check Please

Boolean fields: 1/True or 0/False the only allowed values. So fundamental are these to the relational model that Chris Date, one of the model’s founders, has called Boolean fields the only data type explicitly required by the model (1).

What’s not so simple, however, is how we handle these yes-no fields on our FileMaker layouts. If you’re like me, you’ve probably long created a special value list with only the single value “1,” placed a single-item checkbox “set” on the layout, endeavored to carefully hide the value, and lined up the label right next to it. It works, if perhaps a bit inelegantly. (FileMaker’s native checkbox-set control is really designed to display value lists for multi-valued fields; in many cases those are better handled by a one-to-many relationship anyway.)

Check Please provides a modern alternative: a simple, transferable layout object, styled just as you like, and without the limitations of Checkbox Set controls. There are no value lists required, no technique-specific custom functions to copy into your files, and only a single script.

Using a button bar offers several advantages:

• It allows you to control the exact appearance of your checkboxes; the accompanying file shows both PNG and SVG icon examples and discusses the pros and cons of each.
• It allows the full label to be clicked to toggle the state, a standard behavior users have come to expect.
• It obviates the need for a single-item “Boolean True” value list.

Basic Checking

How it works

Each “Boolean checkbox control” is actually a 2-segment button bar. “Hide object when” conditions on the individual segments ensure that only the icon for the current state is displayed. A distinctive feature of button bars, namely that when a segment is hidden, the visible segments stretch to fill the void, makes them uniquely suited to handle this job without requiring any stacking of layout objects.

The button segments each run the same script, “Toggle Boolean Value (booleanFieldName {;commit } ),” passing the name of the respective Boolean field in as a parameter (protected by the GetFieldName ( ) function, of course). Thus, a single script can be used to be used to toggle (1/True ↔︎ 0/False) any number of Boolean fields across any number of layouts or contexts.

The script’s optional commit parameter can be set to True when a record commit is required, or left blank when not.

How to implement

(See the accompanying file for examples, scripts, functions, and a sampling of copy-and-paste–ready button bars.)

1. Define your Boolean fields (e.g., Product::isDiscontinued, Task::isComplete, etc.) as number fields with an auto-enter calc GetAsBoolean ( Self ) (replaces existing value). For good measure, also add a data auto-enter value of 0 or 1, providing the appropriate default for brand new records.
2. Make sure you have the Six Fried Rice Dictionary functions [# ( ), #P ( ), #Decode ( ), #Encode ( ), #NthValue ( ), and #Value ( )] in place before importing the script. These will be used for passing parameters (2). (If you use the FileMakerStandards (3) functions instead, the variable-declaration script steps can be modified accordingly. The actual parameters passed by the button-bar segments won’t need to be changed, as both systems use the # ( “name” ; value ) format.)
3. Copy or import the script “Toggle Boolean Value (booleanFieldName {;commit } ).”
4. Copy a button bar out of “Checkboxes To Go” (see demo file) and paste onto your layouts. Double-click each segment, adjust the label, replace the icon graphic if desired, and add the script parameter # ( “booleanFieldName”; GetFieldName ( <your field name> ) ). Be sure to retain the GetFieldName ( ) function to protect against field-name changes. The script’s optional commit parameter can be added (set to “True”) or omitted, depending on your needs.
5. Set the “Hide object when” conditions. For the unchecked segment, the condition is just the name of your field; for the checked segment, it is not <your field name>.
6. That’s it. As promised, there are no value lists required and no technique-specific custom functions to copy over.

Advanced Checking

But that’s just the start! The accompanying file demonstrates a few ways Check Please can be extended to improve your designs and communicate effectively (4). The Priorities technique is a particularly good example of using design to quickly communicate information to your users. Let’s say you have 3 keys in your pocket that do different things.

When you reach in to get the key to open your mailbox, you don’t have to pull it out to find it. You can use your senses to locate the correct key. Similarly, in the Priorities example, you don’t have to look over to the right to see what the priority level is; the checkbox color tells you at a glance (5).

The Power of UX!

The sky’s the limit in terms of things you can do with this technique. If you come up with some new twists on the basics, we’d love to hear from you.

Check Please.fmp12

Note Added in Proof

As this “goes to press,” another article on creative uses of button bars emerges in the form of ISO FileMaker Magazine from Matt Petrowsky. Be sure to check out Matt’s video for some really cool techniques: more proof that button bars are so much more than a mere “group of buttons permanently joined at the hip”!

Acknowledgements

Thanks to Vince Menanno and Brian Schick for their many suggestions that helped improve this post and demo file, and particularly to Vince for the “3 keys” metaphor.

Endnotes

1. “The only required system-defined type is type boolean (the most fundamental type of all), but a real system will surely support integers, strings, etc., as built-in types as well.”  C. J. Date. The Database Relational Model: A Retrospective Review and Analysis. 2001. Addison Wesley Longman, Inc. p. 142.
2. The core set of functions is included in the accompanying file. For reference, see “FileMaker – Passing Multiple Script Parameters,” “Passing Multiple Parameters to Scripts – Advanced,” and “FileMaker Dictionary Functions.”
3. “Custom Functions » Script Parameter Interface.”
4. One caveat about implementing any of these advanced tricks: copying and pasting button bars with complex visibility calculations between files will sometimes crash FileMaker. Even editing complex visibility conditions on these objects can provoke a crash. Once you get things set up, however, these button bars should give you no further problems. Thus, for the more complex button bars shown here, I advise building them from scratch in your solution, rather than copying and pasting.
5. Don’t, however, fall into the trap of using only color, which may fail to communicate as intended for users with red-green colorblindness. Always include at least one other indicator, such as seen in the example.