Better Breadcrumbs

Introduction

Breadcrumb menus are great. They tell the user a lot about where they are within a solutions hierarchy.  They also provide a really quick and easy way to navigate up/down that hierarchy if needed. In the FileMaker world, people have been making breadcrumb menus in various forms for a while, the most common implementation is that of a repeating fields, button bars, or in the case of vertical menus, a portal.

And while all of these methods are workable, they tend to have limitations when it comes to 2 aspects - the visual quality of the menu, and the ability to customise and extend the menu. So what do we mean by these?  We’ll start off by giving an example of a breadcrumb menu built using a button bar, discuss some of its limitations, and then present our alternative implementation using a tab control object.

Example file time!

Rather than wait til the end to check out the demo, we strongly recommend you download and explore the example file as you read. This will help you follow along with the content of the article and help you to understand what we are talking about.

BetterBreadcrumbs.zip

A typical breadcrumb menu

Here is an example of a standard breadcrumb menu. This is a location based menu, as the items in the menu are locations within the solution the user can navigate to.

The user currently resides at the right-most location in the menu, and as you scan to the left you can work your way back up the navigation hierarchy all the way to home screen. These navigation elements are clickable, so the user is free to traverse back up the hierarchy to any point they wish.

Building this in FileMaker

Many peoples first instinct would be to use a button bar to design and build a breadcrumb menu. It has a number of properties that suit a breadcrumb menu:

• Multiple segments, each could be a step in the hierarchy
• Clickable, as each segment is essentially a button
• You can calculate the text to appear in each segment.

But here’s the problem. Button bars are of a fixed width, and the segments within the button bar are all proportional in width to the overall width of the bar itself. So if you have a 100pt wide button bar, with 10 segments, then each segment will be 10 pts wide. If you extend the width of the bar to 200pts, then each segment grows to 20pts in width. You have no control over the width of each individual segment.

So what does this mean for us in real terms?

Here is a crack at building a breadcrumb menu with a button bar. The issue we have is that each segment has a variable amount of text, yet we can only have a single width per segment. Add to this the fact that typical breadcrumb menus have a divider between each element, and you end up with a pretty average looking menu.

This is what it looks like in layout mode, to further illustrate whats going on.

Now, we have seen people come up with attempts to work around this fixed width segment issue. Some involve creating button bar segments based on calculations, where the text inside each segment is padded with spaces to make it a certain width, while others involve starting off with hundreds of small segments, and programmatically removing certain segments and padding others. The simple fact is these are all complex and a real pain to work with, and you still do not achieve a really beautiful result.

What about a tab control?

What’s that, I hear you ask? A tab control? Surely a tab is the last object you’d think of to build a breadcrumb menu right? Well maybe, but the fact is tab controls are the perfect layout object for building them (short of an actual breadcrumb menu layout object!). 

The reason why tab controls are so great for this, is the simple fact that the width of each tab control name is variable in width. This means it doesn’t matter how much or how little text goes into each tab name, they won’t all end up the same width.

This is a tab control, designed to look like a breadcrumb menu. Looks pretty nice doesn’t it. Notice how all of the spacing between the dividers and the items are all consistent.  So how is this done?

Here is the same tab control object highlighted in layout mode.  The height of the overall object has been reduced such that there is actually no content space, it’s just the height of the tab names themselves. We aren’t going to be using this object for placing other objects in, we are only concerned with the names.

Let’s look at the tab control setup next.

Interesting! What we can see here is that the odd positions in the tab control are given the names of the items in the menu. Whilst the even positions are used for dividers. This is a key concept in our technique for building the menu - odd spaces are for items, even spaces are for separators.

The above setup is kind of useless in an actual solution because it is so hard-coded. Ideally you want the menu to be dynamic, and have elements add/remove as you traverse up/down the navigation hierarchy of your solution, but at this point we’re simply showing you the building blocks for how we structure the object.

We use the “Label width + Margin of” option for tab width, this allows tabs to grow as more text is added, whilst maintaining an even spacing between items and dividers. We are using an ascii character of a right arrow for the divider.

Formatting items

You’ll note that the first three items in the menu are underlined. This is to give visual indication to the user that these are clickable. The right-most element is not underlined, suggesting that is the screen they are current on, and there is no need for them to click that link.

Visual design is achieved through conditional formatting of each individual tab control. In this very basic example, the condition for the first 3 items is simply “true” and we format them to underlined. Again in reality we want to be a bit more dynamic in our conditional formatting, which we’ll cover later.

For a navigation breadcrumb, you may actually wish to simply go with a hard-coded menu such as the one above, and just adjust its display for each layout it appears on, and indeed this may be the easiest implementation.  Other implementations may require a more soft-coded dynamic approach.

A simple example

In the example file we start off with a simple wizard example. Here we use a breadcrumb menu to indicate position in a step by step wizard.

This wizard has 5 steps, and the user will work their way through the wizard, and continue to the next section by clicking a button. The menu itself is not clickable, it exists purely as a visual aid to inform the user of their progress in the wizard.

We use the tab control for display of the menu, and we are using a slide-control beneath it for the wizard itself. So, the slide control has 5 panels and each panel is named Wizard_1 through Wizard_5.

The tab control setup is as follows:

Pretty simple stuff. Again odd positions for items, even positions are separators. Because the size of this wizard is known, we only need to add however many tabs are required for each step. 

Navigation through the wizard is done by running a script.  The script takes as a parameter a direction, be it forward or back. Depending on which direction, it updates the value of a global variable $$WIZARD_POSITION. We use this global variable to help us know which step of the wizard we are on.  The script then simply navigates to the next or previous slide panel.

The breadcrumb menu now has to update visually to reflect the users position also. We know the position of the user based on the number in the global variable which will be between 1 and 5.  The visual updating is done via conditional formatting, so let's take a look at that:

This is really easy. What we are looking at is the conditional formatting rule for the second position “Your Details”.  We’re saying that if the user is at this position, or has gone past this position already, that it should be coloured.

Here the user is on step 4 “Interests”, and so the conditional formatting of items 1 through 4 are evaluated to true, and are coloured bold and green.

For the dividers, they are irrelevant in our example, so we can either always evaluate their conditional formatting to true (and assign them some property, in this case grey colour), or you can leave them without conditional formatting, in which case they will inherit the default formatting of the tab control object.

In this example, you’ll note that the text is black, and the dividers are grey, so we have a difference in formatting of the 2 types of tabs. In the interests of simplicity, we make the default tab text colour black, and we have applied conditional formatting to all dividers, to change them to grey.

Adding action to navigation items

More often than not, you want the user to be allowed to click an item in the navigation menu and run a script accordingly. We can achieve this in tab controls by using the OnPanelSwitch object trigger.

Here is the same wizard, although this time all sections can be navigated to at any point in time.

We start by altering the formatting so that all objects are underlined to begin with, indicating that they can be clicked.  The other conditional formatting properties are the same as in the previous example, if the user is on a position, or that position is to the left of where the user currently is, we make it bold and green.

If we apply an OnPanelSwitch trigger to the tab control object,  then our script will run regardless of which tab is chosen.  An important piece of information we will use in the script is the position of the tab the user has clicked. This can be found by evaluating the first value in the function Get ( TriggerTargetPanel ).

There are 2 possible situations here. Firstly, the user may have clicked a divider. Our script will still run in this instance, so we must handle this situation. Recall all even positions are dividers, so we can check whether the clicked position is even. If it is then we return a FALSE result from the script, and the divider tab is not navigated to.

The only other scenario is the user has clicked on an actual item that they can navigate to. This will be an odd number.  We must translate this number into the actual wizard position. We need to do this because of the dividers, they offset the clicked item.

To illustrate this consider clicking on “Immediate Family”. You know that this is the third position in the wizard, but it is actually the 5th position in the tab control. So we need to write a translation between the position chosen and the wizard position. It’s pretty straightforward and simply Ceiling ( $PositionClicked / 2 ).  In our example, this would be 5/2 = 2.5, and taking the ceiling of this gives us a wizard position of 3.

Now that we know the wizard position, it’s just a case of setting our location to that value, and going to that sliding panel object, all done !

You can indeed write your own script to cater for any positional click in your menu, regardless of what you are using your menu for.

Abstracting item names into a table

Often times your wizard or menu items will exist in a table as records because you need to customise them, or build different menus for different purposes. In this example we’re going to show that you can still use the breadcrumb menu in this fashion.

Here is a table of records, each for a different section in the breadcrumb menu, and below is the breadcrumb menu.  The 2 important bits of information in the table are the name of the item, and its position in the menu.

The beauty of using a tab control really stands out when using an abstracted menu like this. The menu will simply expand to accommodate variable lengths of text. In order for things to work smoothly there are just two things you need to be aware of:

• Make the initial width of the tab object wide enough to cater for a worst case scenario length of menu.
• Add enough tab control objects so that you are sure you have enough menu positions to cater for all the items that may end up in the menu.

Here is the tab control setup of this abstracted menu. Wow things are really getting interesting now!  What you see there is a custom function which we have named @BREADCRUMB. It takes 2 parameters. The first is a keyword identifying which records in our wizard setup table to retrieve, and the second is the order number to retrieve. The 5 items in our table are all of type “Abstracted”, and are all numbered 1 through 5. 

Here’s the custom function. It’s a simple executeSQL query where we retrieve names of items based on their type and order number, again nothing magical here just standard FileMaker.

The rest of the implementation is no different to our other examples. Conditional formatting for the items, and a script trigger for navigation.

Abstracting the formatting as well as the names

In this last example we show how you can tailor the formatting of individual items in the menu as well as their names. Now you could achieve this with conditional formatting again, but if you want a specific item to have a specific formatting you may wish to abstract this into a table of records to be based on actual items, rather than position in the menu.

This is a very similar example to the one above, with a slight exception that we have an additional field in our table containing an RGB function for the colour we want our item to be.

Here is the tab control setup for this example:

We have added in 9 different tabs here. In fact we add more than required in case more are needed. Because the items are abstracted to a menu, but adding more tabs, we ensure we don’t have to come back and potentially add more in future.

The other interesting thing to notice here is that we no longer are adding dividers into the even positions. It’s all just calls to a custom function called @BREADCRUMB_Formatted.  This function is identical in behaviour to the earlier one, but this function does a couple more things

• If the order number passed through is even, it returns the divider character
• If the order number passed through is odd, it obtains the name of that item from corresponding record.
• It also obtains the formatting properties from the record, and applies them to the name, using the Evaluate function.
• It also determines using the wizard position $$WIZARD_POSITION whether to format the item, or whether to not format

So in this case, we are not using conditional formatting to determine whether to format an item or not, it is entirely done within the custom function. The formatting properties we use comes from the record itself.

The end result of this is that because we are only displaying text for items, we have full formatting control over how that looks using the text formatting functions. Here we are using slightly different colours for each item.

Tabs are awesome

The tab control object is just one of those cool objects that just keeps giving. We really love these breadcrumb menus and feel they have a really useful place in solutions. They can also be now made to look really professional and behave just like a breadcrumb menu should as well as being very easy to customise and format.

Example file again!

As with all of our articles we produce we like to provide a detailed example file to go along with it. It’s not enough to just read how something is done, you should be able to see it in action and explore how it works yourself. Please find attached the example file below.

Breadcrumbs.zip

Credits

We'd like to thank Greig Jackson here at Digital Fusion for coming up with this method — nice work!