# Streamlit UX Boundaries

The FinanceManager dashboard remains a Streamlit application for the MVP.

## What Streamlit handles well

- Fast local dashboards over SQLite/runtime data.
- Metrics, cards, charts, expanders, tabs and simple forms.
- Explicit review flows with buttons and confirmation checkboxes.
- Safe local read models that do not call external APIs during render.

## Practical Streamlit UI elements used

- Summary cards via `st.metric`.
- Selection-driven details via `st.selectbox` and `st.session_state`.
- Action cards via button grids.
- Lightweight charts via `st.bar_chart`.
- Admin/debug sections via `st.expander`.
- Wizard-like forms shown only after an action is selected.

## Limitations

- True row-click UX is limited compared with a custom frontend.
- Per-row buttons inside native dataframes are awkward; selectboxes/cards are more reliable.
- Complex multi-step workflows need careful `session_state` handling.
- Styling, layout precision, responsive behavior and advanced components are limited.
- Fine-grained permissions/read-only modes are application conventions, not a full frontend security model.

## Later FastAPI + React advantages

- Real clickable tables/cards and route-based detail pages.
- Better reusable components, status badges and responsive design.
- Stronger workflow state machines for review/confirm actions.
- Cleaner separation between backend read/write APIs and frontend views.
- More professional interaction patterns for portfolio actions and review queues.

## Stack assessment

- **Streamlit** remains the MVP shell. It is good enough for local Runtime-DB dashboards, explicit buttons, compact metric cards and audited forms. Its weak spots are row-click interactions, pixel-perfect layouts and complex multi-panel workflows.
- **Dash** is attractive for Plotly-heavy analytical dashboards, but would add callback complexity without solving the portfolio workflow/audit problem as cleanly as a real app stack.
- **NiceGUI** can produce more app-like Python-only UIs than Streamlit, but it is another framework migration before the data foundation is fully stable; defer unless Streamlit blocks a concrete MVP acceptance flow.
- **FastAPI + React** is the likely long-term target once the ledger/import/valuation core stabilizes: backend APIs can enforce read/write boundaries, React can provide proper row selection, side panels, drawers, inline actions and polished responsive UX.

## Swissquote UX inspiration reviewed

Two Swissquote/eTrading screenshots from Google Drive were inspected as UX inspiration only. They were downloaded to `/tmp/finance_driveux`, not copied into the repository, and must stay out of Git.

Useful patterns adopted or kept in mind:

- A calm overview page with a small number of top metrics before details.
- Clear separation of buying power/cash, total value and daily/quality indicators.
- Portfolio sections as collapsible cards: Assets, Orders, Positions, News/Detail.
- Position tables grouped by product type/account/currency with subtotals rather than one raw dump.
- Per-row actions visible as plain user actions, while technical identifiers remain hidden.
- Search by name/symbol/ISIN and explicit export/download actions.
- Detail side panel / selected-position area is the right future pattern; Streamlit approximates this with selectboxes/buttons until a React frontend exists.

No migration is planned in this UX sprint; Streamlit remains the MVP shell.