FileMaker Go – What is it actually good for?

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.

Screen Resolution.

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.

Speed

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.

Documentation

There is a lot of really good documentation on the FileMaker website regarding development on the Go platform. Its definitely worth reading.

 

Damian Kelly

Damian has been a database developer with Linear Blue since 2007. During this time he has developed complex FileMaker solutions in a broad range of industries from Finance and Investment to Manufacturing to New Media Promotion. Damian graduated in Production Engineering from the University of Hertfordshire in 1996, attained his Masters of Engineering from Kingston University in 1997 and MBA from Heriot Watt in 2006. He holds certification in FileMaker versions 7 through 12 and in Oracle MySQL 5.

More Posts - Website

4 thoughts on “FileMaker Go – What is it actually good for?”

  1. Very useful observations!
    I am now playing a lot with FileMaker Go and I see one more interesting thing – developing for this platform can teach you important lessons you can apply to the desktop FileMaker development as well. I hope I’ll have some time to write more about this soon…

  2. Thats quite an interesting point Honza. In someways FileMaker on FileMaker Go has to be as focused as possible. FileMaker Pro combined with fast networks and computers encourages lazyness

  3. The word “Go” is important. Changing one’s thinking from moving my solution onto a portable iPad to “How can I use the mobile iPad to best advantage?” Mobile means touch and GO not scroll and hunt…

    Creating a new file that accesses your parent file and designing specifically for the iPad and what a person would most likely do with it is a challenge. I have been working in this vein with the iPhone, without owning an iPhone, and my goal is to use a fixed screen and access the data in question in just a few taps. Using those parameters, my design is uniquely different than that of my 15/17″ laptop screen.

    Rather than just plop a lot of stuff on the screen and let the user find what they want, which works beautifully, I have to think “What does the user want to do and what is the fastest, simplest way to do it.” So I tap, main menu, Address, Keywords, Emergency and I see all of the police, fire, hospitals, etc. in my default county.

    On the iPad I would do something similar except I have room to put a tab to show maps and web pages.

    Oh, and part of my focused design on a solution to work on a mobile phone is that big Emergency Icon on the splash screen and each menu. If you need it, there it is shaky hands and all.

    I think each of Filemaker’s possibilities needs to be viewed within its own parameters and use and a design can be found that maximizes the use. Trying one size fits all doesn’t work quite as well.

    I’ve started 3 blogs at http://www.jackrodgersjr.com and as a startup they are a bit scattered…

Leave a Reply