Over 46,000+ Business Solution Developers Find answers, ask questions, and connect with our community of business solutions developers, business owners and partners.
FileMaker 13 Progress Tracker Using Hide Object – FileMaker Today
We have been working on a FileMaker system to replace one from around v8, with “all fields on a big desktop”-style layouts—layers of tabs, and a little bit “Where’s Waldo?” The customer is a niche printing business, mostly yearly repeating, but most jobs are highly bespoke — and all with legal compliance requirements.
The data on their new web store has a completely different structure to the existing, rather flat, set of tables, so this has given the opportunity to look at the whole business, and focus on the processes and not merely the acquisition of data.
To introduce a clear, simply understood progress indicator for how far each “job” is through the system, with visibility to all users.
We all take inspiration from multiple sources, some of which may be past memories of design language, so when I saw the post here recently on creating a progress tracker, something reminded me of presentation graphics I did several years ago for the car company, Jaguar.
The brief was to communicate to journalists the “top ten important things about this car.” For this we turned the screens on their sides and simply showed ten slides as a list of features, with an indicator running down the left margin and titles breaking into the body text.
Similarly, for this project we wanted to have the entire process laid out on a single layout, and only show the objects relevant to the stage of the job. In the past something similar might have been achieved in FileMaker using conditional formatting, but that only works for native objects, and I was interested in playing with a favourite new FMP13 feature, Hide Object When.
To enable this we will determine the stage by using a calculation in a field which we will call ProgressIndicator.
The first step is to move to the calculation engine, and specifically binary maths, which uses ones and zeros to show increasing powers of the number 2:
1 = 1 2 = 10 3 = 11 4 = 100 5 = 101 etc. or 20, 21, 22, 23, 24, ...
This is useful because for each next power of 2, if you add all the previous results in the sequence together you will be one short, e.g. 1 + 2 + 4 + 8 = 15 (one short of 16—the next power of 2).
We’ll use a calculation called ProgressIndicator to determine the stage. It is written as a big Let statement, where each satisfied condition (stageN) adds the next power of 2 to a running total number variable (_x).
// The stageN test can be not IsEmpty(field) e.g. invoiceDate or any other valid combination of conditions
Let([ _x = if( stage2 ; 3 ; 1 ) ; //stage1 default _x = if( stage3 ; _x + 4 ; _x ) ; //add 4 == 5 or 6 _x = if( stage4 ; _x + 8 ; _x ) ; _x = if( stage5 ; _x + 16 ; _x ) //etc. etc. ] ; _x )
This means that you can determine—in a single, elegant calculation—which specific stages have been completed. You don’t have to have a separate test for each stage and then determine where in the process you are. Since no two stages add up the same way, you can always tell from the resulting sum which stage is incomplete.
Next, because the display part utilises only “1” and “0,” we can then test which binary “bits” are “on” (i.e. have a value of 1) in any decimal number when it is converted to binary notation.
For example, testing the number 5 ( in binary notation 101), bit1 will be true, bit2 will be false and bit3 will be true. (Pedants will know this is actually bit0, bit1 and bit2, and is read right to left—BUT it gives me the chance for a maths joke: “There are 10 types of people in the world, those who understand binary and those who don’t!”)
The custom function BitTest will do this for us:
BitTest ( value ; bit ) Returns True (1) if the bit is ON, False (0) if not.
We want to hide any stages that come after the one we are currently on, so the simple test for object visibility for indicators showing that a stage has been completed becomes Hide Object When:
BitTest ( Status::ProgressIndicator ; oneMoreThanMe )
– based on a strict adherence to every step being “completed.”
In this use case the client needed to be able to skip several steps, so there was an additional test to also work out the ProgressIndicator value if only the first and the subsequent step were completed, which added:
OR ProgressIndicator > nnn
For example, visibility test for current stage 6 ==
not BitTest ( Status::ProgressIndicator ; 7 ) or Status::ProgressIndicator > 386
Armed with a set of values on which we could show or hide a sequence of elements, we can now set about the design part of the exercise.
Next, the design
A simple dotted line with a series of evenly spaced numbered graphics is the completely OFF state, and no hiding condition applied—as in this case the graphics to show above these are exactly the same size and shape.
We then copied this set alongside and made them the COMPLETED state
Then another copy with the CURRENT state
Then finally two values which required a WARNING state (more about this later)
For the purpose of testing, we put the ProgressIndicator, and each of the fields which constitute the conditions being fulfilled, onto a layout and started filling in the Hide calculations and possible field values. With the “Hide Object When” calculation in full view on the fourth Inspector tab, you can easily see what is happening with the indicator state for any given object. In our experience, it’s somewhat easier to troubleshoot this way than multiple conditional formatting states hidden in a dialogue box.
It became possible to delete the first OFF state graphic and also the final completed one, as they are never required.
There are two places in the workflow where approval is required for artwork, one if it is a new client and the product is in the standard range (allowing for a check if the customer has come from the web, and they have been responsible for entering their own text), and the second if the product is highly bespoke and definitely requires customer approval for final artwork before printing.
This added two additional markers on the top layer, with a slightly different set of conditions – based on business rules. in the first case it is deemed OK to pass to print without the explicit confirmation but in the second this puts a definite halt to the futher stages.
After testing, it was then a case of aligning all objects be horizontal centre ready to be pasted onto the final layout.
A text label for each stage is placed next to the numeric indicator, with a colour depth that doesn’t draw the eye unnecessarily, followed by a set of key dates when each gateway was passed.
With a solid way to calculate progress status or stage completion, it was easy to add buttons which either allow for related action, and where appropriate to allow it right here, or to allow for disclosure of the related information, like an invoice, in some other window.
Some of the text labels are either a pop-over button or run a message pop-over script, enabling a rich layer of information right at the point of use. The yellow “plus” means add new or add data in the rest of the system, similarly the blue “jump to” arrow.
While we have been talking about the abstract of tracking “status” for some months, any brand new interface can meet initial resistance or confusion. So we showed some static screen-grabs first which led to very helpful discussion about the actual stage label and the exact ordering.
As we had already made the relevant scripts, it was quick to change text, assign pop-overs & buttons and amend the ProgressIndicator calculation. Within about half an hour we were then able to demonstrate the working prototype.
My experience is that while the “shiny moving parts” are the bits which really impress, it is all the more satisfying when they are built based on sound analysis of business processes.
Download the demo file to see how it works in detail.