Consider the humble button.
Since the very first moments of FileMaker cosmos, the button has been an essential element of our platform. Over the years, across major and minor product releases, the unassuming button has remained a trusted constant and a dependable workhorse.
In daily practice, the button is as essential and transparent to our solutions as water to a fish. (As an interesting conceptual challenge, try envisioning a button-free solution). And yet, the button’s heroics on our behalf go overlooked and unsung. We lavish design and development attention on fields, portals, tab controls, web viewers – virtually every interface element except the unassuming button.
In this series, we’ll offer our old friend some long overdue attention. We’ll demonstrate several new techniques available in FileMaker 12 to greatly enhance its appearance, behavior, and meaningfulness. The button’s simplicity will help us isolate and demonstrate several modern UI and UX concepts, which we’ll then be able to apply not only to buttons, but throughout our interfaces.
It’s Alive!
So why does the button get so little attention? Perhaps its utter simplicity infers that it’s just too trivial for our consideration. Maybe since we FileMaker developers are data developers, the unassuming button flies beneath our data-driven radar. Or perhaps we carry impressions and practices from the earlier history of our platform, when the button was limited to being a visually passive, static object in a world where users increasingly were expecting real time interaction.
But the times, they’ve been a-changin’. As we know, the release of FileMaker 12 has brought a quiet revolution to the platform’s interface structure and capabilities. The new CSS-driven Design Surface introduced what I’ll term “interactive formatting“, enabling objects to visually interact with users in real time. This behavior comes for free with every modern CSS-based theme in FileMaker 12, and can, of course, be readily tuned and extended to add further expressive depth and nuance.
No element in the FileMaker universe experienced a more profound upgrade in FileMaker 12 than the button, which was suddenly transformed into a visually active – and interactive – element. Its new ability to give users direct visual feedback as they hovered, tapped, and clicked, gave the button greatly expanded powers of expression. The invigorated button could now communicate information much more directly and succinctly. In response, buttons everywhere rolled over and popped up in celebration. Huzzah!
Of Mice and Semantics
The visual impact of Design Surface has been immediate and extremely positive. FileMaker 12 interfaces feel zippier, more modern, and more intuitive: In a word, users love them.
But there’s more happening here than just good looks. FileMaker 12’s interactive formatting lets us create interfaces that are more semantically meaningful. When objects – and especially buttons – respond interactively to user actions, they communicate who they are and what they will do for the user if clicked. We used to achieve this with tooltips, static explanatory text (“click this button if you want to do that…”), and changing the cursor from a pointer to a hand. Now, interactive formatting can handle this for us, much more succinctly and far more gracefully.
This has a profound impact: When a FileMaker 12 button changes appearance in direct response to a user’s hovers, clicks, or taps, it’s telling to the user that it’s an active, “living” object ready to perform an action on her behalf. Even more: As it interacts visually with the user, this button offers a tacit agreement: “Click or tap me, and I’ll perform the action promised by my label or icon.”
As modern UI and UX theory informs us, interfaces that more directly communicate their purpose and function to users are more intuitive, require less training and support, and provide far greater user trust and satisfaction. While the updated button’s good looks may be what first catches our eye, as developers and designers, the more subtle goal of honing and enhancing its semantic meaning is fully worthy of our ongoing attention and best efforts.
Clearly State Your Intentions
Out of the box, Design Surface does everything it can to help our buttons communicate their purpose to users clearly and accurately. But of course, there’s a catch. (There’s always a catch). In many cases, we developers will need to extend FileMaker 12’s default button formatting to preserve our buttons’ semantic meaningfulness and integrity.
Buttons often need to alter their behavior as our solution’s data changes. For example, a button to update a record’s status might depend on our data having met certain milestones; A delete button may be available only for draft records, for users of an administrative privilege set, or as users hover over a portal line item; Or a browser-style search field may have a clear button only having meaning when search text is present.
State-dependent buttons like these will at times be active and available for users to click, and at others be disabled and unavailable for their use. Because the rules of when state-dependent buttons will and won’t be available are dependent on solution-specific business rules, we can’t expect FileMaker – or any platform – to handle this automatically. Instead, it’s our challenge to ensure that state-dependent buttons accurately communicate their availability in real time, as live conditions change.
Keeping the Faith
Remember a moment ago, when our buttons’s interactive formatting made a tacit agreement with users?
What happens as our state-dependent button becomes functionally inactive? If it continues to respond interactively to hovers, taps, and clicks – as it will do out of the box – our user will likely click it once again, still expecting the promised result. But this time, our button will break its agreement, failing to deliver as advertised.
The result is semantic misinformation. Our state-dependent button’s interactive formatting is now misaligned with its functional behavior. To correct this, we might display an alert, (“You can’t perform this action now”). The problem is, while this is true, it’s no more satisfying than walking into a store displaying a prominent “Open” sign, only to be told, “Welcome. We’re closed; please leave.” Or perhaps our button will simply exit silently, leaving the user to wonder why the formerly trustworthy button has stopped working without an explanation. Again, this will be unsatisfactory to our user.
Semantic misinformation is jarring, confusing, and degrades trust. At best, users will construct an internal matrix of rules telling them when to ignore the visual cues our buttons are giving, (“Don’t click the submit button unless you’ve entered something in this and that field…”). Even in this best case, daily use and new user training are much more difficult, as users must manually learn and convey rote rules that can’t be inferred from the interface. At worst, users will lose trust, potentially avoiding our solutions, or viewing them as unreliable.
Happily, once we’ve recognized this issue, it’s easy to ensure that state-dependent objects always remain semantically meaningful, even as our data changes. And the simple steps we’ll take to implement this will improve both our solutions and users’ experience and confidence in using them.
Same Bat Time, Same Bat Channel…
Up next: We’ll describe – and provide working examples – of two lightweight methods to implement dynamic, state-based formatting: The first, a time-honored conditional formatting standby that’s still useful in many situations; The second, a new, nimble FileMaker 12-specific technique that takes full advantage of Design Surface’s advanced capabilities. Stay tuned…
Thoughts? Questions? Have a different point of view? Leave a comment and let me know – I look forward to your feedback.
- Brian
2 thoughts on “Button. Up.”