FileMaker is a great tool for building many kinds of software solutions, many of which involve managing/organizing/scheduling visits/sales or service calls, deliveries/etc. An example might be a solution for a home inspection company, the keeps tracks of the homes the inspector needs to visit.
Google Maps excels at displaying (in the form of a map) that kind of address data, creating an optimized route between those waypoints, and calculating the distances and times involved.
Given the relatives strengths of the two platforms it's easy to see how desirable a mapping integration would be, and the Google Maps API makes that relatively easy.
The FileMaker web viewer is a very powerful tool, and it makes integration with the Google Maps API fairly straightforward – the solution just has to send the address or waypoint data into Google Maps via the web viewer.
There are a number of mapping modules and products designed to make the tricky part – formatting FileMaker address data for use with the Google Maps API – easier, and they work quite well.
The problem is that they ignore one major problem, and miss out on an amazing opportunity for a mapping application.
Seeing a list of waypoints on a map is great, seeing the route optimized along with estimated times and distances is even better. Getting some of that data back into FileMaker would be even better.
For example – Google Maps will optimize a list of deliveries into the most efficient (shortest) route. Two way communication would allow that information to flow back into FileMaker, which could then list the deliveries according to this new optimized order.
But that is just the start – the FileMaker mapping solution could also get the estimates ETAs, distances, etc., manipulate it using calculations, include it on FileMaker layouts, etc.
None of this is possible using a simple web-viewer approach, but Delfs Engineering has developed a solution.
Delfs is a very special kind of FileMaker development company, one that often gets called by other FileMaker development firms to solve the problems they can't. Once such problem was a more complete FileMaker/Google Maps integration that would offer two-way communication.
The result is outstanding, offering better and faster communication than expected. It includes extra touches like having the related FileMaker record highlight when the user hovers over the pin in Google Maps.
It might sound like window dressing but it's actually very powerful – a user looking at a route can hover over a pin to see related data (the nature of delivery, the production status, etc.) get highlighted in a portal.
The standard web viewer approach also ignores an important consideration involving what Google considers a "page load", and that can be costly as more page loads almost always mean more money (plus a performance hit).
In the more typical intended usage the Google map would be embedded on a web page as part of some kind of web app, adding mapping functionality to that app. When the user first visits that page that is one page load. From that point on the user is generally interacting with the map itself, and this does not count as additional page loads.
Using a web viewer is very different. Again, when the web viewer (and map within) is first displayed, that counts as one page load. But the web viewer also triggers a lot of additional page loads. If you refresh the FileMaker window, that is another page load. If for example you were toggling addresses from a portal into/out of the map it's a page load each time, each way. If the contents of a web viewer are based on a calculation, it's a page load every time that calculation changes.
Here the page loads (and related costs) can really escalate, especially if you have some kind of FileMaker vertical market mapping solution.
Again Delfs Engineering has a solution, one that allows FileMaker to interact with the Google Maps API through the web viewer without triggering additional page loads. It is an elegant answer to a serious problem – a problem that other mapping solutions have tended to ignore.
