UI .NET quando l'interfaccia deve aiutare il lavoro, non rallentarlo

UI .NET: quale tecnologia per quale problema

L'ecosistema UI di .NET è ricco e a volte confuso: WPF, Windows Forms, Blazor, .NET MAUI, Avalonia.

Ogni framework ha un caso d'uso primario e contesti dove non è la scelta giusta.

Usarli senza questo criterio produce applicazioni che funzionano ma che costano troppo da mantenere o che non soddisfano i requisiti reali.

WPF è la scelta per applicazioni desktop Windows con interfacce ricche, binding complessi e rendering vettoriale. È maturo, stabile e ha il migliore supporto per scenari enterprise Windows-only. Non è cross-platform.

Windows Forms resta valido per applicazioni desktop semplici con team che lo conosce bene. Non ha le capacità di rendering di WPF, ma per form di inserimento dati, griglie e workflow interni è produttivo e facile da mantenere.

.NET MAUI è la scelta per applicazioni che devono girare su iOS, Android, Windows e macOS con un unico codebase .NET. È più giovane degli altri e ha ancora aspetti da maturare, ma per team .NET che devono coprire più piattaforme mobile è la scelta più coerente con lo stack esistente.

Blazor è la scelta per interfacce web interattive scritte in C#. Blazor Server e Blazor WebAssembly hanno modelli di esecuzione diversi con trade-off diversi su latenza, offline e scalabilità.

Design di una UI che aiuta il lavoro: i principi che cambiano i prodotti

Una UI tecnicamente corretta che gli utenti trovano difficile da usare è un fallimento.

Non serve implementare perfettamente MVVM se il flusso di lavoro che l'interfaccia supporta richiede dieci click per fare qualcosa che si faceva in due con la versione precedente.

Il principio fondamentale è che l'interfaccia deve modellare il lavoro dell'utente, non la struttura dei dati del sistema.

La differenza è sottile ma decisiva: un sistema che espone le sue entità (Cliente, Ordine, Prodotto) come schermate separate forza l'utente a costruire il contesto nella propria testa.

Un sistema che espone i task (Gestisci ordine cliente, Elabora reso) riduce l'attrito perché corrisponde al modo in cui l'utente pensa al suo lavoro.

La gestione dello stato è il secondo principio critico: quanto stato deve mantenere l'interfaccia, dove viene salvato, cosa succede se l'utente chiude per errore.

In un'applicazione desktop complessa la perdita di dati non salvati è un problema di UX prima ancora che tecnico.

Il feedback immediato sulle operazioni lunghe non è un dettaglio: è la differenza tra un'interfaccia che sembra responsiva e una che sembra bloccata.

Progress indicator, operazioni cancellabili, aggiornamenti asincroni: sono investimenti che l'utente nota e apprezza anche senza saperli nominare.

.NET MAUI e cross-platform: quando funziona davvero

La promessa del cross-platform è scrivere il codice una volta e farlo girare ovunque.

La realtà è più sfumata: il codice di logica è davvero condiviso, ma la UI richiede attenzione alle differenze tra piattaforme perché iOS e Android hanno paradigmi di navigazione, gestione della tastiera e stili visivi diversi.

.NET MAUI gestisce queste differenze con il concetto di renderer nativi: i controlli MAUI vengono renderizzati con i controlli nativi di ogni piattaforma.

Il risultato è un'applicazione che si sente nativa su ogni sistema operativo, ma che richiede testing su ogni piattaforma perché il comportamento può differire nei dettagli.

I casi dove MAUI dà il massimo valore sono le applicazioni enterprise interne dove la coerenza visiva cross-platform è meno critica della produttività del team e del riuso di logica di business esistente in .NET.

I casi dove va valutato con più attenzione sono le applicazioni consumer dove l'aderenza alle convenzioni native di iOS o Android è un requisito di mercato.

Shell di MAUI semplifica la navigazione e la struttura dell'applicazione.

Il ciclo di vita, le permission, l'accesso all'hardware (camera, GPS, sensori) richiedono tutti gestione platform-specific anche con MAUI.

Accessibilità e performance nelle UI .NET: non sono optional

L'accessibilità nelle applicazioni desktop e mobile non è un requisito opzionale per nicchie specifiche.

È un requisito legale in molti contesti enterprise e pubblici, e un indicatore della qualità del prodotto.

In WPF l'accessibilità si costruisce con AutomationProperties, che forniscono il testo che i screen reader leggono agli utenti non vedenti.

In MAUI ogni controllo ha proprietà di semantica accessibile.

In Blazor si seguono le stesse regole ARIA del web.

Non richiedono un grande investimento se integrate fin dall'inizio; richiedono un refactoring costoso se aggiunte alla fine.

La performance delle UI si misura in modo diverso da quella del backend: l'obiettivo è la fluidità percepita, non il throughput.

Un'operazione che dura tre secondi ma mostra un progress indicator è percepita come più responsiva di una che dura un secondo ma blocca l'interfaccia.

Il thread UI non deve mai essere bloccato da operazioni I/O o elaborazioni CPU-intensive: tutto ciò che non è aggiornamento diretto dei controlli deve girare su thread separati con async/await o Task.