The Unified Layout

V12, Section 2

This post is the second in a series based on our effort to revamp xBase. We are currently using xBase version 4 (Click to download. Full access login is developer:Extensitech), which was designed to leverage the capabilities of FileMaker version 10. It has served us well, and continues to do so, but it is getting a bit old. We’d like our next version to take into account all the things that have made version 4 such a pleasure to work with, but we’re taking a “ground up” approach, reconsidering everything we’ve done to ensure that we’re fully leveraging new capabilities of FileMaker, and all that we’ve learned as developers during the years since we developed version 4.

You will note, by the way, that we’re changing our version numbering system. Version 4 is, as you might expect, the fourth iteration of the xBase file. That’s probably the simplest naming we could do. However, it becomes challenging to explain to clients that version 4 was made for FileMaker 10, version 3 was made for FileMaker 9, version 2 for FileMaker 8 and version 1 for FileMaker 7. Instead, from now on, we’re going to name our xBase versions after the FileMaker version for which they are designed.

The concept presented here, the unified layout, is one that we’ve employed for some time, and one that we are keeping pretty much “as is”. Other concepts build on this, though, so this post explains how and why we have a single “base” layout that does the lion’s share of the work for each table in xBase.

The Unified Layout

For this post, you may want to download a copy of xBase version 4 and follow along.

There are a few important conventions we employ in xBase that make our development faster and more consistent. One of them, our naming convention, I discussed in a previous post. The use of a single, unified layout is another important convention.

In most other FileMaker solutions we see, each table has a number of different layouts. The most obvious and prevalent two are form and list. Many solutions include others, too, such as a layout for doing finds, a layout for selecting records, different data entry layouts for different departments and/or use cases, and so on. We also find that these layouts vary in how they are designed, both by purpose and from table to table.

In xBase, we’ve created a single layout design that can be used for all of these purposes. (Open xBase v4. Go to the Navigation menu, Contact Management submenu, and select “Contacts”. I’ll point out examples from this perspective.)

The most unusual aspect of the design is that the list and form are both on one layout. We accomplish this by making the layout a View as List, but putting a large tab panel in the footer. In browse mode, the footer shows field values from the currently selected record. The effect is that when you click on a record in the list, the details of that record show in the form section, which is really the footer. Thus, the user does not have to continuously switch from list to form and back, and when working on a record they can still see a brief description of other records in the found set, up in the list portion.

We combine various departmental and use-case layouts through the use of tabs in that footer. This allows a user to see all the details of the record on one layout, but still allows some focus based on what tab they have selected.

(Go into layout mode on the Contacts layout, and you can see the various parts.)

Another nice side effect of this approach is that it’s fairly easy to adjust the layout for different uses without having to create a whole new layout.

One obvious method of doing this is color. In xBase v4, for instance, there’s a bar above and below the list portion with some conditional formatting, so that the color of those bars change depending upon whether the user is doing a find, adding a new record, selecting records or editing an existing record. It’s a subtle change, but it acts as an alert to the user that they’re doing something besides just scrolling through records. In xBase v2 we actually changed the color of the entire background, but we found that that made it more difficult to make text and buttons “disappear” (really, match the background) when not applicable.

Another method, not so obvious, is to change the size of the window. If you resize the window on one of our unified layouts to be smaller than the footer, only the list portion shows. We use this for when the user should be selecting from a list. On the other hand, if you find just one record, and resize the window to be just a bit larger than the footer, that one record in the row ends up looking like a header for the information on the tab panel. We use this when the user is adding or editing a record in a modal window.

To see these changes in action, try the following from the Contacts layout:

Add a new record. The bars turn green and the one new record shows in a smaller, modal window to let you know that you need to finish adding your new record before you proceed elsewhere.
On the Relationships tab, click the “add link” button (the little chain link above the list of related contacts) to select another contact to link. When asked for search criteria, leave the box blank so you can browse all. The selection window shows just the list and the bars turn yellow.
Note that both the New Record window and the Select Records window were showing this very same layout, slightly altered based on what you were doing. If you missed that, try selecting a related Contact again, like you did in step 2. When you get to the selection list, though, stretch your screen vertically, and watch the details portion at the bottom of the screen reappear.

There are two important notes regarding a unified layout. First, note that we are not talking about layouts for printing. A unified layout cannot effectively serve as a print layout for forms and reports. Things that print get their own layouts.

Second, having a unified layout doesn’t preclude having other layouts for the same table, for specific data entry efforts or other very specific functions. In most cases, though, it makes multiple non-printing layouts unnecessary unless a client has a pressing need for something more specific. In our experience implementing xBase for dozens of users, we’ve had less than a handful of solutions where additional, non-printing layouts were needed.

If, in your own development, you prefer more specific layouts for more specific purposes, you can still have them. Having a single unified layout for each table, though (even if there are others) means that your scripts can always reliably determine a good layout to go to.

This is especially useful if you name the layout the same as the table, since you can calculate a good layout name based on the field or table your script is working with. For example, in xScript (which we’ll discuss in more detail later) we pass parameters to the “selection” routine, including the table from which we want to select. We have the option to specify a selection layout, but if we don’t (and we usually don’t) the routine looks for the “main” layout, which is the one with the same name as the base table.

Also, unless you go completely nuts adding other layouts, changes to the display can be made in one, or at least fewer, places, reducing development time and a fair amount of tedium.

And finally, note that we have a table and layout called “ZZZ__Template”. Building a unified layout from scratch each time would be tedious, but we have a template to work from so that we don’t have to do that. If you want, you can follow the steps below to make a new table and new layout with all the basic functionality you just saw on Contacts. Note that in v12 we’ve simplified a number of these processes. In spite of the length of the list below, though, this goes pretty quickly:

In Manage Database, select, copy and paste the ZZZ__Template table.
Rename it using the same naming convention. For example, let’s change it to “ITM__Items”
Go to the fields for ITM__Items. Change the primary key (“__P”). In the options for that field, change the auto-entry serial to start with “ITM1”. Take “_change_me” off the field name.
On the relationship graph, link ITM__Items to ITM_SYS, (based on the SYS__System table) and make _1 equal _1. (This is a cartesian relationship to the one System record, but linking 1 to 1 is just easier to drag and drop.)
Click OK to leave Manage Database
Go to the ZZZ__Template layout, and duplicate it.
Your new layout should be called “ITM__Items” and be based on your new ITM__Items table.
Repoint all fields to the local table. Reset all merge fields by clicking in and doing an “edit” (delete a letter or character and put it back, so that FileMaker will reset the reference)
Delete the ITM__Items layout that FM automatically created (it’s a mess, anyway).
Run the script called “System_Preferences”, which just adds your new layout to the cached layout list
Optional: You can add this to the navigation menu now. Find a navigation to another table, like Contacts, duplicate it, and change the TLA in the parameter from “CON” to “ITM”.
Now you can add fields to the ITM table and ITM layout. We held off on this so that when repointing fields from ZZZ to ITM, the field list would “line up”.