Blocks
Migliori onboarding blocks 2026: 9 sezioni verificate
9 blocchi di onboarding da 3 registry, sette dei quali di un solo autore. Cosa si rompe tra refresh, tasto indietro e progresso finto, e quando conviene una checklist invece di un wizard.
In sintesi
- 9 blocchi onboarding, 9 file, 3 publisher: sette righe arrivano da ephraimduncan.
- Il refresh a metà flusso è il difetto principale: lo stato vive in memoria e l'URL non cambia.
- Fino a tre passaggi saltabili il dialog basta; oltre serve una route con persistenza.
L’onboarding serve a portare una persona nuova al primo risultato utile, non a mostrare un tour. Il catalogo conta 9 blocchi da 3 registry, misurati il 1 novembre 2026, e sette vengono da un solo publisher: è un campione di una scuola di design, non di un mercato.
I guasti arrivano quando il flusso incontra la vita reale. L’utente compila due passaggi, ricarica la pagina e torna al primo; preme il tasto indietro del browser ed esce dal flusso invece di tornare al passo precedente; il “Salta” non salva niente, quindi il tour si ripresenta al login successivo. Sono difetti di stato e di URL, non di disegno, e nessuna anteprima li mostra.
Perché il refresh rompe tutto
Un blocco a un file tiene i passaggi in memoria: un indice, magari uno useState. Finché l’utente resta nella pagina funziona; appena ricarica, l’indice torna a zero. Per resistere al refresh servono tre cose che il blocco per definizione non ha: un URL che cambia a ogni passo, uno stato salvato sul server e una regola per riprendere dal punto giusto. Se non ci sono, il wizard è una demo.
Sette righe su nove, un solo autore
Ephraimduncan firma sette blocchi con nomi espliciti, workspace setup, steps with progress, accordion, activity feed, timeline, e sono tutti a un file; flx contribuisce con un dialog di benvenuto, 1st-pouf con una pagina. In totale 9 file, 7 dipendenze npm e 20 registry dependency: il peso è basso, la varietà è quella di una sola mano, e due dei sette sono varianti della stessa idea di progressione.
La tabella, ordinata per file
Con un file per blocco la colonna numerica non ordina nulla: qui conta il nome, che dice il tipo di flusso. “Workspace setup” chiede dati e serve un form; “accordion” e “timeline” sono contenuti da leggere; “welcome” è un dialog di primo accesso. Sono tre problemi diversi e richiedono tre decisioni diverse sullo stato.
| Blocco | Registry | File | Categoria |
|---|---|---|---|
| Onboarding welcome | flx | 1 | onboarding |
| Onboarding | 1st-pouf | 1 | onboarding |
| Onboarding | blocks | 1 | onboarding |
| Onboarding Workspace Setup | blocks | 1 | onboarding |
| Onboarding Steps with Progress | blocks | 1 | onboarding |
| Onboarding Accordion | blocks | 1 | onboarding |
| Onboarding Activity Feed | blocks | 1 | onboarding |
| Onboarding Timeline | blocks | 1 | onboarding |
Le prove che smascherano un onboarding
Compila il secondo passaggio, ricarica e guarda dove torni. Poi premi indietro e verifica se esci dal flusso o torni al passo prima. Poi salta e ricarica: se il tour ricompare, il “Salta” non ha salvato niente. Infine attraversa i passaggi con uno screen reader: il cambio di passo deve essere annunciato, e l’indicatore di progresso deve dire a che punto sei, non solo colorare una barra.
- URL che riflette il passo, così il tasto indietro funziona.
- Stato salvato sul server e ripreso al login, non solo in memoria.
- L’indicatore di progresso ha un testo e aria-current sul passo attivo.
- Ogni passo si può saltare o l’intero flusso si può chiudere senza perdere l’account.
curl "https://ui.eneawork.it/api/blocks/category/onboarding?limit=10"
Il limite: presentazione, non persistenza
Nessuno di questi blocchi contiene la logica che serve a un onboarding vero: sono schermate. Un blocco a un file non può includere anche il salvataggio dei passaggi, la ripresa al login e il calcolo di cosa mostrare a chi ha già completato. La categoria, inoltre, è dedotta dal titolo, quindi un wizard chiamato “Setup” finisce altrove e un dialog di benvenuto entra qui pur non essendo un percorso a passaggi.
Regola di decisione
Fino a tre passaggi, tutti saltabili, un dialog va bene: interrompe una volta e non richiede URL. Oltre i tre, o se un passaggio raccoglie dati che devono sopravvivere al refresh, serve una route dedicata con stato sul server e un passo nell’URL. L’alternativa è non fare un wizard: una checklist nella dashboard, con tre voci da completare, ottiene lo stesso risultato senza bloccare l’utente, e la usano prodotti che devono far vedere valore subito. Il blocco conviene quando porta un disegno di progresso che non vuoi ricostruire, non quando deve gestire lo stato al posto tuo.
I blocchi stanno su /blocks/category/onboarding, l’inventario su /blocks, e “Onboarding Steps with Progress” ha la scheda qui. Per lo stato di un form a più passaggi leggi lo stato nei form multi-step, per l’implementazione con shadcn il multi step form con shadcn, e per il confronto tra copiare e comporre copy-paste contro headless.
Domande frequenti
Quanti onboarding blocks ci sono nel catalogo?
9 blocchi da 3 registry, misurati il 1 novembre 2026, per 9 file totali. Sette arrivano da ephraimduncan e sono tutti a un file.
Perché l'onboarding riparte da zero dopo un refresh?
Perché i blocchi tengono il passo in memoria e non nell'URL né sul server. Senza un passo nell'URL e uno stato salvato, il refresh riporta all'inizio.
Quando conviene un dialog di onboarding?
Fino a tre passaggi saltabili, quando serve un solo momento di attenzione. Oltre, il dialog diventa un ostacolo e la route dedicata è più gestibile.
Meglio un wizard o una checklist in dashboard?
La checklist se l'utente può già usare il prodotto e deve solo completare dei passi. Il wizard se senza quei dati il prodotto non funziona.
Come rendo accessibile l'indicatore di progresso?
Con un testo che dice il passo corrente e quanti mancano, più aria-current sul passo attivo. Il solo colore non comunica lo stato a chi non lo distingue.