Build a Navigation System Part One - Starting Out Simple
By Daniel Wood, 3 January 2011
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
Something to say? Post a comment...
Comments
Daniel Wood 20/05/2020 11:03am (5 years ago)
hello Wasiu, if you need some help please feel free to get in touch with me via email - daniel@teamdf.com, thanks.
Wasiu 17/04/2020 9:29pm (5 years ago)
Please can you help me with script that can place table fields as button set caption just like pos sales point buttons for retail sales
Wasiu 17/04/2020 9:29pm (5 years ago)
Please can you help me with script that can place table fields as button set caption just like pos sales point buttons for retail sales
Binu_Alexander 15/03/2015 7:13am (10 years ago)
Same Problem as Andy ..... All the values in the global fields disappear when I close the file. All my configuration goes waste !! What are we missing here ?
Andy 04/01/2015 5:23pm (10 years ago)
I am just a FM Noob so I have a stupid question. I must have missed how you keep the global from clearing after close. I get the menu set up and when I reopen, the data is gone.
Jeeva 23/11/2012 4:15am (12 years ago)
Thank you for this post. It is very helpful. Let me know is there any other alternative method to achieve this. Can do it with custom function. Is there any alternative kindly give example. Waiting for sample. Thanks in advance
Hunny O 28/09/2012 12:02am (12 years ago)
Thanx a lot Daniel.
This was super duper useful for me..I'm just a FileMaker newbie.
Daniel Wood 21/02/2011 8:08am (14 years ago)
Hi Dan, yep it is the first, just have to write the next one now :)
Dan Heinze 21/02/2011 6:14am (14 years ago)
You said this article was the first in a series. Can't wait for the next installment ...
Daniel Wood 10/02/2011 2:32pm (14 years ago)
Hi Robear, thanks for the comment, this is indeed a good idea.
I should have stated that the main reason for me using a separate button over top, is because I wish for the entire block allocated for each screen in the nav bar to be a single clickable link. This area includes both the icon repeating field, AND the label repeating field.
Now, I *could* do as you mention and make each repeating field it's own individual field, and then group both the icon & the label into a single object, and turn that into a button. There are two key reasons why I don't do this:
1. If i need to reposition or edit any of the repeating fields, I have to ungroup the object first, which is going to force me to get rid of the button that the grouped object now is, very annoying.
2. I use an interface/data separation mode, meaning I have many layouts each based on a different interface table occurrence. I like to be able to copy and paste the entire nav bar to a different context, and very quickly repoint the repeating fields to the new context. If the repeating fields are all together, then this is a 2-step action of repointing the icons & the labels. If each one is its own separate field, that requires 2x the number of icons & labels, takes far longer to do.
Hopefully this clears up my decision to use the button as an entirely separate object as opposed to using the repetitions themselves.
Cheers.
robear 10/02/2011 2:24pm (14 years ago)
? Although you cannot turn a repeating Field into a button you can show any 1 repeating field by itself and turn that object into a Button. Simply set the Field's parameters to Show 1 of 10, 2 of 10... (see Inspector / Data / Field area)
"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!"
Julio 04/02/2011 6:14am (14 years ago)
As far as having to place a button object on top of each repetition, you could potentially avoid having to this by making the repeating field enter-able and running running the script OnObjectEnter.
Daniel 01/02/2011 9:13am (14 years ago)
Hi Brian,
Reactor is capable of running Native FM scripts directly from the javascript code you write, in addition to obtaining field values from FileMaker as well as setting them back. When the user clicks on a button in the reactor navigation in the core file, it triggers the running of a native FM script which then handles the actual navigation. This is the core concept behind Reactor in that it enables you to write interface controls using web technology, but hook that directly into FileMaker via functions to get/set field values, and run scripts.
Cheers
Daniel
Brian Schick 01/02/2011 8:50am (14 years ago)
Interesting, Daniel. I'll look forward to checking out Reactor & black box in more detail. The ability to have standard web events for navigation - particularly moving forward into html5/css3 - is really appealing.
Which has me curious: When you've used Reactor for FileMaker navigation, have you relied on some added functionality of Reactor to enable in the web viewer to trigger nav scripts in FileMaker? Or have you used native FM techniques ( that I clearly don't know about : ) to allow events in the web viewer to trigger scripts in the FileMaker database?
Thanks,
Brian
Daniel Wood 30/01/2011 2:00pm (14 years ago)
Hi Brian,
Yes we have used Reactor to do some navigation in the past but generally it is for custom development. The repeating field method is one we use in our framework system because of it's quickness in setting up, something that saves us time when building custom solutions.
If you have a look @ the Reactor demo file, you will notice the navigation there is done using reactor (not a blackbox however). The cool thing about that is it can use things such as rollover effects which look quite nice, at the expense of added work to program.
We haven't really pursued a simple navigation system based on Reactor beyond that, but it might be a possibility for the future, or for someone else to have a crack at building a blackbox for.
Cheers
Daniel
Brian Schick 30/01/2011 1:14pm (14 years ago)
I'm curious if you've considered using your own Fusion Blackbox as a possible alternative. I'm guessing there are probably gotchas in the FileMaker interaction with the web viewer that make this less attractive in reality than it sounds. But still, the possibility's intriguing?
Justin Sisney 21/01/2011 11:38am (14 years ago)
Thanks for the tip. Great information for a filemaker newbe
Peter Newland 18/01/2011 10:42pm (14 years ago)
We've used a similar system for many years but add another set of, non global, repeating fields to hold copies of the global items. During startup we copy all the items from the storage fields into the display global's. Allows changes to networked server solutions where changes to global's would otherwise be lost.
We use the same technique to get sub levels of menu's, just further down a repeating field chain, and then layout trigger scripts to set various parameters on layout load etc.
Have had great success with both using this technique in vertical orientation and even as a separate floater window.
Daniel Shanahan 04/01/2011 3:01am (14 years ago)
I do something similar using a portal. A vertical nav bar is easier than the horizontal nav bar because the latter requires showing one portal, each a different row. Then I began to wonder about using a repeating field for horizontal navigation. I haven't yet, so I was very happy to stumble upon this article. Good luck with weetbicks - it is now bookmarked!
David Zakary 03/01/2011 12:01pm (14 years ago)
I've been using this kind of system for years. Works well, has issues, but is very simple to set up and maintain.
Daniel 03/01/2011 2:01am (14 years ago)
Hi David, thanks for the comment. Yes it's a good simple solution, but you are right about the drawbacks. One I should have mentioned in particular it it's lack of scalability if you wish to add more screens, it require modifying the nav bar on all the layouts etc..
We have used a modified version of this for a very long time here @ Digital Fusion, and have never felt the need to move to anything else.
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments