Why the content-type picker exists

When you add a button to your app — to the tab bar, the left menu, or anywhere else a navigation item lives — the first thing MAM Suite asks is what kind of button is this? That’s the content-type picker, and it’s the biggest single decision you’ll make about that button. Everything else — its label, its icon, its settings — follows from this one choice.

The picker comes first because in a no-code app builder, a “button” is never just a button. A button that logs someone in behaves nothing like one that opens a web page, which behaves nothing like one that lists every post in a category — each needs its own settings, its own data sent to the device, its own on-tap behavior. Instead of handing you one generic button with a hundred conditional options bolted on, MAM Suite gives you a menu of pre-built behaviors and asks you to pick the one that matches what you’re trying to do.

Under the hood, each option in that menu is a content class. Knowing roughly what that is makes the picker far less mysterious, and helps you get the right choice the first time.

What a content class actually is

A content class is one type of mobile UI element, packaged up as a single unit of behavior. A Login button is a content class. So is a Map button. So is the viewer that shows a single WordPress post. MAM Suite has 19 of them loaded today, and together they’re the complete vocabulary your app’s screens get built from. If a behavior isn’t backed by a content class, a button simply can’t do it — which is exactly why “add a new content class” is how the product itself grows new capabilities.

Each content class handles three jobs at once:

1. What you see in the builder. It decides which settings tabs and fields show up when you configure a button of that type — the Login button shows authentication settings, the Web URL button shows a URL field, the Placeholder button shows almost nothing, because it does almost nothing.
2. What gets sent to the device. It assembles the data payload — the bundle of information your app downloads from your site — that the mobile app actually receives for that button. You never see this part directly, but it’s why a Map button renders a map and a Phone Call button dials a number.
3. What a brand-new button looks like. When you click “add new” for that type, the content class hands you the starting state — a blank, sensibly-defaulted button ready for you to fill in.

Here’s a useful way to think about it: the content type you pick is a contract. It promises the app a specific behavior, and promises you a specific set of settings to control that behavior. Picking the type means picking the contract.

The 19 types, grouped by what they do

The picker lists each type by its user-visible label. Below, those labels are the actual content_type values registered in the platform, grouped here by intent instead of the near-alphabetical order the picker shows them in. Use the groupings to narrow things down quickly — if the exact wording in your install differs slightly from what’s here, trust your install.

Account and identity

• Login Button — Signs the user in. It carries the app’s authentication settings, so this is more than a button — it’s where you configure how login works for the whole app.
• Logout Button — Signs the user out.

Content from your WordPress site

These are the workhorses for any app that surfaces content already on your WordPress site.

• WordPress Page Content — Renders a single WordPress page or post inside the app.
• WordPress Post Content — A detail view for an individual post.
• WordPress Post Category — A list view of every post in a chosen category.
• WordPress Post Category URLs — The same category list, but driven by a URL rather than a fixed category selection.

Choosing between these four comes down to one question: are you showing one thing or a list of things, and is the source fixed or dynamic? A single fixed page is WordPress Page Content. A single post’s detail view is WordPress Post Content. A list of everything in one category is WordPress Post Category. A list driven by a URL instead is WordPress Post Category URLs.

Going somewhere

• Web URL — Opens a web page in an in-app browser. Your go-to choice for anything that lives on the web but isn’t WordPress content you want rendered natively.
• Map — Shows a geographic map with markers.
• Make Phone Call — Tap to dial a phone number.

App features and engagement

• Favorites — The user’s list of saved items.
• Enable Push Notifications — Opens the notification center.
• Onboarding — The first-launch onboarding screens.
• Share This App — Lets the user share the app with others.
• Social Media — Link buttons out to your social profiles.
• Enable Location Services — Prompts the user to grant location permission.

Layout and structure

These don’t carry content of their own — they shape the navigation around it.

• Home Icon for Tab Bar — A tab-bar home shortcut.
• Settings Menu (Left Menu) — Opens the settings drawer.
• Placeholder Button — A decorative spacer that reserves a position in the nav without doing anything when tapped.
• Left Menu Separator — A visual divider in the left menu.

How to reason about which one to pick

The picker can feel like a long list at first, but in practice the decision comes down to a few questions, asked in order.

1. Is this navigation structure or actual content? If all you need is a spacer, a divider, a home shortcut, or the settings drawer, you’re in the layout group — and you’re nearly done, since these types have few or no settings by design.

2. Is the content already on your WordPress site? If so, you almost certainly want one of the four WP types — the choice between them just comes down to “one item vs. a list” and “fixed source vs. URL-driven.” You can reach for Web URL to show WordPress content instead, and it’ll work, but you’ll get a plain in-app browser rather than a native-feeling rendered view. When the content is yours, the WP types are the better fit.

3. Is this an app capability rather than a piece of content? Login, Logout, Favorites, Enable Push Notifications, Onboarding, Share This App, and Enable Location Services are features, not pages — you pick them because you want that capability available, and most of the behavior behind them is already built in.

4. Is it just a link out? Web URL for the web, Phone Call for a number, Map for a place, Social Media for your profiles.

A few more things worth knowing before you pick:

• Changing the type later isn’t as easy as the UI makes it look. Each type carries its own settings, so switching a button’s type means its old settings stop applying. Treat the picker as a real decision, not a placeholder — if you’re not sure yet, a Placeholder Button is the honest way to hold a slot until you are.
• Some types are more than “just a button.” The Login Button, especially, is where the app’s authentication gets configured — adding or removing it isn’t a cosmetic change.
• A type’s on-device behavior can depend on other plugins or settings. The picker always offers the same set of types, but some need supporting setup to actually work — a Map needs a maps key, and a few types lean on other MAM Suite plugins. If a type you expect isn’t behaving, or its data never reaches the device, check what that type requires before assuming something’s wrong with the picker.

Where this connects to the rest of the app

The content-type picker is the front door to a button, but it’s just the first step in a larger flow.

• After the type comes the settings. Each type’s settings are grouped into tabs — the Login Button’s “Login Settings” tab, for example. The tabs and fields you see are defined by the content class you picked, which is the direct, visible payoff of that choice.
• Settings can be site-wide or per-button. Some apply globally across the app; others only apply to the one button you’re editing — so the same type can stay consistent app-wide on some options while being tuned individually on others.
• The type determines the device payload. Everything you configure here eventually gets assembled into the data your app downloads. A content type that didn’t supply that payload would show up in the builder but render nothing on the device — which is why every type the picker offers is complete and working.

If you take one thing away: the content-type picker is choosing a behavior contract, not styling a button. Pick the behavior that matches what you’re trying to do, and the rest of the button — its settings, its payload, its on-tap action — follows from there.

Related

• Recipe: Adding a button to the tab bar (how-to)
• Recipe: Adding a left-menu item (how-to)
• Concept: Tab bar vs. left menu — where buttons live
• Plugin reference: MAM Main