Why navigation is a design decision, not a default

Every screen you build is really a small decision: how does someone get from opening the app to doing the thing they came for? MAM doesn’t hand you one fixed navigation pattern. Instead you get three independent navigation surfaces, each with its own builder panel, its own data, and its own behavior in the app:

• Home buttons — the grid of buttons (often shown as icons or cards) that fills the app’s first screen.
• The left menu — the slide-out drawer reached from the menu icon, holding secondary and account-related destinations.
• The bottom tab bar — the persistent strip across the bottom of the screen, present no matter which screen the user is on.

These aren’t three views of the same list. Each surface is configured separately, can carry a different set of buttons, and can be set per user role. That independence is the point: it lets you put a small number of high-traffic destinations where the thumb naturally lands, keep the home screen scannable, and tuck the long tail (Settings, Contact Us, legal pages, log out) out of the way without deleting it.

Getting the split right matters because all three surfaces are competing for the same scarce resource — the user’s attention in the first few seconds. A coherent app uses each surface for what it’s good at. An incoherent one duplicates the same buttons across all three, or buries a primary action in the drawer. Here’s what each surface is good at, so you can make that call on purpose.

The three surfaces, concretely

All three are configured under Mobile App Manager → App Setup (and the related Navigation pages), and all three ultimately feed into the JSON payload — the bundle of data the app downloads from your site — that the mobile app pulls down.

Home buttons — the front door

The home screen is built in Home Page Design on the App Setup page. Here you add buttons one at a time, pick the content each one points to, and arrange their order. The builder’s own subtitle captures the intended workflow: “Add a button. Pick your content. Change the background. Add social media. Publish.”

Under the hood, these are the buttons MAM fetches for the main location. They’re the primary content of the app — the directory, the events list, the shop, the featured screen — surfaced as the first thing the user sees. Home buttons are the most prominent surface, and the one you should treat as your app’s table of contents.

Use home buttons for the handful of destinations that are the reason the app exists. If a user opens the app to browse listings, “Listings” belongs here. Order matters; the most important button should be first.

The left menu — the drawer for everything else

The left menu is built in Left Menu Design, a separate tab on the App Setup page. Its builder puts audience front and center: “Manage content for the left menu for each role.” You add buttons the same way you do on the home screen, but they’re fetched for the left location and rendered by a dedicated content class (mam_main_left_menu) — a technical label for the code that draws the drawer — as a vertical list inside the slide-out drawer.

That setup has a few consequences:

• Some content types are left-menu-only. The left-menu separator, for example, carries a left_menu_only flag, so the home-screen content-type picker hides it — it only makes sense as a divider inside a vertical list. In other words, some elements are built for the drawer and nowhere else.
• The left menu is the natural home for secondary and account destinations: Settings, My Profile, Contact Us, About, Terms, Log In / Log Out. These need to exist but should not crowd the first screen.
• Because the drawer is a scrolling list, it scales. You can put many entries here without the visual cost the same number of home buttons would carry.

Use the left menu for things users need occasionally — account, support, legal, and overflow navigation that does not earn a spot on the home screen or tab bar.

The bottom tab bar — always-on, thumb-reachable

The tab bar is the persistent strip across the bottom of every screen. It is configured under Mobile App Manager → Navigation → Tab Bar, and unlike the other two surfaces it is present everywhere — it does not scroll away when the user drills into a detail screen.

Here’s what makes it behave differently, straight from how the manager works:

• It holds a small, fixed number of slots (up to five). This is a hard design constraint, not a soft suggestion; the tab bar is for the few destinations a user returns to constantly.
• Each slot has a title, an icon, and a “Show Button” visibility toggle. A slot whose visibility is off is skipped entirely at request time — the app never even looks for it.
• Tab bar configuration is per role. You switch the role selector and configure each role’s tab bar separately, so a staff member and an anonymous visitor can see different tabs.
• The home screen itself can optionally be presented as a tab (the use_tabs_for_homepage behavior), which folds the front door into the tab bar rather than showing it as a standalone screen.

There is also a second, related use of “tab bar buttons”: individual screens can attach their own per-listing tab bar buttons (Edit, Share, Call, Approve) that appear when a user is on a detail screen. Those are configured on the button’s own Tab Bar Manager sub-tab (the mam_main_tab_bar_manager admin UI, which manages tab bar buttons on list-type nav buttons) and are a different thing from the app-wide bottom tab bar — same name, different scope. Keep the distinction in mind: the app-wide tab bar is global navigation; the per-screen tab bar buttons are contextual actions.

Use the tab bar for the two-to-five destinations a user comes back to most — the ones worth keeping one tap away from any screen.

How to choose: a model for splitting destinations

A simple way to sort destinations onto surfaces: ask how often and how urgently a user needs each one.

Two rules keep the result coherent:

1. Do not duplicate the same destination across all three surfaces. A little overlap is fine — it is common for one or two anchors (Home, a primary list) to appear both as a home button and a tab. But if every button is on every surface, none of the surfaces is doing its job, and you have spent your most valuable space saying the same thing three times.
2. Respect each surface’s capacity. The tab bar’s small slot count is a feature: it forces you to choose. If you find yourself wanting a sixth tab, that destination probably belongs on the home screen or in the left menu instead.

Because every surface can be configured per role, you can also let the audience drive the split — give logged-in members a richer tab bar, keep the anonymous-visitor home screen focused on a single call to action.

How the three surfaces connect to the rest of MAM

These three surfaces don’t work in isolation. The same button you create can live on the home screen or in the left menu — what changes is where you place it, not how you defined it. That’s why a Contact Us form, for example, can appear as a home button or a left-menu entry without you building it twice. Both placements draw from the same pool of buttons you build in the App Setup page.

Each surface contributes a different part of the phone-data payload the app downloads: home buttons and left-menu buttons are emitted as button lists, while the tab bar (and the home-screen stack, when the home screen is composed as a stack of sections) emit their own structures. Sibling plugins extend all of this through filters — WordPress hooks that let a plugin plug in without touching your site’s core code — so a plugin can inject a tab bar button, add a content type that’s left-menu-only, or contribute a home-screen section, all without you touching code.

The practical takeaway: decide the navigation model first — what goes on the home screen, what goes in the drawer, what earns a tab — and the per-button, per-role, and per-plugin settings all hang off that decision.

Related

• Concepts: How a MAM app is structured — tabs, screens, and buttons
• Concepts: Role-based settings — per-button, per-role, and global
• Recipe: Configure the tab bar
• Recipe: Add a button
• Plugin: mam-contact-form (an example of a button placed on the home screen or in the left menu)