Now the dust has settled a little perhaps it would be useful to start pulling together the things that 13 can do to improve our lives as developers and our users' experience? Not necessarily the things that the FMI marketing folk choose to focus on.
These are my personal thoughts developed through the FM12 period into the present - so do please disagree if you wish - I shall be delighted to hear your contrary views - the best way to learn.
FMS13 enables us now to write a single solution - if we design it carefully - reading the FM WebDirect Guide first is a must - that we can deploy through FMP on recent versions of OS X and Windows, through FMGo on iOS and through FM WebDirect to many browsers - so a really great variety of deployment options.
So how can we get the best out of this new box of tools that FMi have delivered?
(a) Typically these scripts run about 20 times faster than the same thing run on a hosted file but not RSos - hence have a profound effect on WAN performance and WAN user experience.
(b) Debugging these scripts is tricky but the FMS13 log provides a great deal of information to help track down one's errors. I write each script to run locally first, driven entirely with parameters passed in a pseudo xml string - a Ray Cologan (amongst others) technique - then have a switch to run the same script RSoS instead - to me at least the simplest means of development.
(c) What I didn't realise until recently was that every time you RSoS this new user session calls the On file open script you have specified - so you need to amend this to do what you expect each time.
(d) You also need to bear in mind that a script that is RSoS will generate Error 3 if it calls another RSoS - since that is now a server side session all sub scripts must be called locally.
(2) Efficient Ui design:
(a) It is more work but I suggest there is no substitute for building new Uis using editable Themes - once built this means you can change every object with the same style throughout your solution by merely Saving the change to Style and then saving the Change to Theme.
(b) Whilst about it why not rethink your Ui design to look and feel more like the modern Apps that all our users are used to on iOS and Android? Remove complexity - remove gradients - simplify then simplify again - to produce something simple, uniform, consistent and elegant? Because that equals speed and speed equals good WAN performance.
(3) Efficient Relationship Model:
(a) To make a solution fast you need - in my experience - amongst other things - to ensure that you adopt the archipelago relationship model - many small groups of TOs - and use publication of environmental data used in the system to $$vars to maintain that simplicity
(b) Then remember that since relationships are bidirectional you can remove some stuff by thinking right to left as well as left to right - not that easy.
(4) Avoid things that are clearly slow:
(a) If you provide folk with an easy method of tagging and finding records then it is - I think - viable to not permit them to do things which you know will be slow - like listing 200k records. Filtered portals are a wonderful and efficient means of getting users to their data quickly and with a little thought enable folk to search for several non-sequential words in a single portal filter.
(b) In fact completely avoid the "traditional" sort of FileMaker Ui design - a wide panel containing many objects and a second layout for a listing - rethink what you want and build something that sips parsimonously on the actual data - thus only asks the WAN to handle the data the user actually needs.
(5) Use value lists where possible:
(a) This is a theme I covered in my similar thread under 12 - from FMS12 onwards the production of value lists is very efficient - much much more efficient that under FM7-11. So where I want to give a user a list of records they have found - I can actually use a value list of the found set and display it using Bruce Robertson's virtual list technique - more efficiently then actually giving them the actual list itself.
(b) So one possible approach is only to open up the real record when it comes to an edit - everything else is virtual - extreme perhaps - but this can be very fast technique because it capitalises on the strengths on FMS13.
(6) Think about what FM WebDirect is good at - how it works and try to use that:
(a) WebDirect is all happening on the server - then publishing the Ui to be displayed in your browser. From the error messages one can generate this appears to use the Vaadin framework and also appears to download a Java virtual machine onto the user's device to help the browser display all our beautiful FM Ui stuff and provide interactive response. So the data work is all undertaken on the server by the Web Publishing Engine without you needing to RSoS - which is why WebDirect does many things nearly as fast as RSos. So this means that if you are designing for WebDIrect you can write simpler scripts without the difficulty of RSoS and still get very good performance.
(b) The flip side is that as this is all done on server you need sufficient server resource, a different server core per simultaneous user script call is a good guide. Since each script call on WebDirect is typically completed within less than 0.25 sec and since real users spend far more time looking at their screen than clicking - unlike test users who just click - it seems to me at least possible that with efficient design an 8 core server could handle say 64 WD users - based on each core handling about 8 users assuming that they do something only every couple of seconds or longer - and assuming no FMP WAN users - certainly my own testing suggests much better performance than FMI's tech requirement proposes.
(c) This is something I have only thought about today - so do please tell where you think I am going wrong - so .... however, if you think about what the server cores are occupied with - if you have a few FMP WAN users on the same machine - running scripts locally not RSoS - whose user actions can typically take 5 - 10 or more seconds to complete - that means that these few FMP WAN users may actually hog a great deal of the total server resource and slow down all your WD users - which is why I propose that for good WD performance you may need to limit your slow FMP WAN connections on that server - efficient RSoS WAN connections should require similar resource to WD.
So that is my starter - please do add your techniques / design approachs for everyone to share