TL;DR
Confirmed: Same-day updates + layout changes + 2-MEC pilot (DAL/UAL) = Full SDUI required
Timeline: September 2026 launch, October hardening, ~6 months development
Next: Finalize look & feel, performance, and content requirements (Q6–Q9) to select SDUI approach
Architecture decision: March sprint (FlagstoneUI vs JSON SDUI vs Blazor Hybrid vs Mixed)
✅ Requirements Confirmed
Update Requirements
- Speed: Same-day updates required (within hours)
- Types: All change types needed:
- Content (text, images, articles, videos)
- Styling/branding (colors, fonts, logos per MEC)
- Layout structure (rearrange sections, add/remove screens)
- Navigation (add/remove menu items, change tab order)
- Feature flags (show/hide per MEC)
- A/B testing capability
Impact: Rules out app store releases as primary deployment. Full SDUI architecture required.
Launch Plan
- Pilot MECs: DAL and UAL (2 MECs)
- September 2026: Launch deadline
- October 2026: Hardening period (stabilization, bug fixes, performance tuning)
- Beyond October: Rollout to additional MECs
Timeline: ~6 months from now to September launch
MEC Customization
- Answer: Planning for different layouts per MEC
- UAL may have different home screen structure than DAL
- Requires full layout rendering engine (not just content/styling swap)
Impact: Rules out simple solutions (CMS + themes). Need JSON SDUI renderer or Blazor Hybrid with layout composition.
Offline & Backend
- Offline: Existing caching strategy supports SDUI (background sync, cache-first)
- Backend: Infrastructure planning deferred until architecture finalized
- Security: HTML content from trusted ALPA sources only (no external sandboxing)
🎯 Architecture Decision Path
Based on confirmed requirements, SDUI is mandatory. Remaining questions determine which SDUI implementation:
📊 Expand: SDUI Options Summary
JSON SDUI (Custom Renderer)
What: Backend sends JSON layout schema, app renders to native MAUI controls
Pros: Full control over rendering · Platform-specific handlers (iOS glass + Android Material) · Native performance · Supports different layouts per MEC
Cons: Must build and maintain renderer · Higher initial development cost · More testing surface area
Effort: 12–16 weeks · Best for: Maximum flexibility, native look, performance critical
Blazor Hybrid
What: WebView-based Razor components with native API bridge
Pros: Web development skills (HTML/CSS/JS) · Rich component ecosystem · Dynamic CSS for per-MEC styling · Fastest to market
Cons: WebView performance (<400ms target, may require optimization) · Cannot achieve native iOS glass effects · Prior WebView bugs (#1891) · ~8MB app size increase
Effort: 8–12 weeks · Best for: Rapid development, web-like content acceptable, HTML from CMS
FlagstoneUI + JSON SDUI (Hybrid)
What: FlagstoneUI controls for pixel-perfect consistency + JSON SDUI for dynamic layouts
Pros: Visual consistency across platforms · Dynamic layout updates · Native performance · No platform handler code
Cons: FlagstoneUI v0.0.1 (only 4 controls, experimental) · Must wait for maturity or build missing controls · Complex hybrid approach
Effort: 14–20 weeks · Best for: Pixel-perfect consistency + dynamic updates, if FlagstoneUI matures quickly
Mixed Architecture (Native + Blazor)
What: Native MAUI for performance screens, Blazor for content screens
Pros: Best of both worlds · Flight Finder/FAR 117 stay fast · Content screens get instant updates
Cons: Inconsistent UI feel (native vs web) · Two codebases to maintain · Users may notice the difference
Effort: 10–14 weeks · Best for: Balancing performance + flexibility, if mixed UI acceptable
❓ Outstanding Questions (Determine Architecture Choice)
Look & Feel (Q6)
- Visual consistency priority (pixel-perfect vs platform-native)?
- iOS glass UI desired (blur effects, translucency)?
- Android Material Design 3 (dynamic color, elevated surfaces)?
- Web-like experience acceptable for content screens?
- Mixed architecture OK (native + web)?
Why it matters: Determines if Blazor viable, if JSON SDUI needs platform handlers, if FlagstoneUI needed
- Acceptable load times per screen type (performance-critical vs content vs settings)?
- Unacceptable issues (laggy scroll, slow transitions, delayed taps)?
Why it matters: Strict performance (<200ms) rules out Blazor for those screens. Relaxed (1–2s) makes Blazor viable.
Content Richness (Q8.1)
- Simple text/buttons? Rich formatted text? Embedded media?
- Interactive elements (polls, forms, quizzes)?
- HTML from CMS (WordPress, SharePoint)?
- PDFs inline or download?
Why it matters: HTML from CMS strongly favors Blazor Hybrid or WebView components.
Risk Tolerance (Q9)
- Priority ranking: instant updates / visual consistency / native performance / stable tech
- Comfort level: experimental tech (FlagstoneUI v0.0.1) / WebView-based UI (Blazor) / custom-built renderer (JSON SDUI) / mixed architecture
Why it matters: Risk tolerance + stability priority = choose mature Blazor over experimental FlagstoneUI or DIY JSON SDUI.
March Sprint Plan — SDUI Pilots
Week 3–4 (Mar 17–31): Architecture validation (stretch goal, if capacity allows)
- Pilot A: JSON SDUI Renderer (3–4 days) — Build minimal renderer (StackLayout, Grid, Label, Button, Image); test with Home Screen layout composition; deliverable: POC + architecture decision doc
- Pilot B: Blazor Hybrid POC (2–3 days) — Implement 1 content screen; measure performance (<400ms load, 50+ FPS target); test WebView behavior (iOS vs Android)
- Pilot C: FlagstoneUI Evaluation (2–3 days) — Clone and test FlagstoneUI sample; assess control coverage vs ALPA needs; decision: pilot on 1–2 screens vs wait for maturity
Note: SDUI pilots are nice-to-have in March. If bug triage and feature work consume capacity, pilots defer to Q2.
Next Steps
- Requirements questionnaire shared
- Schedule workshop with Communications team (1–2 hours)
- Complete Q6–Q9 (look & feel, performance, content, risk)
- Run architecture pilots (March Week 3–4 if capacity)
- Architecture decision by March 31
- Q2 Implementation begins (April)
Attachments
Questions or concerns? Let me know.
— José