The FileMaker Project – steps along the app development journey
The FileMaker platform is what powers KRCS, and many companies throughout the world. It is flexible, entirely customisable, and, most of all, development is really quick. However, do not fear. This does not mean the KRCS development team are cowboys(and girl)! We follow clear steps when conducting a FileMaker project.
Step 1: Talking it through
FileMaker is a rapid application development tool. This means that a developer, can quite quickly, get a blank canvas and start coding straight away. However, this doesn’t mean it’s necessarily a good idea! It is better to get a good grasp of what’s needed first. Then, it’s a matter of bringing the specificities and limitations of FileMaker, together with your needs, to find the best, cost-effective middle ground. A few years ago, we started working with a pharmaceutical company in Yorkshire. What they needed sounded simple: translate all their paper records from quotation to production and shipping into FileMaker. Easier said than done! We met several times at their premises and had day-long meetings to understand their processes. We went into their lab and sales floor, where we could access all the folders and log books that they were using, to record progress on their production and sales. This gave us a lot to take back to Nottingham and start building a proposal.
Step 2: Translating the specifications
Once we understood what they needed from a business point of view, we could start thinking about it in FileMaker terms. This meant understanding how their processes linked to each other, what needed to be included in the app, and what didn’t.
This step is absolutely necessary to ensure the scope of the work is right.
Basic data structure of the app
Once we get the data structure right, we can start thinking about how we will build the app’s functionality. To do so, I like to start drawing the screens the users will interact with. What’s on the dashboard? When I want to enter a quotation, where do I click, and what happens then? It helps to put myself in the shoes of the user, to list in detail what script, buttons, and interface features are desirable. With my sketches in hand I can start building the app!
Step 3: Start coding!
The repartition of the development work load at KRCS means that developers usually work alone on their projects – save for the biggest ones – with great freedom in the tools and methods available. However, we still have 2 simple rules to ensure that any one of us can hop on another project if needed:
- 1. Comment your code!
- 2. Use the Anchor-Buoy framework!
Developer autonomy ensures tight deadlines can be met, as we can get to coding straight away after the design phase. The FileMaker platform is, after all, a leader among the Rapid Application Development Software crowd. I like to code in “modules”, meaning that I will do one functionality at a time. For the aforementioned client, I started with a CRM module to manage a list of client organisations and contacts. Then a colleague tested it to ensure it worked well. We always test each other’s projects as it is easy to miss a bug when testing your own code. Typically, after that was done, I would usually start on a related module, for instance quotations. Each module would correspond broadly to a step shown in Picture 1 Basic data structure of the app. Rinse and repeat until the project is ready to be deployed!
Step 4: Time to deploy the app!
Most FileMaker apps need to be hosted on a server. That way they can safely serve as many users as needed, who access data securely, stored in one place from their PCs Mac, iPad, iPhone or web browser. There are a many ways to access a FileMaker app!
Using FileMaker Server, ensures the app and its data are backed up and recoverable, and it can even be accessible in the cloud for more security and flexibility.
So the deployment strategies we put in place, depends on you: who needs to access the data? When? How? How fast? From where in the world?
Accessing an app hosted on a local server will always be quicker than accessing an app hosted in the Cloud. We discuss all those aspects with you and together we choose the deployment solution that answers your needs best. This can be done at step 1, when we discuss the business aspects of the solution.
Step 5: Aftercare
One of the best features of FileMaker is the ability to edit a live file. It makes it easier for us to correct bugs found once you start using the app, and it also means that it’s possible to tweak it! It has been made safer to do so very recently with the latest version of FileMaker, which allows developers to import large data sets in minutes. It is customary for us to offer a support contract after launch. This enables you to ask for small adjustments of the app after you start using it. For example, the pharmaceutical company I mentioned earlier very recently – 2 years after launch – asked for a report to be sorted in a particular order. This wasn’t something they’d thought of in the original spec, but was a ‘nice-to-have’ that they were ready to spend a little bit of support on. No need for a costly re-write! To me, that is one of the main strengths of FileMaker!
If you would like to take advantage of our FileMaker developers, either to build your app or mentor your through your FileMaker journey, please contact email@example.com or call 0115 985 1797
1 The “cowboy” approach to coding allows programmers to work with minimal process and discipline, which often means best practice is not followed and project management is minimal. This often leads to late projects due to a lack of implementation planning and dirty coding!