User Interfaces in FileMaker Pro

Every new FileMaker Pro database essentially begins with a single, blank layout. User interface designersand, yes, you're now one by definitionoften have to approach each solution they design somewhat differently, to tailor it for the specific use in question, for the users for whom the system is ultimately intended, and in keeping with the time/budget/scope variables we all struggle with in some form or another. This chapter is not intended to present a complete user interface discourse. How to approach a user interface is a widely debated topic in both the FileMaker and the computer science worlds. On the Web, as you no doubt know, what works for one site doesn't often work for anothernor should it. We won't presume to know what the world's most perfect user interface might be.

Rather than trying to present the "what" or "why" of user interface and layout design, we're going to focus on the "how." There are some constants in FileMaker interface design: Almost every database solution ever built has some form of navigation, meaning a button-and-scriptdriven means of moving from layout to layout. Data presentationhow you view and access information in your systemvaries, and we explore some of the options there as well. We also examine how to approach working with multiple windows, and delve into FileMaker 8's new Custom Menus feature as well.

This chapter presents several topics. Each section could comfortably stand on its own; the idea here is to present you with some ideas you can apply to your solutions as you see fit. The chapter assumes a moderately advanced familiarity with FileMaker Pro, but beginners should be able to grasp the concepts quite easily, if they don't immediately understand the implementation.

User interfaces are central to most FileMaker databases. It is rare (although entirely possible) that a FileMaker database would serve only as a back-end data repository, with some other system providing a visual front end. Custom web-published databases are an obvious exception, but many FileMaker-based web systems also have administrative or data-entry functions built into native FileMaker Pro layouts and accessed with FileMaker Pro, not to mention IWP (Instant Web Publishing) that depends on layouts being created in FileMaker. Some FileMaker systems also serve as front-end extensions of larger systems through ODBC or XML connections; one of the core reasons organizations choose to use FileMaker in such cases is the rapidity and flexibility with which interfaces can be built. It's safe to say that not only is storing data fundamental to FileMaker Pro, but the presentation of data is fundamental as well.

Figures 13.1, 13.2, and 13.3 present some interface examples we've come across in our travels.

Figure 13.1. This is a fairly typical example of a tabbed interface in FileMaker Pro; the tabs in this example have been created as graphic objects.

Figure 13.2. FileMaker Recruiter 2.0, produced by FileMaker, Inc., itself, is a solid example of a classic design. Notice the two tiers of navigation with the section headers at the top of the window.

Figure 13.3. Here's a different twist on user interfacelean, with lots of whitespace and navigation in more of a web-style approach.

Primary considerations when you approach designing a user interface include how to trigger functions specific to your database solution (for example, a series of scripts that create monthly invoices), how to manage creating and deleting records, whether to build some form of interface to help with Find requests, and how a user might run a report.

Other issues will also need to be worked out: What color scheme do you want your user interface to follow? How much screen real estate do you have? What fonts will work for all the users in your system?

Tip

We recommend two things when defining an interface for a new solution. First, define one. Rather than having things just evolve at random, you'll be well served by spending a few minutes up front coming up with a standard interface approach.

Second, create a prototypical layout and menu set for your system and then test it with users before building the rest of your system. Establish a common standard for where things go, how large the screen is, how portals look, where field labels sit, and how you'll use menus, and then get buy-in from the people who will ultimately live with the database day in and day out. It's far easier to spend a little time in the beginning discovering that your boss deeply loathes the color green than to go back and rework your database.

When moving forward in your system, it will be easier to duplicate your template layout than to start from scratch each time. This also saves time: After the problem of look and feel is solved, you won't need to spend more time thinking about it as you create new layouts.

FileMaker's Native User Interface

Another critical consideration for your user interface (UI) is to what degree to use FileMaker's own native elementsthe Status Area, menu commands, and Scripts menuor how to go about replacing them with your own buttons, scripts, or custom menus.

It is entirely possible to build a perfectly usable FileMaker database without adding a single button to any of your layouts. Users can rely on the Layout pop-up menu in the Status Area and, for those reports and functions that require scripts, turn to the Scripts menu, or to any special menus you may have added as custom menus. Relying heavily on FileMaker's native UI delivers some significant benefits in the time it takes you to build a database. Your users are likely already to understand at least some of the basics of working with a FileMaker database as well. This bare-bones approach can "just get it working" quite quickly. The downside, aside from simple aesthetics, is that your database may not be particularly intuitive for nondevelopers to manipulate in cases in which your data structure becomes complex.

We strongly recommend embracing FileMaker's raison d'étre: flexibility. Although it's possible to pull off some quite advanced custom-crafted user interface designs, make sure that you take on added complexity deliberately, by choice, and recognize the cost.

Tip

Be sure if you use a native approach in FileMaker to do so fully and make use of its security. You can still leave FileMaker's menu commands available to your users if you carefully think through your security setup.

You can also disable the native menu choices you don't want used, or override them with your own custom scripts, by creating custom menu sets. Refer to the section "Working with Custom Menus," later in this chapter.

Building Your Own Interface

The alternative to a native FileMaker approach is to replace the Status Area and menu functions with your own buttons, scripts, and custom menus. The approach here gives you the most control, but also signs you up for the most work. (Notice that the Status Area seen Figure 13.2 is closed. The designers of this system replaced the functions of the Status Area with their own buttons elsewhere on the layout.)

When following such an approach, you will need to replace all the functions of the Status Area in three of the four modes (it is not possible to replicate its functions in Layout mode), and you'll likely opt to close and lock the Status Area after you've done so.

This process is identical in nature to building other interface elements: You will need to create objects to serve as buttons (images, text, or some other FileMaker layout object) and then create scripts to replicate the functions of the Status Area, such as "go to next record" or "go to previous record." One of the more challenging elements of re-creating all the functions of the Status Area can be the Omit check box control while in Find mode.

By using FileMaker Pro 8 Advanced, you can leave elements of native FileMaker functionality available while locking down just those you need to restrict. This mix-and-match approach is one of the best reasons to upgrade to FileMaker 8.

Interface Look and Feel

Remember that container fields, as well as graphical objects pasted onto a layout, can be turned into buttons and thus associated with a script action. This enables you to design quite complete user interface elements in the image-editing software of your choice. Buttons can be far more than simply gray rectangles, and it's quite possible to create a user experience that feels nothing like FileMaker in its native state.

We recommend that you insert all such graphical UI elements into container fields set for global storage, rather than pasting them directly on layouts. If you ever need to make a change, you need only do so in one place, rather than having to paste a modified element back onto all the layouts on which it was used and reapply its script or button behavior.

To use this container method, simply create a single repeating container field, set to global storage. Then when placing buttons on your layouts, instead of placing the graphic element itself, simply place a field with the proper dimensions and set it to show repetition X through X (say 3 through 3) to display the applicable graphic. Then attach a button behavior to that field. From this point forward in the chapter, when we speak of placing button objects on a layout, this is the method we prefer, but we will not reference it continually throughout the chapter.

Tip

Remember, when you are placing a button object on multiple layouts, first apply the script behavior to the object, and then copy and paste on all layouts with the button behavior intact.

For maximum control, it's even possible to create a kiosk experience in FileMaker Pro that takes complete control of the screen. FileMaker's menus will not appear in kiosk mode, and you can choose to close and hide the Status Area as well. For all intents and purposes, the entire look and feel of the screen will be in your hands. A kiosk typically isn't something you'd want to deploy for use on desktops: It takes over the entire screen and isn't well suited for working with other applications.

Single File Interface Versus Distributed Interface

Aside from the approach of building an interface, its architecture should be considered as well. One of the most frequent questions we receive is whether it is better to build a solution as a single file or to create a distributed architecture across multiple files. There are a wide variety of opinions on this topic in the FileMaker community, and some experts strongly advocate one approach over the other. Our answer is less definitive: It depends.

A single file system, with all your interface layouts in one place, is generally easier to build and requires less architectural overhead. FileMaker 8's capability to reference external table occurrences makes the overhead arguably minimal in some cases, but you will need to replicate security settings, value lists, and custom functions in each file separately, and you will need to work out window management and navigation schemes to support multiple files. (Although, again, it's possible to build all of your interface in a single window that then references a separate or multiple data files, so...it depends.)

A multiple file system (possibly with interface layouts in multiple files) has the benefit of allowing multiple developers to work on each file in parallel (whereas working in Script Maker or making database schema changes can be done by only one person at a time), as well as keeping FileMaker elements organized in discrete, separate packages. A single file system tends to balloon with scripts, value lists, and layouts. In a multiple file system it's possible to isolate those elements to just the functionality or operational group necessary. As an example, you might put all your customer-related interfaces in a Customers file, and all of your finance-related interfaces in a Finance file.

In our consulting practice, we implement systems with both types of architectures. Generally, smaller systems end up as single file systems, and larger systems (ones with more than 40 or so data tables) have to some degree tended to be distributed. This is a somewhat specialized observation, though: We tend to create distributed file systems to support multiple developers, which generally is not an overriding concern for many organizations.

Obviously, there might be times when you have no choice: Your database might have been converted from a version before FileMaker 7, in which case you'd need to do substantial rewriting to bring the interface elements into one file. It is often best to live with the separate files created by the conversion process, given that security settings, and so forth, have already been replicated for you during conversion.