Here a few thoughts on my current conclusions on the development for performance work I been doing over the last years - please do comment and disagree - perhaps this way we can start to build some agreed good practice on developing for performance and in particular for WAN.
An introduction to building for performance.
The universal rule is that 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 a second for their screen to update during normal navigation.
Whether you are approaching this with an existing solution – perhaps many years old - or whether you wish to develop a new solution leveraging the power of Filemaker 13 – 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.
When planning your solution 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 13 you cannot rewrite some of these features in order to get from A to B more directly and quickly.
The quickest results for an existing solution 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 – this will require significantly more work and proper planning.
If your existing solution includes unstored calculated fields in relationships then you will see significant gains by removing this schema weakness using a well tried technique to replace with indexible fields with minimum disruption to your solution.
If you are planning a new solution then you need to start by optimising the schema 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.