Getting started building FileMaker Apps for WAN performance.
The universal rule is that users will not use software which they perceive to be too slow. If they don’t use it they never see all the cool features you have developed. Thus achieving at least adequate WAN performance is crucial. This can be defined as the user generally not needing to wait for more than six seconds for the App to startup and no more than a second for their screen to update during normal navigation.
Whether you are approaching this with an existing App — perhaps many years old — or whether you wish to develop a new App leveraging the power of Filemaker 15 — will color your approach. In either case you need to strive for simplicity wherever possible — because the less you ask FileMaker to do the quicker it will get done.
I have spent several years learning how to build simpler FileMaker Apps, transiting from traditional complex Apps like this…
through this…
to modern high performance Apps like this…
and this…
The pattern is pretty obvious.
When planning your App consider carefully what your WAN / mobile user most needs to receive and exclude everything else. Bear in mind that 80% of the users of most software only use 20% of the features. Work out what that 20% is in your case and exclude the rest. Resist the urge to include features “because I can”. With an existing solution consider limiting the 80% not required by most users to a separate sub-system for those who may need them and offer WAN users a new limited interface.
Look at existing features — that you wish to retain — and consider whether with FileMaker 15 you cannot rewrite some of these features in order to get from A to B more directly and quickly. You may be surprised at how very much simpler you can make a scripted process first written years ago.
The quickest results for an existing App will be achieved by controlling the current found set of records and by using server side scripting. Further improvements will be made by improving your use of Themes to control your layouts — to avoid the use of any local styles — this will require significantly more work and proper planning.
If your existing App includes unstored calculated fields in relationships then you will see significant gains by removing this schema weakness using a well tried technique to replace these with indexible fields with minimum disruption to your solution.
If you are planning a new App then you need to start by optimising the database schema, the design of fields, tables and relationships, followed by planning your use of Themes and improved scripting.
Your planning work will be aided by obtaining and using two essential types of additional tool — first an appropriate software planning tool such as Omni Group’s Omnigraffle which will rapidly and graphically help you clarify your plans and second a FileMaker DDR analysis tool such as Goya’s Base Elements which will enable you to plan where changes are required in an existing complex solution.
Author’s Note: This short piece on building for performance in FileMaker serves as an introduction to the FileMaker DevCon 2016 Session I was privileged to deliver in Las Vegas, July 2016. Here is a snippet on YouTube:
and here is the full session video:
I am planning a series of posts here on Medium on specific topics from this DevCon session, if there is a topic you would like me to write about you are very welcome to suggest it in a comment on this posting.
Cheers, Nick
Sussex, UK
August 22nd, 2016
[ENDS]
