You have room for one persistent control on a phone. The sales team wants “Book a demo”. Support wants Chat. The website team wants Search. Put all three in a bar and the page gets crowded. Pick one button and someone worries that the other two have disappeared.
The choice starts with how many jobs genuinely need to follow the visitor. A floating action button, often called a FAB, is one prominent button that stays above the page. An extended FAB includes a short text label. A floating action bar is a compact strip with several actions visible at once. Both sit above ordinary page content; neither deserves its place merely because it looks good in a design file.
Choose a button when one action clearly outranks the alternatives on that page. Choose a bar when a small group of different actions all need persistent access and can stay understandable together. If neither case is strong, keep the actions in the page. That third option deserves a place in the decision.
Count real jobs, not stakeholder requests
Write down the visitor's next plausible tasks before choosing a shape. “Can I see the price?”, “I need to ask a question”, and “I am ready to book” are different jobs. “We want more clicks on three campaigns” is one business wish spread across three buttons.
Google's Material guidance for a FAB describes it as a high-emphasis control for one primary action in an app. That is a useful design principle, but a website has its own navigation and content. Do not transfer an app pattern to every marketing page as a rule. A website visitor may still be reading or comparing options; forcing a single conversion action to follow them everywhere can pull attention away from that work.
Ask three questions:
- Is one action plainly the next step on this page? If yes, a labelled button may be enough. “Book a demo” is clearer than an unlabelled calendar icon.
- Would hiding another action make a common task harder? If someone reading a long help page may need Search and Contact at different moments, a compact bar may earn its extra space.
- Are we duplicating the page? If the primary CTA is already visible beside a form, a floating copy may add noise without helping anyone reach it.
A one-button control that opens a tray of four unrelated links is no longer a simple one-action choice. The tray becomes a small menu: people have to discover it, understand it, open it and move through it. Review that interaction on its own terms rather than calling it a space-saving button.
Work through a page with two competing needs
Imagine an illustrative software pricing page. The top shows plan differences; lower down is a “Book a demo” form. Visitors also ask detailed questions about integrations, so the site has a chat provider. The mobile design offers either a single “Book a demo” floating button or a three-item floating bar with Book a demo, Chat and Search. No figures in this example are measured customer results.
First, watch the tasks. A visitor at the top may still be comparing plans, so a permanent booking button is not automatically the best help. Search is already in the site's menu. Chat appears from its provider launcher when needed. The first cut is to remove Search from the persistent set and decide whether the native chat launcher can coexist with a booking control. If not, do not solve the clash by stacking them.
Next, inspect the form section. The page already has a clear “Book a demo” button there. A persistent booking button that sits over the form's Submit button is worse than the existing page CTA. At this point the strongest option may be no floating control on the form route. Keep the booking CTA in content and let the provider's chat control remain available, provided it does not cover the form.
Now change the page: imagine a long comparison guide with no form and many sections. Visitors may reasonably need both Search and Contact while reading. A short, labelled bar could help there. Test whether those two actions remain legible on the narrowest supported width, whether the last paragraph and links remain usable, and whether chat yields to the bar when it opens. The choice changed because the visitor's page and task changed, not because one visual pattern won a popularity contest.
That is the decision rule to keep: one dominant task suggests a button; several recurring, distinct tasks may justify a bar; a task already well served in content may need neither.
Make each visible action understandable
A compact button saves width, but “compact” is not the same as “clear”. A plus icon could mean add, open a menu or expand a panel. If the action is unfamiliar, use a visible label or another explicit cue. A screen reader also needs a useful accessible name. If visible text says “Book a demo”, the accessible name should include it; WCAG Label in Name explains why that matters for speech-input users.
A bar gives actions more room to be seen together, but long labels can create a different problem. At a narrow width or with larger text, a three-item row may clip the one phrase a visitor needs. WCAG Reflow requires most vertically scrolling content to rearrange at a 320 CSS-pixel width without losing information or function, subject to its exceptions. A CSS pixel is the browser's layout unit, rather than a physical screen dot. Check the actual copy, not placeholder labels.
Both patterns need usable tap areas. WCAG Target Size (Minimum) sets a 24 × 24 CSS-pixel threshold with specified exceptions, including spacing. This is a floor. If three actions only fit by shrinking every target and label, your priority decision needs another pass. Keep important actions named; do not make hover the only way to learn what an icon does on a touch screen.
Compare the outcome beyond clicks
A bigger bar may attract more taps because it is bigger. A button may get fewer taps because it is less clear. Neither number tells you whether people completed the job they came to do.
Before a test, name the outcome. On the illustrative pricing page it might be completed demo submissions, with form-error rate and chat starts as supporting signals. Record whether the control was visible, whether someone used it, whether they reached the destination and whether they completed the task. Compare mobile pages and audiences that actually saw the same design. A click on Chat is a useful action, but it is not a substitute for a completed demo form if that was the page's purpose.
Also give the test a guardrail: a result you do not want to worsen while chasing more CTA clicks. For example, if the bar increases clicks but form completion falls or the final page links become harder to use, treat that as a problem. This is an editorial decision rule, not a claim that a particular shape improves conversion. A fair experiment requires suitable assignment and measurement; changing the page and traffic mix at the same time makes the comparison hard to interpret.
Be clear about what Barrava can make
Barrava currently renders call-to-action (CTA) buttons inside an ordered docked or floating toolbar. One CTA is available in the core bar; a second is available on Starter or higher, subject to the account's current entitlement. Both sit within the same rail alongside other configured actions. The floating toolbar is a bar, even when it contains only one CTA. Legacy fab and extended-fab values in configuration do not select a separate standalone FAB treatment in the current runtime.
That matters if you are comparing tools. This article helps you choose the design pattern for your page; it does not claim Barrava will generate both shapes. If a standalone FAB is the right answer, plan and test that implementation separately. If several actions need a shared persistent home, Barrava's website toolbar can support a floating or docked ordered bar. The mobile actions guide covers the page spacing, keyboard and collision checks you should run once you have chosen a pattern.
Next step: Take one real mobile page, list the visitor's continuing tasks, and remove every persistent action you cannot justify. Then test the smallest pattern that still lets people finish the task.
