Comunicare modifiche agli appuntamenti in un’app
Un piano di prova per permessi, stato di invio e ritorno all’appuntamento di assistenza aggiornato.
La modifica resta nel sistema degli appuntamenti
Una notifica push informa di un appuntamento modificato. La modifica valida va prima salvata nel sistema responsabile. Pianifichi dove il cliente trova lo stato attuale e chi segue un cambiamento importante se il messaggio non arriva.
Apple e Android descrivono permessi di notifica specifici delle piattaforme. Spieghi il vantaggio al momento adatto, per esempio quando il cliente vuole attivare gli avvisi. Un permesso negato non è consenso. Verifichi il comportamento su dispositivi e versioni del sistema previsti.
Esempio e piano di prova dettagliato
Nell’esempio inventato, la pianificazione sposta l’appuntamento di assistenza AP-17 da 14:00 a 15:00. Un messaggio discreto è: «Un appuntamento di assistenza è cambiato. Apra l’app per lo stato aggiornato». Non servono dettagli personali dell’intervento sullo schermo bloccato.
Situazione | Comportamento previsto | Evidenza attesa |
|---|---|---|
Permesso assente | Gli appuntamenti attuali restano reperibili nell’app; usare il contatto concordato per modifiche importanti. | Il team non presume un contatto push riuscito e conosce il ruolo responsabile. |
Appuntamento modificato | Salvare la modifica e collegare chiaramente la notifica all’appuntamento. | Il nuovo stato è salvato; un tentativo di invio non sostituisce il salvataggio. |
Messaggio accettato dal fornitore | Registrare lo stato di invio effettivamente noto. | L’accettazione non viene chiamata ricezione sul dispositivo o lettura del cliente. |
Dispositivo offline o messaggio tardivo | Caricare lo stato attuale all’apertura. | Un vecchio messaggio non ripristina un vecchio stato; il mancato aggiornamento è indicato chiaramente. |
Il cliente tocca la notifica | Aprire l’appuntamento dopo l’accesso necessario e il controllo dei permessi attuali. | Appare l’appuntamento corretto. Se manca l’accesso o i dati non si caricano, il cliente riceve un riscontro adatto. |
Verificare separatamente invio e azione del cliente
FCM documenta accettazione del server e consegna all’SDK del dispositivo come eventi distinti. La ricezione non prova neppure che il cliente abbia letto o accettato la modifica. Nell’esempio, il tocco non deve creare un altro appuntamento né dare automaticamente un’approvazione richiesta dal processo aziendale.
Stabilisca una durata adatta al messaggio. I messaggi possono arrivare tardi; una vecchia notifica non deve essere l’unica fonte dello stato dell’appuntamento. Concordi quando il responsabile segue le modifiche importanti tramite il contatto definito.
Provi permessi concessi e negati, ricezione tardiva, mancato accesso e dati che non si caricano. La tabella descrive risultati attesi della prova. Valuti se il cliente trova l’appuntamento attuale e comprende l’azione successiva necessaria.
Fonti
Scritto da
- Katharina WeberRedattrice per software e tecnologiaKatharina Weber cura per ASES gli articoli sullo sviluppo software. Scrive delle questioni che le aziende affrontano nella scelta del software, nello sviluppo di nuove applicazioni e nella modernizzazione dei sistemi esistenti.
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile