4th Dimension Learning Basics

Introduction: Why Menus Matter More Than You Think

In Part I of this series, we established a working vocabulary: throughout this document, 4D means 4th Dimension (now known as 4D), and FMP means FileMaker Pro. With those definitions settled, Part III turns to something that is easy to underestimate — the menu bar.

Menus are the skeleton of a database application’s user experience. Before a user ever clicks a button on a layout, they scan the menu bar to answer a basic question: what can I do here? In FileMaker Pro, that question has a fixed answer. The menu bar is largely locked down by the platform, so the developer’s only real lever is placing buttons on layouts that call scripts. In 4D, the developer gets a genuine choice — and with that choice comes responsibility.

4D allows you to create custom menu bars, menus, and menu items. That flexibility is a real advantage, but it forces a design decision that FMP developers never have to make: what should the menus actually contain? The purpose of this part is to help you decide what the basic menu bar, menus, and menu items should be in a custom 4D database. What follows is the rationale behind those choices, plus a suggested starting-point menu structure.

These suggestions are in addition to any special menus you build for program-specific needs. And they are suggestions — there will certainly be cases where they do not fit. But for the majority of databases, they deserve serious consideration.

Key Takeaways

• 4D lets you build custom menu bars, menus, and menu items; FileMaker Pro largely does not, leaving layout buttons as the FMP developer’s main tool.
• Custom menus give you power and control, but they also demand deliberate design — a menu bar is a contract with your users.
• A sensible starting point is to study what FMP, the 4D User environment, and the 4D Foundation default User environment already present, then adapt.
• Foundation is a well-regarded 4D add-on worth adopting once you have the basics down.
• Menu design should be driven by the user’s workflow, not by the developer’s internal table structure.
• Consistency across menus — naming, ordering, keyboard shortcuts — matters more than any single clever menu item.

When to Start Thinking About Menus

Once your database development is underway, you should start thinking about the mechanics of how the user will actually use what you have built. This is a shift in mindset. Early in a project you are thinking about tables, fields, relations, and code. Later — and ideally before you are too far along — you must think about interaction.

The timing matters because menu structure tends to mirror your application’s workflow. If you design menus late, you often discover that your workflow has awkward gaps: a task the user needs to perform has no natural home in the menu bar, or two menus overlap confusingly. Designing menus early forces you to articulate the user’s journey in plain language.

With FMP, since you cannot change the menu bar, you have only one option: buttons on layouts that call scripts. That constraint is not necessarily bad — it pushes everything into the layout, where the user’s attention already is.

With 4D, you have much more flexibility. In addition to buttons, you can build custom menu bars, menus, and menu items. The idea of custom menus is great and provides power and control over your database program. It also requires the developer to give serious thought to what those menus should be.

Studying the Defaults Before You Deviate

To investigate what should be considered a starting point for deciding on menus, it helps to look at what already exists. Three reference points are especially useful:

• The standard FileMaker Pro menus — a mature, widely understood convention that many of your users will already know.
• The 4D User environment menus — what 4D itself presents to users out of the box.
• The 4D Foundation default User environment menus — a third-party baseline that reflects years of practical 4D development experience.

Comparing these three reveals where conventions agree and where they diverge. Where all three agree, you have strong evidence that a menu item belongs. Where they diverge, you have a design decision to make — and usually a good reason to pick the option that matches your users’ prior experience.

A note on Foundation: for those not familiar with it, Foundation is an excellent product that can greatly enhance your 4D development. Once you have mastered the basics of 4D, purchasing Foundation is highly recommended. For information on Foundation, check DataCraft, Inc. (the vendor behind the product).

What This Part Covers

This part of the 4D Learning Series walks through:

• Definitions
• Comparison of standard FMP and 4D menus
• Creating 4D custom menus
• File menu comparisons
• File menu suggestions
• Other menu comparisons
• Records menu suggestions
• Custom splash screen

Each of these builds on the last. The comparisons establish the raw material; the suggestions turn that material into a concrete starting point you can adapt.

A Practical Framework for Deciding Menu Contents

Rather than copying any single menu bar wholesale, use a decision framework. For each candidate menu item, ask:

1. Does the user need it frequently? Frequent actions earn top-level placement or a keyboard shortcut.
2. Is it discoverable? If a user would never guess the feature exists, it needs a visible menu home.
3. Does it belong to a recognizable family? File operations, edit operations, record operations, and navigation each form natural groupings.
4. Is it destructive? Destructive actions (delete, replace) deserve careful placement and often confirmation dialogs.
5. Is it developer-only? Administrative or diagnostic items should be separated from the everyday user menu bar, or hidden entirely in a deployed solution.

A useful comparison of the two platforms’ starting positions:

Consideration	FileMaker Pro	4D
Can you change the menu bar?	Largely no	Yes — custom menu bars, menus, and items
Primary interaction tool	Layout buttons calling scripts	Buttons and custom menus
Where workflow lives	On the layout	Split between layout and menu bar
Design burden	Lower (fewer choices)	Higher (more choices to get right)
Risk	Menus may not fit your workflow	Menus may confuse users if poorly designed

The trade-off is clear: 4D gives you more control, but control without discipline produces a menu bar that is worse than the fixed one you started with.

Designing Menus Around Workflow, Not Tables

A common mistake among developers new to custom menus is to mirror the database structure. They create a menu for each table, or a menu item for each field group. This feels organized to the developer but is usually meaningless to the user, who thinks in terms of tasks, not tables.

Instead, organize around verbs: create, find, edit, print, export, navigate. These map to what users actually want to accomplish. A records-oriented menu, for example, naturally groups actions like creating a new record, duplicating one, deleting one, and moving between records — because those are all variations on the same underlying task.

This is also why the Records menu deserves its own focused treatment. Record-level operations are among the most frequently performed actions in any database, and they carry the highest risk of accidental data loss. Getting that menu right — clear labels, sensible ordering, safe defaults — pays dividends across the entire application.

Consistency, Shortcuts, and the Long Game

Two details separate a professional menu bar from an amateur one.

Consistency. Use the same verbs everywhere. If “Delete” means remove a record in one menu, do not use “Delete” to mean remove a field value in another. Users build a mental model from your labels, and inconsistency erodes trust.

Keyboard shortcuts. Power users live on the keyboard. Assigning standard shortcuts — the ones users already know from their operating system and from FMP — reduces training time dramatically. Where a shortcut is already a platform convention, follow it rather than inventing your own.

There is also a long-game consideration: menus are hard to change once users have learned them. Every menu item you add is a commitment. This is an argument for starting lean and adding deliberately, rather than shipping a sprawling menu bar on day one.

Custom Splash Screen

A custom splash screen is a small but meaningful touch. It gives your application an identity, communicates version information, and can serve as a natural place to display licensing or support contact details. In a 4D application, the splash screen is also an opportunity to orient the user — briefly explaining what the database is for and where to begin. Keep it short, keep it skippable, and never let it block the user from getting to work.

Acknowledgments

Special thanks to all those on the databasics list who offered comments and suggestions regarding custom menus. Community discussion lists like databasics were, and remain, one of the most valuable resources for 4D and FileMaker developers working through real design problems.

Frequently Asked Questions

Why can’t I customize the menu bar in FileMaker Pro the way I can in 4D?

FileMaker Pro deliberately locks down much of its menu bar to keep solutions consistent and to protect platform-level behavior. The practical consequence is that FMP developers express workflow through layout buttons and scripts rather than menus. 4D takes the opposite approach, exposing custom menu bars, menus, and menu items to the developer. Neither philosophy is inherently better — they simply place the design burden in different spots.

What is Foundation, and do I need it?

Foundation is a third-party 4D add-on that extends the platform and provides a mature default user environment, among other things. It is not required to build a 4D database, but it is widely respected and can save considerable development effort. The sensible path is to master core 4D first, then evaluate Foundation once you understand what it is replacing or augmenting.

Should I copy the FileMaker Pro menu structure into my 4D application?

Not wholesale. FMP’s menus are a useful reference because many of your users will already know them, but they reflect FMP’s capabilities, not yours. Use the FMP menus, the 4D User environment, and the Foundation defaults as three comparison points, then design a menu bar that fits your specific workflow. Where all three agree, you have a strong signal; where they diverge, decide deliberately.

How many menu items is too many?

There is no fixed number, but the guiding principle is that every item is a commitment users must learn. Start lean, group related actions into submenus, and reserve top-level slots for the most frequent tasks. If a menu item exists only for a rare administrative task, consider moving it to a separate developer menu or hiding it in the deployed solution.

Where should record-level operations live?

Record operations — creating, duplicating, deleting, and navigating between records — are frequent and often destructive, so they deserve a dedicated Records menu with clear labels and safe defaults. Grouping them together matches how users think about the task and makes it easier to apply consistent confirmation behavior for anything that can lose data.

Do keyboard shortcuts really matter for a small-team application?

Yes. Even in a small deployment, a handful of power users will do the bulk of the data entry, and shortcuts dramatically reduce their effort. More importantly, following platform-standard shortcuts lowers the learning curve for everyone, because users can transfer habits they already have from their operating system and from other database tools.

---

Copyright