Design Think Your Code

Have you ever opened an existing solution, took one look at the source code – and your eyes just glazed over – as if you were attempting to decipher the Matrix?

You’ve entered the world of DX, or “Developer Experience”.

Just as User Experience (UX) refers to the experience of users, Developer Experience (DX) focuses on the experience that Developers have within the code of your system. This applies whether that’s code you inherited, code you passed on to someone, or code you originally wrote — all situations which affect a person I would call ‘Developer Next’. This could certainly be your-good-self, in six months time.

Developer Experience (DX) In Claris FileMaker

The Claris® FileMaker® Platform provides Developers with a rich toolkit for coding functions and features to craft mature app solutions. As we build these solutions for users, we care deeply about UX, while developing new design concepts through Design Thinking, then carefully applying Design Patterns to solve common problems that affect those users.

But we should also consider self-care, and how thinking and patterns might improve our own quality of life, as Developers.

As a function of Design Thinking, please consider applying the following Design Patterns to your next solution, with the audience beyond the UX, to also include the DX.

Here’s an example of improving a DX interaction with a few lines of Code:

Option+Click Card Window Scripts

This simple DX ‘design pattern’ came to me recently – while away from the computer – and has saved much time for our team on many projects.

Friction Point: Card Windows do not allow the Developer to switch to Layout mode.

Time is consumed on the need to open a new window, or open and find the Layout via Manage Layouts – across multiple days of development – can be extensive, indeed.

Solution: Set up an ‘if’ statement within your script to open a Card Window, where if the User has [Full Access] and the Option key is pressed, open a Document Window instead of a Card Window.

Design Patterns

Design patterns can be divided into three fundamental groups:

Creational patterns are used to create objects for a suitable class that serves as a solution for a problem.
Behavioral patterns describe interactions between objects and focus on how objects communicate with each other.
Structural patterns form larger structures from individual parts, generally of different classes.

Let’s dive deeper into these Design Patterns, group by group, and pattern by pattern:

Creational (Code) Design Patterns

Developer Friendly Code.

This is more an ‘overview’ of the concepts mentioned here, although sometimes forgotten, it’s not exactly front of mind when crafting the code for the next function.

Also referred to as ‘write clean code‘ – and I can highly recommend Uncle Bob’s 8 hours of presentations. They’re well worth your time, consideration and application in your daily code.

Zero Code Errors.

Firstly – you may ask ‘what exactly is an error in code?’ Let’s restrict this conversation and concept to any error reported within the Database Design Report (DDR) export from the FileMaker Solution. If you’re not currently running your solution through a DDR analysis tool (you should invest in one — check out Inspector Pro, for example), I’ll wait here while you do.

Running a DDR at the start of your Coding Day, then at the end of the session, will show you the errors you have created on that day – and help you build the habit to remove these before leaving the computer.

Attempting to remove these errors in six months, or have an other Developer remove the errors, leaves us open to interpretation on how to remove or fix the error.

Let’s use a simple Go To Layout <layout missing> error.

What change needs to happen for the code to perform ‘correctly’?

remove the script step, as the script currently performs as expected, OR…
re-set the defined layout to an existing layout, OR…
the layout has been deleted, and needs to be re-created

Any one of the above options could be the correct answer – there’s just no way of knowing.

Human Friendly Variable Names.

This concept can be applied to not just Variable Names, but also basically every Object element in your solution.

I can’t be the first developer to open up an existing solution and wonder if I needed a degree in applied algebra or trigonometry to understand the code.

Attempt to stay away from using terms that may change over time, such as the Company Name, or descriptors that can change over time. As the Developer, there’s not much you can do if the name of an entity changes from Location to Depot to Office to Workshop over a period of time.

Keeping the logic consistent and human friendly can go along way to reducing the cognitive load of your code for the next Developer – and again, this can be you, in six months time.

That’s not to say you cannot apply some best practices when it comes to naming conventions. And no, I am not talking about prefixing field names with a Z if I think I may not be using them in code.

As an example of this exception, my preference is to use $i and $j as the counters for looping.
This technique is clean and simple, and allows loops to exit when $i > $j.

Exercise: Open one of your more complicated scripts, and with your ‘Developer Next’ hat on, scroll half way down the script, and see if you can ‘decipher’ the data behind the Variable, based on only the name of the Variable, followed by the context of the use of the Variable.

Name Your Layout Objects.

With the introduction of FileMaker 16, we were gifted the objects Inspector.

Just as we craft a filtered portal for our Users when the data is beyond the ‘baker’s dozen’, Claris has allowed us the ability to filter the Objects Portal to locate the field or object we are looking for.

Let’s not forget to we can turn off items in Layout Mode, to allow us to drill down the layers of objects on our Layout. There are many options to interact with the Objects via the Objects Inspector.

Object Themes and Styles.

Many ‘Under The Hood’ sessions and blogs have explained the rendering performance of applying styles to your object layouts. There is also a huge benefit of being able to apply ‘one’ style change, and have it cascade through each and every object on each and every layout.

Exercise: For your next project, start with designing a Theme for all your objects. Start by researching the options available. This may be one of the existing themes within the sample files, one released by one of the Claris Partners, or even one you build yourself. This is well worth the initial effort.

Script Comments as Script Headers.

The one true piece of useful ‘meta-data’ about the script – which can live in the Script Header Comments – is the expected structure of the Script Parameters being passed into the script.

In this day and age of JSON Script Parameters, being able to simply copy and paste is a huge time saver, rather than fishing through the buttons (or parent scripts) to find the syntax.

Script Comments as Section Breakers.

As described at the beginning of this post, the ‘cognitive load’ of your logic applied to your scripts have greatly reduce the next Developer’s ability to understand your code.

From a UX Design Pattern perspective, this is not that different to writing a long-winded error dialog – which we know the User doesn’t generally read, anyhow.

Example: Put simply, if you need a number of paragraphs to explain the complexity of the script, then you may wish to look at simplifying the script itself.

Exercise: Rather than create the Comment Header, apply your Comments more as a Function breaker. Create a ‘section’ for the Variable collection, a section for the Error Capturing, and preface each main section with a Comment Marker.

In practice, this allows the reader of the script to scan through each section, without the need to understand the script logic, expected result or to find the change in logic.

Behavioral (Code Execution) Patterns

Economical Troubleshooting.

The initial thought pattern is that the script in question will only need troubleshooting while the Developer is writing the initial code. This falls into the category that ‘you are not the user’ – which in real life is hardly the case.

Exercise: While writing the next script, perform a mock troubleshooting session, with the environment being either Live or Test, and time your ability to complete the session.

Economical Execution.

No ‘User’ wants to press a button and wait for ‘X’ minutes for the outcome to appear on their screen. As well, no ‘Developer’ wants to wait for ‘X’ minutes to run the script while creating, troubleshooting or updating said script.

That said, loading data into variables which are declared at the start of each script is a good starting practice, to begin moving this data into memory, the fastest option for accessing data. This also allows the same data point to be loaded once, not every time it is called.

This method can also be applied to configuring Let statements inside complicated Calculations. This not only aids the speed of the calculation loading, but also the Developer’s ability to read, update or troubleshoot the Calculation.

Exercise: Create a timer function for your next script, and while in the Design phase of your code, experiment with different methods. You may be surprised with the throughput of one method over an other – or you may find one method is only milliseconds slower than another, while providing various benefits to the next Developer.

Successful Completion.

At first glance, this one seems to be a no-brainer. Before we write the first line of our script, does this script need to reach the last line, to be defined as successfully executed?

Would the ‘Developer Next’ understand this expectation – on updating or troubleshooting this script – even if that Developer is you, in six months time?

One of the most underutilized script steps is the Exit Script [ Text Result ] script step.

Let’s be very clear on the difference between Exit Script vs. Halt Script. The Halt Script step is akin to taking the keys out of the ignition of your car to slow it down, rather than using the brakes. I do apply a Commit and then Halt ‘utility’ script for overriding the tab order for fields on the layout, as part of the UI.

Example: There is nothing more frustrating that troubleshooting a script, where an ‘if’ statement returns a condition as part of the error checking, only to find that the script continues on to the bulk of the code, where the context ‘fails’ further ‘if’ statements. And, as the Developer, you are left clicking through seemingly never-ending script steps in the Script Debugger.

Exercise: Investigate the use of the Exit Script, returning a text result in a more ‘complicated’ script, and make a considered decision to exit at that point, each time a new script is written.

Error Checking and Capturing.

This concept goes beyond when the User doesn’t do what the Developer is expecting, to an environmental change that can render the outcome of the script unexpected or even destructive.

Displaying a Custom Dialogue via the script step – with the error code, or even in the language of the User – doesn’t really give the best experience of the code.

Example: I apply an email notification script to solutions when an ‘Unknown’ User authenticates against the ‘Test’ Version of any system. This script presents a Custom Dialog to the ‘Unknown’ User that they have opened the ‘Test’ Version. Then, they have the option of Exiting or Continuing – and this result is emailed to the Support Staff.

Exercise: Create an Error Log table, which logs the details surrounding the User’s situation in creating this error. Include the option to notify Support staff of this error, either via email, Slack or SMS, depending on the workflow required for this error.

User Logging and Notification.

This concept is the lesser known cousin of the Error Log table. Just as we’d like to know when something goes wrong, it’s also helpful to know when, and how often, it goes right.

This is particularly helpful when introducing new functions to solutions, to:

report on which users are using these new functions
gauge when to provide feedback to Project Managers if further User Training is required
identify if the feature does not fit Users’ needs
understand if the feature was in fact added without full support from the Users

Exercise: Create a User Log table for the next major new feature you add to your solution. Allow a number of days or week of use to create a set of Log data of the Users. Create a chart or basic report for the Project Manager, outlining the ROI of the current feature.

Structural (Environment) Design Patterns

Industry Standards.

Following ‘Industry Standards’ covers a wide range of concepts and ideas. This context includes applying industry standards and embracing uniform formats for exchanging data, such as REST, JSON and even External Authentication.

Applying Industry Standards not only enhances the experience as a Claris FileMaker Developer(s), the benefits can extend out to the Developers of ‘other’ platforms and affect how data is shared.

When asked if FileMaker ‘shares’ data, we can simply answer that FileMaker Server has a RESTful Data API – and you can even provide a set of Postman Collections. You’ll see huge smiles on other Developers’ faces, and all is good.

Developing Live on Production Servers (Not).

With the introduction of the FileMaker Data Migration Tool (DMT) – there’s no need to do ‘native’ imports to move data from LIVE to the UAT version – and therefore the update process is much faster, safer, etc.

I know this sounds like a long bow to justify a blocker in working LIVE on a Production Server. Just remember, there was a time when various Developers were promoting ‘best practices for Developing Code on a Production Server’ – which personally I believe is similar to discussion the best practices for driving at night without headlights.

Bottom line, don’t put yourself (or the next Developer) under that level of stress to develop on a Production Server.

Craft your Code, test your Code, get feedback on the Code, then publish, only then.

Research New Functions.

With each new version of FileMaker, we receive newer and more powerful functions. This is now even more evident with the ‘agile’ method of releases from Claris.

The mindset is to challenge assumptions and pre-existing notions of how we have always completed a task, to ensure our craft is continually improving.

As a practice, spend some quality time researching and applying these new functions, and decide to include these in your Coding Toolkit.

Example: The While() function was introduced with FileMaker 18. The Claris documentation is not exactly a tutorial on how to create your first While function, this blog by Skeleton Key (and this one from Beezwax) help clearly break down the structure of your While functions.

Exercise: Find an existing Recursive Custom Function, or even a looping script and then update your code to apply the new While() function. Compare the old and the new, and decide on which allows for the best Design Pattern. Sample an advanced example combining While() with JSON.

Get Claris FileMaker Certified.

We could entertain an entire conversation on this one topic – it’s not without controversy in our community.

Personally, I choose to be Certified to ensure I have spent quality time investigating and exploring the full feature set of our platform. This could be considered a broader version of ‘Researching New Functions’ – although Certification is Claris FileMaker focused and targeted.

Without suggesting that the content of the Claris FileMaker Certification Exam is based on any particular source of knowledge (my lips are sealed about exam material), the best place to get to know each feature may be via the ‘Help’ files – particularly the ‘Notes’ section.

Hit by a Kangaroo Scenario.

I prefer to not utter ‘hit by a bus’ nor invite any other inanimate object into my universe.

Back on topic, there’s no employment guarantee provided by writing code that only you can read, let alone update or troubleshoot. And I ask you, do you wish to be developing the same code for the same solution in ten years time?

Exercise: This follows the other exercises, simply write code that lends itself to various levels of developer skill and experience, particularly for the next Developer.

Conclusion

Ultimately, it’s up to you as a ‘Developer Now’ to consider the happiness and productivity of ‘Developer Next’, remembering, this it may be you in six months time that next touches your code. With a little empathy, and help from Design Thinking and consideration for Design Patterns, I guarantee you a deeper and more fulfilling Developer Career.

Developer Experience (DX) In Claris FileMaker

Option+Click Card Window Scripts