In software design, it’s common for users to not notice a well-designed feature while almost always taking note of the less-developed options. There’s a simple reason for this: when software operates the way users anticipate, they don’t recognize that it did exactly what they wanted. But when it doesn’t, the unmet expectations remain, standing out like a sore thumb. This is especially true when it comes to navigation. 

At the surface level, navigation is a simple concept. Users click to go to a new location. But from a development and user interface standpoint, it’s not nearly that simple. What does the navigation look like and how exactly do users interact with it? 

When creating your navigation structure, perhaps the most important starting point is determining which versions of FileMaker will need to use this file. Features change over time and aren’t always supported on older versions. In an ideal world, clients are always up-to-date on the most recent version of FileMaker, but the reality is that this doesn’t happen.

What object does the user click on to navigate throughout the database? The two most common options are individual buttons and button bars. Generally speaking, button bars are the superior option. They’re easier to use when formatting multiple options, allow merge fields and calculations, use an active state, and can easily resize on your layout if specific buttons are only available for certain users. However, if the database uses FileMaker 13 or earlier, button bars aren’t supported. Additionally, a button bar will stretch to fill space by increasing the size of each button. If certain buttons are only available for select groups of users and you don’t want the options to scale, buttons will retain their original size.

Once you’ve decided between buttons and button bars, then you need to determine how they’ll be accessed in your database. Below, we’ll discuss four possible options available in FileMaker for navigation processes.\

First, you can place your button or button bar directly on the layout as an object. This method maximizes access and visibility, though it can take up more space on your layout than other methods (depending on your overall navigation structure). However, changes to your navigation will need to be updated at every instance this is used, which generally would mean each individual layout. Using your layout is one of the most widely-supported methods.

Second, you have the option to use a pop-over menu that has the button or button bar placed in it. This decreases the visibility of the navigation while also requiring an extra click to access, but it can be a more efficient use of space on a crowded layout. Pop-over menus are supported in FileMaker 13 and newer releases. They also will need to be updated across every instance of the navigation structure should changes occur.

Third, there is the option of a card window. Card windows are similar to pop-over menus in that they aren’t as readily available and require an extra click to launch while saving space on the actual layout. Additionally, the card window will require an extra layout to maintain. However, perhaps the greatest perk with a card window is that it’s used in all navigation instances. If you need to add or remove navigation content, you merely do so on the card window and it’s applied everywhere the card window is linked to—potentially saving great amounts of time and energy with future development. However, the greatest downside to card windows is that they are only supported in FileMaker 16 and later, making them inaccessible to some legacy databases.

Fourth, portals can also be used with a button assigned to each record. This method allows a great amount of flexibility due to the nature of portals, and because they’re supported by so many versions of FileMaker. You can arrange your portal so that all navigation elements are visible at once, which allows them to always be accessed by users while reducing the number of clicks required, though potentially using a decent amount of layout space. Or, you can make the portal condensed in size so while the user may need to scroll to view all options, it minimizes the amount of space used. Depending on how the portal is set-up, it can require minimal work should the navigation structure change in the future, though that initial set-up process can require more slightly more development than other options.

At PK Information, we frequently find ourselves using card windows and portals—but we also use popover menus and layout objects for our navigation. Deciding which of these options is best largely depends on the situation: what your client needs, the database structure, and how the users will operate within the system. Engage with your client and do as much research as possible before you commit to a specific direction. Even then, realize that new information may come to light or needs will change over time resulting in an update further down the line.

PK Information is a FileMaker-certified development agency serving the Tampa Bay and Knoxville regions. We believe that great software can change everything. Would your database benefit from a process review? Contact us today!

SUBSCRIBE

Sign up with your email address to receive future posts like this directly to your inbox.