AccountingNext/UI_IMPROVEMENT_PLAN.md

UI improvement plan

Analysis produced 2026-07-03. Focused on Blazor UI concerns; the IMPROVEMENT_PLAN.md covered service/repository layers.

1. Real bugs

1.1 TransactionDialog.SaveAsync will NRE if the date picker is cleared

TransactionDialog.razor.cs:37-40:

if (editContext.Validate())
{
    Content.ValueDate = SelectedValue!.Value;   // SelectedValue is DateTime?
    Content.BookingDate = SelectedValue!.Value;
    ...
}

SelectedValue!.Value throws InvalidOperationException if the user opened the dialog, cleared the date, and hit Speichern.

1.2 TransactionSplitDialog only validates the first split row

TransactionSplitDialog.razor.cs:50 builds an EditContext around the first transaction only. When the user adds a split row, subsequent rows have no EditContext — editContext.Validate() in SaveAsync returns true for the first row and completely ignores the rest. Empty text / wrong account on split rows never fails validation.

1.3 AccountSelector doesn't react to Accounts arriving late

AccountSelector.razor.cs:17-20:

protected override void OnInitialized()
{
    SelectedAccount = Accounts.FirstOrDefault(account => account.Id == AccountId);
}

OnInitialized fires once. If the parent's Accounts list is empty at that point (the async path introduced in PR P) and hydrates later, SelectedAccount stays null and the typeahead shows no preselection. Should be OnParametersSet.

1.4 The whole "year/mandator via forceLoad" architecture

MyHeader.YearChanged calls NavigateTo(..., forceLoad: true). Home.SplitBankTransactionAsync and Home.ReloadPage() do the same after any successful split. SettingsService is Singleton (documented in Extensions.cs) because the state has to survive that reload.

Symptoms:

• Full HTTP round-trip on every year/mandator switch, every split save. Tears down the SignalR circuit, blows away the scoped RepositoryCache, re-runs every repo constructor.
• No URL-bookmarkable state — you can't send yourself a link to "2023 / Mandator X".
• Multi-user hazard (already documented — single-user in practice, but the design is fragile if that ever changes).
• Client-side state loss — filters, scroll positions, half-typed inputs.

2. First-render null trap (partially patched, still fragile)

PR P's follow-up added @if (accounts is null) { <p>Lädt…</p> return; } sprinkled across ~11 pages/dialogs. Works but:

• Every page rolls its own guard. Sometimes it's @if (balance is null), sometimes @if (accounts is null || transactions is null), sometimes @if (config is not null && layout is not null && data is not null) { <PlotlyChart .../> }.
• No shared skeleton visual — just <p>Lädt…</p>. Feels unfinished.
• Collection fields are initialised to [] in some pages and left nullable in others. Two idioms in the same codebase.

A shared <LoadingWhen Data="@x" /> wrapper with a consistent skeleton visual would centralize this.

3. Home.razor is doing too much

100 lines of markup + 190-line codebehind for four unrelated concerns on the landing page:

1. Statement upload — FluentInputFile, progress bar, cancel button.
2. XML/zip file processing — OnCompletedAsync, unzip, iterate.
3. Auto-matched bank transactions table — hand-crafted <table>, <input list="texts"> for autocomplete, per-row book / split buttons.
4. Booking / split flow — BookBankTransactionAsync, SplitBankTransactionAsync.

Split into <StatementImport /> and <PendingBookings />; Home stacks them.

4. Reports vs. list pages use different visual languages

• List pages (Accounts, BookingRules, BookingTexts, Transactions, BankTransactions): <FluentDataGrid> with <PropertyColumn> / <TemplateColumn>, pagination, sortable headers.
• Reports (BalanceReport, BalanceSheetReport, DetailReport, ProfitLossReport): hand-rolled <table class="report"> with @if (account.Balance == 0) { continue; } inside <tr> and hand-crafted section headers.

Two different visual languages. Report format is domain-appropriate (they're printed accounting statements, not grids), but the hand-rolled markup means:

• Adding a column means editing 4 report .razor files.
• The @if ... { continue; } pattern inside <tr> reads oddly.
• No component reuse across reports.

Extract <ReportSection Title="…">, <ReportAccountRow Account="@x" ShowBalance />, <ReportTotalRow Label="…" Value="…" />.

5. No error boundaries, no expected-error UX

If any component throws, users get blazor-error-ui at the bottom of MainLayout.razor — a fixed div with "An unhandled error has occurred. Reload." No route back except manual reload. Error.razor is the default template that tells the user to enable Development mode.

For expected failures (save failed because file locked, unknown id on delete):

• Wrap each page/section in <ErrorBoundary> with a friendly retry.
• Route repository/service exceptions through IMessageService / IToastService (both already registered) instead of letting them bubble.

6. Feedback after mutations is invisible

Accounts.EditAsync closes the dialog and re-fetches the list. No confirmation, no "Saved" toast. If the list is long and the user's edit isn't visible in the current page, they have no signal the save worked.

Same in BookingRules, BookingTexts, Classes, Transactions.

Add toastService.ShowSuccess("Konto gespeichert") etc.

7. Confirmation dialogs show unformatted values

Transactions.DeleteAsync:

$"Transaction '{transaction.Text}' mit Betrag {transaction.Value} wirklich löschen?"

transaction.Value is a raw decimal — no currency, no thousands separator. Reads "...mit Betrag 1234.567 wirklich löschen?". Should use .ToFormattedString() and append the currency.

Same in Accounts.DeleteAsync, BookingRules.DeleteAsync, BookingTexts.DeleteAsync, Classes.DeleteAsync.

8. No search / filter on list pages

None of the FluentDataGrid pages have search or filter controls — only pagination.

• BookingRules can grow to hundreds of entries.
• BookingTexts likewise.
• BankTransactions runs into thousands over a year.

<FluentSearch> bound to a filter field, filter the IQueryable before passing to the grid.

9. Dialogs are fixed-height

DialogParameters { Height = "500px" } on every dialog. Content shorter than 500px wastes space; content longer scrolls inside. Should be Height = "auto".

Also every dialog uses the same header icon (Icons.Regular.Size24.WindowApps — a generic "window" glyph). No visual distinction between dialog types.

10. AccountSelector uses Autofocus="true"

Fine for the split-dialog flow. In the Home booking table it means every keystroke-navigated row grabs focus from wherever the user was. Should be an opt-in parameter, off by default.

11. Header year/mandator has no confirm on change

MyHeader.YearChanged immediately does a forceLoad. If the user accidentally clicks 2018 in the dropdown, whatever they were doing (unsaved dialog, half-typed booking) is gone. Fixed once (1.4) is fixed.

12. Minor rough edges

• Home.razor.cs field name IsCanceled describes an intent, not a state — cancelRequested would be clearer.
• Home.razor:35 shows a smiley emoji when no pending bookings.
• Home.razor:67 uses <input list="texts"> + <datalist> for text autocomplete — native HTML, inconsistent with FluentAutocomplete used in AccountSelector.
• Print CSS in app.css only hides .hidePrint. No @page, no page-break-inside: avoid on report rows. Long reports fragment across pages randomly.
• No accessible label on the delete/edit icon buttons (screen readers say "Button, button").
• The header $"{title} {mandator} {year}" in Report.cs reads like "Bilanz Claudio Schaad 2026" — no separator, no branding.

---

Suggested phased plan

Sequenced by value / risk. Each is one PR unless noted.

Phase 1 — Correctness bugs (low risk, high value)

• U-1 Fix AccountSelector to use OnParametersSet instead of OnInitialized so the preselection tracks late-arriving Accounts.
• U-2 Guard TransactionDialog.SaveAsync against SelectedValue == null; disable Save when the date is empty.
• U-3 Fix TransactionSplitDialog validation to cover every row (per-row EditContext, or one EditContext over a wrapper).

Phase 2 — The forceLoad/singleton trap (biggest single improvement)

• U-4 Persist year and mandator to a cookie and keep them in the URL as query params. SettingsService becomes Scoped, reading initial state from query params (fallback: cookie, fallback: config default). Header switching becomes an in-place update — no forceLoad, no circuit teardown, no state loss.

Phase 3 — Loading and error UX consistency

• U-5 Shared <LoadingWhen Data="@x"> component with a consistent skeleton visual. Adopt across every page currently using ad-hoc @if (x is null) { <p>Lädt…</p> return; }.
• U-6 Wrap each page (or the layout's @Body) in <ErrorBoundary> with a friendly retry UI. Route SaveTransactionAsync / DeleteAccountAsync etc. exceptions to IMessageService instead of bubbling.

Phase 4 — Feedback + polish for mutations

• U-7 IToastService.ShowSuccess(...) after every successful save/delete across Accounts, BookingRules, BookingTexts, Classes, Transactions.
• U-8 Format values in confirmation messages; centralize the confirmation message builder.
• U-9 Add <FluentSearch> filter to Accounts, BookingRules, BookingTexts, BankTransactions.

Phase 5 — Home page split

• U-10 Extract <StatementImport /> and <PendingBookings /> components. Home stacks them.
• U-11 Replace the Home <input list="texts"> + <datalist> with FluentAutocomplete so the autocomplete UI is uniform with the split dialog.

Phase 6 — Report componentization

• U-12 Extract <ReportSection>, <ReportAccountRow>, <ReportSectionHeader>, <ReportTotalRow>, <ReportFooter>. Apply to the four report pages. Shared print CSS + page-break-inside: avoid on rows.

Phase 7 — Nice-to-haves (optional)

• Accessibility: aria-label on icon-only buttons, focus management after dialog close, skip-to-content link.
• Dark mode toggle (Fluent supports theme override).
• Keyboard: Ctrl+S in dialogs, Del on selected row in grids.
• Header format: nicer separator + optional subtitle.
• AccountSelector's Autofocus becomes opt-in.

What was explicitly not flagged

• The de-CH culture hardcode. Correct choice for the target user; localizing is a lot of work for zero user value.
• The InteractiveServer render mode. Correct for this app.
• The Fluent UI dependency.