Offline, in ritardo, ripreso: percorsi mobili

Consideriamo una persona che avvia un’azione con una connessione stabile, prosegue mentre la risposta è in ritardo e ritorna dopo la chiusura dell’applicazione. L’interfaccia deve tenere conto dell’intero percorso, non soltanto del momento in cui la richiesta va a buon fine. Il funzionamento offline, ossia in assenza di un percorso di rete utilizzabile, è una condizione all’interno di questo più ampio problema di continuità.

La latenza è il ritardo tra un’azione e la relativa risposta. Una sessione interrotta è un percorso nel prodotto sospeso prima che l’applicazione abbia risolto completamente l’intento della persona. Considerare entrambi come elementi di progettazione porta a domande più chiare: che cosa può continuare localmente, che cosa richiede conferma e che cosa si deve mostrare quando non vi è certezza?

Mappa il percorso prima di scegliere un’alternativa

Inizia dall’azione prevista e traccia ogni stato in cui può entrare. Un documento potrebbe essere intatto, modificato localmente, in attesa di caricamento, confermato da remoto o bloccato da un conflitto. Assegnare un nome a questi stati evita che una generica schermata di caricamento racchiuda varie situazioni che richiedono spiegazioni o controlli differenti.

La mappa deve includere le uscite e i ritorni. Chiediti che cosa rimane se l’applicazione si chiude, se la connessione cambia o se una risposta arriva dopo la scomparsa della schermata visibile. Anziché compilare un elenco di casi limite, descrivi il percorso nel prodotto in ogni condizione di implementazione che il team deve supportare e verificare.

• Identifica l’intento della persona separatamente dalla richiesta di rete utilizzata per realizzarlo.
• Indica quali passaggi possono essere completati localmente e quali richiedono una conferma remota.
• Registra ciò che l’interfaccia mostra mentre il risultato rimane incerto.
• Definisci da dove riprende una sessione al ritorno e quale contesto ripristina.

Assegna un significato chiaro a ogni stato visibile

Lo stato è l’insieme delle informazioni che un’applicazione conserva sulla situazione attuale. Alcuni stati appartengono soltanto all’interfaccia, come un pannello aperto. Altri rappresentano progressi significativi, come una bozza modificata. I team di prodotto devono decidere quali informazioni debbano sopravvivere a un’interruzione e inserirle in una memoria persistente, ossia una memoria progettata per rimanere disponibile dopo la fine della sessione corrente.

Le etichette visibili devono distinguere il progresso dalla conferma. Salvato su questo dispositivo, in attesa di invio e impossibile confermare descrivono condizioni diverse. La formulazione esatta dipende dal prodotto, ma ogni messaggio deve spiegare che cosa è accaduto, se la persona deve intervenire e se il suo lavoro rimane disponibile.

1. Dai allo stato significativo un nome espresso nel linguaggio del prodotto anziché in quello dell’implementazione.
2. Decidi quali prove consentono all’applicazione di mostrare quello stato con sicurezza.
3. Proponi un’azione successiva soltanto quando un intervento può cambiare il risultato.
4. Conserva un contesto sufficiente affinché il messaggio rimanga comprensibile dopo il ritorno.

Separa i progressi locali dalla verità condivisa

Una fonte di verità è il registro controllato che un prodotto considera autorevole quando le copie non coincidono. Un’applicazione può conservare il lavoro locale mentre attende di confrontarlo con quel registro. L’interfaccia non deve far pensare che sia avvenuta una conferma remota solo perché il salvataggio locale è riuscito, ma non deve nemmeno presentare utili progressi locali come se fossero andati persi.

Un aggiornamento ottimistico presenta il risultato previsto prima dell’arrivo della conferma remota. Questa scelta può sostituire un’attesa visibile con uno stato provvisorio, ma il team deve quindi definire che cosa accade dopo un rifiuto, un ritardo o una correzione. Prendila in considerazione quando lo stato provvisorio è comprensibile e reversibile. Per le azioni con conseguenze o irreversibili, una conferma esplicita può offrire un confine più chiaro.

• Mostra uno stato provvisorio quando una correzione successiva potrebbe altrimenti risultare sorprendente.
• Mantieni disponibili le modifiche locali finché la conferma remota rimane irrisolta.
• Spiega i conflitti attraverso i contenuti interessati anziché mediante un generico errore di sincronizzazione.
• Evita la sostituzione silenziosa quando il prodotto potrebbe dover conservare modifiche in conflitto.

Tratta il lavoro in sospeso come una coda gestita

Una coda è una raccolta ordinata di operazioni in attesa di elaborazione. Se un’azione deve continuare dopo il ripristino della connettività, rappresentala come un’operazione persistente anziché come un’animazione legata a un’unica schermata. Il team deve verificare le condizioni di implementazione relative alla memoria, al lavoro esterno alla schermata visibile e ai tentativi ripetuti prima di decidere quanto autonomamente possa funzionare quella coda.

Ogni operazione richiede un’identità, uno stato attuale e una politica per i nuovi tentativi, che definisce quando sia opportuno eseguire un altro tentativo. Dove il prodotto e il sistema remoto lo consentono, rendi l’elaborazione idempotente, ossia fai in modo che ripetere la stessa operazione non produca un effetto aggiuntivo. Se il team non può stabilire tale condizione, il prodotto deve fermarsi prima di una ripetizione ambigua e offrire un modo per esaminare l’azione irrisolta.

1. Memorizza l’operazione prevista con il contesto minimo necessario per riprenderla in sicurezza.
2. Indica se l’elaborazione non è iniziata, rimane incerta, è riuscita o richiede attenzione.
3. Esegui un nuovo tentativo soltanto quando l’operazione e il sistema remoto rendono sicura la ripetizione.
4. Rimuovi il lavoro completato senza cancellare il contesto necessario per spiegare il risultato visibile.

Verifica i confini delle interruzioni, non solo le schermate

I test delle interruzioni devono seguire le azioni attraverso i diversi confini: prima dell’invio, durante una risposta in ritardo, dopo il salvataggio locale e prima della conferma remota. Un test mirato modifica una condizione alla volta, quindi controlla sia l’interfaccia immediata sia lo stato presentato dopo la riapertura. In questo modo il team può individuare direttamente le regole di ripristino poco chiare.

Chiudi l’applicazione in ogni fase significativa di un’azione composta da più passaggi, quindi ripristina la connettività prima e dopo la creazione del lavoro in sospeso. Introduci un’ipotetica modifica in conflitto ed esamina il percorso di risoluzione. Ritorna da un punto di accesso diverso e controlla se lo stato rimane comprensibile senza dipendere dalla schermata originale.

Esamina il risultato sia dal punto di vista del prodotto sia da quello tecnico. Per ogni test, valuta se il completamento tecnico e il messaggio visibile concordano. I criteri di accettazione, ossia le condizioni utilizzate per valutare il percorso, devono coprire il lavoro conservato, lo stato visibile, la ripetizione sicura e il successivo allineamento con il registro autorevole.

Scrivi un contratto di continuità per ogni azione chiave

Trasforma il quadro in un contratto di continuità: una breve descrizione interna di ciò che l’applicazione conserva, comunica e tenta quando un’azione viene interrotta. Per ogni percorso chiave, registra lo stato locale, il registro autorevole, le condizioni per la conferma, la regola per i nuovi tentativi e l’opzione di ripristino disponibile per la persona.

La decisione pratica non consiste nello stabilire se un’applicazione sia semplicemente online oppure offline. Consiste nel modo in cui il prodotto rappresenta l’incertezza tra l’intento e la conferma. Mappa gli stati, distingui i progressi locali dalla verità condivisa, gestisci esplicitamente il lavoro in sospeso e verifica ogni confine di interruzione. Nel loro insieme, queste decisioni costituiscono un piano utilizzabile per i percorsi in cui la continuità non può essere data per scontata.