There’s a new hero in the world of web applications, services, and microservices: Server-Side Swift is making serious waves across the industry. At Beezwax, it’s changing how we approach and solve many typical, long-standing coding challenges.
Our previous post highlighted the new capabilities of the venerable FileMaker button. In FileMaker 12’s Design Surface, the once-humble button gains new-found expressive power, enabling it to respond fluidly to user hovers, taps, and clicks via what we termed interactive formatting. The catch: interactive buttons — whether in FileMaker 12, or on any other platform — are prone to semantic misinformation, in which interactive formatting unintentionally misleads and confuses users.
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.
Here’s an interesting FileMaker challenge:
How can you dynamically slice off a set of values from a repeating field in a related table, the way you’d grab a column of values in a spreadsheet?
It’s easy enough to do this for a single repeating field in the current record, but how do you do this with a repeating field in a different table, operating not just on a single record, but an entire record set?
It’s hard to believe it’s been only a few months since SQL was introduced as part of FileMaker 12.
You gotta love FileMaker Go. Go’s ability to effortlessly create data-driven mobile apps and extend existing desktop data applications to mobile users is transformative. But sooner or later, almost all of us run up against one of Go’s core limitations: its lack of native plugins.
One of the most exciting aspects of the newly-released FileMaker 12 product line upgrade is a major redesign to the product’s UI. A new Design Surface modernizes FileMaker Pro layouts and updates every built-in control, giving developers and designers powerful new tools for designing better interfaces.
But as great as Design Surface is, why just stay on the surface?
Here’s an interesting interface challenge we recently faced: A client needed to place text fields on a layout and fluidly choose which fields would be editable or read-only—the same field might exist in both editable and read-only state on the same layout.
Now, here’s the challenging bit: Each read-only field must have all the same capabilities of its editable cousins—users must be able to scroll, select, and copy text, and the field control must display all rich text formatting entered.
One of the most valuable aspects of 2011’s FileMaker Developers Conference in San Diego was a far-reaching discussion about the role of design in the FileMaker world. Design wasn’t the official theme of this year’s conference; but it was certainly among the most popular topics. A large number of sessions focused exclusively on design issues: