Build a Navigation System Part One - Starting Out Simple

Introduction

The first in a series on the subject. This article presents a very simple and easy to setup method of navigation for a database, making use of repeating fields.

Why do I need to create a navigation system, why not just use the layout menus?

Good question. Of course there is nothing stopping you from just giving users access to the layout menu via the status area, or Layouts menu, but there are a number of reasons why this is not always an ideal method of navigation:

• Large number of layouts may confuse the user
• User may not be required to see all layouts
• Layouts may be placed in groups, increasing time required to navigate
• Developer may use their own layout naming scheme for manageability, but will only confuse the user
• Makes a solution feel less polished

It is my opinion that while the layout menus could be useful in a very simple solution, if you are designing a solution where you want it to look good, and have it feel more like an actual solution, then the layout menus should be avoided, keep them for the developers!

Method of Navigation: The Navigation Bar

The navigation system that will be built in this article is a very simple navigation bar, build using global repeating fields.

So, How Is It Built?

The navigation bar pictured above contains 10 different screens. Each screen in the navigation bar comprises of both an icon, and a text label that appears underneath.

This is achieved using 2 global repeating fields, each containing 10 repetitions, and positioned horizontally across the top of the layout. The first repetition is for the icons, and the second is for the labels:

These repeating fields have been placed in a table called "Navigation". This table only contains one record (though in actuality it need not contain any given all fields in it are global).

When setting up the navigation bar, remember that corresponding repetitions in both fields make up a single screen on the navigation bar. For example the fourth repetition of both fields will be the icon & label for the fourth screen on the navigation bar.

The Importance of Being Global

By having the navigation system based upon global fields, it means we can easily copy/paste our navigation bar onto any layout and it should just work. We will not need to re-point any of the component fields to any other table occurrence. The relationship graph simply requires one table occurrence for Navigation, and this is what is used at all times.

So How Does It Actually Navigate?

Another good question. What we currently have is the appearance of a navigation bar, but no functionality. We need to attach a script or script step to each screen in the navigation bar so we can actually go to that screen.

This is done by placing a button over top of each screen (corresponding repetitions) in the navigation bar. Unfortunately, you cannot simply turn a repeating field into a button and have each repetition act a its own button, which is what we want (though that would be a great feature, c'mon FileMaker!)

In the picture above, the black outlines are the buttons that have been placed on top of each "screen" in the navigation bar. By having individual buttons, we can tailor each one to go to its correct screen.

In order to navigate to a layout, we need to know what that layout is. We cannot hard-code navigation to a layout, because the very nature of this navigation bar means it is built in a "soft" manner - we can completely customize it based on what is put into the repeating fields. For this reason we also need to soft-code the layouts.

This is done by the introduction of a new repeating field into the Navigation table, for the purpose of storing the layout names corresponding to each screen:

With the navigation table now complete, I can setup the buttons for each screen in the navigation bar. Here is an example of how the fourth screen is setup:

As you can see, Go to layout by Name is the method of navigation. We obtain the correct layout name by referencing the repetition of the Layout field, that corresponds to the screen clicked. Each button is placed over a specific set of repetitions, so we can use that number on each button. Indeed each button is setup to go to a different layout repetition.

Is a Layout Field Required?

The answer is yes and no. This depends on how you name your layouts.

If you have a very simple layout naming scheme, and your label names are exactly the same as your layout names, you can just use the label repeating field in your Go to layout by name step.

However, even if this is the case, I would recommend always using the layout repeating field. More often than not, the layout names will differ from the label you wish to present. Label length is constrained by how wide your navigation bar is, and so you must choose your labels carefully. For example consider a screen for Purchase Ordering. That is a pretty long label, so you may wish to shorten it to "Purchases". However, you would really want to keep the layout name as "Purchase Orders" so you know exactly what it is when developing.

What if I Want to Use a Script For Navigation?

Sometimes you may need to do something upon navigating to a layout, such as showing all records, establishing a found set, etc.

If you wish to use a script for your navigation purposes, then you can easily do so. You can pass the selected screens repetition number as a script parameter to the script, and then that script can carry out the navigation to that screen using the repeating field when it is ready to do so.

Taking Things Further

The navigation bar built in this article is a pretty basic, straightforward, bare bones type of navigation bar. There are a wide number of things that can be done with it to extend its usability, design, and flexibility.

In the next article in this series, I will demonstrate some of these extensions, such as:

• Colouring/Bolding the selected screens label
• Background fill under selected screen in navigation bar
• Increasing flexibility of colours/formatting using additional fields
• A script to quickly and painlessly reorder screens in the navigation bar

And future articles will cover areas such as:

• Customised Navigation for each user
• Integrating as a Custom Menu
• Alternative Navigation Styles, ie Portals

Final Thoughts

While using layout menus is a quick solution for navigation of a database, there are a number of drawbacks.

The main benefit of the navigation bar demonstrated, is that it is global, and fully customizable. It is setup once, and in one place, which is reflected across all layouts containing the navigation bar.

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is provided to help you fully understand what is going on in this article, and to let you experiment in FileMaker with this solution

Download Example File