[Feature] [UI/UX] Standardize barcode scan button size across all food logging screens, bigger is better

[maxerbox]

What problem does this solve?

Barcode scanning buttons have inconsistent sizes across the app, creating a confusing user experience:

• Meal Editor (when adding ingredients to a meal/recipe): Large button with full icon + label visibility
• Foods screen: Medium inline button within the search bar
• Diary quick-add (logging a meal to the diary): Very small icon button
• Food Editor (creating/editing a food): Small inline button next to barcode input

This inconsistency makes some scan buttons hard to notice or tap, especially on mobile. Users expect the scan button to be prominent and easy to access in all contexts, since barcode scanning is a primary feature for quick food logging.

Proposed solution

Standardize all barcode scan buttons to use the large, prominent style currently seen in the Meal Editor ingredient picker. The big button:

• Makes the feature discoverable and easy to tap
• Provides clear feedback that scanning is available
• Improves mobile usability (larger tap target)
• Matches the prominence of other primary actions (Add buttons, Save buttons)

Implementation approach:

1. Define a reusable ScanButton component (or CSS class .btn-scan-prominent) with:

   • Button class: btn btn-primary or btn btn-accent
   • Icon: barcode_scanner (material-symbols-rounded)
   • Label text: "Scan" or "Scan Barcode"
   • Consistent height/padding across all instances

2. Update all barcode scan button locations:

   • MealEditor.svelte (line 954): ingredient picker header — already large, use as reference
   • Diary.svelte: quick-add meal logging flow — make prominent
   • Foods.svelte (line 887): foods search bar — upgrade from inline to prominent
   • FoodEditor.svelte (line 854): barcode input section — upgrade from inline to prominent

3. Consider placement:

   • In modal headers (Meal Editor picker): small icon button is OK
   • In main screens and dialogs: use large button with label
   • Avoid tiny inline buttons unless space is extremely constrained

4. Accessibility:

   • Ensure all buttons have aria-label="Scan barcode" or title="Scan barcode"
   • Min tap target 44×44px (iOS) / 48×48dp (Android)

Alternatives you've considered

1. Icon-only buttons everywhere: Harder to discover, doesn't solve the inconsistency
2. Keyboard shortcut (e.g. Ctrl+B): Good supplement but doesn't fix the UI consistency issue
3. Quick-access FAB (floating action button): Could work but adds clutter when multiple actions exist

Additional context

Current implementations:

• Large (Meal Editor, line 954):

  <button class="btn-icon" on:click={() => _pickerScannerOpen = true}>
    <span class="material-symbols-rounded">barcode_scanner</span>
  </button>

[thebigjoe1]

Implemented in my dev environment and will go out with the next public RC.

Took a slightly different angle than full-size buttons everywhere, since the Foods search bar and the Food Editor barcode field both rely on the dense pill layout, going prominent there would either push the input much narrower or break the pill into two stacked controls. Instead:

New shared .btn-scan-inline class: accent-tinted circular pill, visible at ~30 px, with the tap target extended to 44 × 44 via a transparent hit area. Meets the iOS / Android accessibility floor without changing the layout.
Foods (also where Diary → Add Food lands you) and the Food Editor barcode field both use the shared class now, so the two inline scan buttons match each other.

Meal Editor picker stays as the existing .btn-icon since you flagged it as the right size for a constrained modal header.
Net result: scan icon is more discoverable (accent color, filled circle vs. muted line glyph) and properly tappable on phones, search experience stays compact. Same icon, same aria-label, same hit target across all entry points.

Will post back when this lands in a public build and ask you to verify before closing.