We have seen an increasing amount of work on FileMaker Go recently and have come to a few conclusions. So here, based on our first few weeks with the product are some thoughts.
Our main use has been on the iPad, so the main thrust of this is aimed at that device.
Out of the box FileMaker Go makes a very very good job of rendering all FileMaker layouts. Pinch/release zooming works very well as does dragging around the layout. However quite quickly it becomes clear that a ‘general purpose’ FileMaker layout does not work well with FileMaker Go
So far we have tended to stick to the ‘natural’ resolutions described in the FileMaker Go documentation and avoided allowing zooming. The main reason for constraining the users this way is to stop accidental zooming.
Effectively the lesson so far is if the users are used to the zoom concept it works well. Where speed of data entry and a simple user interface is important it is better to prevent zooming.
What Do You Actually Want To Do?
Our first use of FileMaker Go was to replace computers used for booking in stock and for picking stock from a warehouse. The natural fit in this scenario is for the iPad to handle the simple pick list/booking in functions with a user resorting to a computer to handle more complex transactions.
The portability of the iPad allows a user to enter real time data from anywhere in a warehouse. Previously laptops had been tried but bulk, battery life and fragility were major minuses to this approach. The main advantage of the laptop approach was a fully functioning machine rather than the reduced power of an iPad.
So right from the start we have developed solutions that have very clear defined procedures. Where in the FileMaker Pro version of the solution a user can achieve a given goal a number of ways, in FileMaker Go there is a simple clear set of steps with no alternatives.
Portal Scroll Bars
The biggest problem with fixing the zoom level is it makes it very hard to scroll portals. So there is a trade off to be decided here.
Buttons To The Lot Of You
Based on the theory my ham fisted fingers would be the least subtle, initially we tried buttons at 32 pixels square. In hind sight closer to 48 square is far easier to deal with.
Without tool tips the funky little icons we have used historically are far harder to use. Instead of a handy reminder as to the function of a button the user has to remember it.
As the main reason for deploying the iPad, speed is essential. Script triggers used on ‘conventional layouts’ tended to make those layouts unusable on the iPad. What appeared to be relatively simple tweaks are a liability when applied to the iPad, as it is not a powerful platform.
WiFi coverage is immensely important to the speed, and its not just speed but latency and bandwidth. Luckily we had a good engineer who was able to give us very good wifi performance. But even very good wifi is nowhere near as good as wired.
Portals with a lot of hops or a lot of calced fields are simply unusable. Similarly a lot of the clever UI tricks are slow. On the plus side conditional formatting can replace a lot of those.
Filtered portals are ok as long as the initial (i.e. unfiltered dataset) is small and the filter calc is simple.
Do They Really Bounce?
iPads are not, unlike a ruggedised laptop, anywhere near strong enough to survive rough handling in an industrial environment. If you drop one from hand height onto a solid concrete floor and it lives then count your blessings. Unfortunately the only one I have seen dropped so far was not in a jacket so I can not offer an idea on how much a rubber case will protect them.
While discussing the device, deploying FileMaker Go requires doing the iStore shuffle. Installing FileMaker Go on a dozen devices is a mind numbing experience.
The iPads can be locked down to prevent the users spending their time surfing the web but there is no way to stop them being stolen and rebuilt.
There is a lot of really good documentation on the FileMaker website regarding development on the Go platform. Its definitely worth reading.