Il prompt, la conferma e l'avviso di JavaScript sono considerati "vecchio stile" [chiuso]

Ultimamente ho sviluppato un sistema di gestione basato sul web per una palestra. La loro app precedente era stata sviluppata in Visual Basic. Per la nuova app, tutti gli script front-end utilizzano jQuery, il server esegue PHP e MySQL ... sai, il tipico stack basato su Linux el-cheapo.

Ad ogni modo, mi chiedevo perché i dialoghi dei messaggi di richiesta, conferma e avviso di JavaScript siano così poco utilizzati al giorno d'oggi. Esistono molti plugin jQuery per finestre modali e messaggi di avviso che tentano di imitare qualcosa che la lingua offre già e ogni browser è costretto a supportare correttamente.

L'uso di soluzioni fatte a mano o basate su plug-in va bene per moduli complessi ed esigenze speciali, ma se hai solo bisogno di chiedere un singolo valore o confermare l'eliminazione di un record, perché dovresti aggiungere tale sovraccarico alla tua app web? Inoltre, iOS e Android offrono dialoghi di messaggi ben adattati quando si utilizza prompt, conferma e avviso.

1. UX: le finestre di messaggio sono per lo più malvagie

Le caselle di avviso sono errate in tutti i casi dal punto di vista UX. Nelle app desktop. Nelle app Web come avvisi o messaggi JavaScript incorporati. Ovunque.

Puoi leggere About Face 3 di Alan Cooper¹ se vuoi sapere perché; spiega molto bene come questo interrompe il flusso di lavoro e infastidisce l'utente e come quasi tutte le caselle di avviso esistenti nel software attuale siano profondamente sbagliate . Nella pagina 542, "La finestra di dialogo che gridava" Lupo! "" Spiega che le caselle di avviso vengono regolarmente ignorate, quindi il loro modello è completamente rotto. A pagina 543 del libro sono elencati tre principi di progettazione principali:

• Non chiedere.
• Rendi reversibili tutte le azioni.
• Fornire feedback non modali per aiutare gli utenti a evitare errori.

Quindi, gli autori ci dicono come sostituire le caselle di avviso con l'approccio progettuale corretto.

I messaggi rapidi sono leggermente diversi. Eppure, interrompono l'esperienza utente della tua app. Se vuoi che l'utente inserisca qualcosa, considera di usare una casella di testo o un'area di testo, decorandola con JavaScript quando necessario. Non essere pigro, fornisci una ricca interfaccia in un'era di app abilitate per RIA e AJAX ; in tutti i casi, se JavaScript è disabilitato, il tuo prompt non verrà visualizzato.

Nelle pagine Web, sia le caselle di avviso che i prompt sono per lo più fastidiosi. Qualche esempio:

1. Alcuni forum consentono di creare elenchi richiedendo all'infinito gli elementi dell'elenco. Significa che durante la creazione dell'elenco non è possibile utilizzare la pagina stessa, incluso copia-incolla. Hai anche un singolo campo minuscolo. Che dire del testo lungo? Che dire audace e corsivo?

2. "Se continui, la foto verrà rimossa definitivamente dal tuo profilo. Sei sicuro?" . Certo che ne sono sicuro! Altrimenti farei clic su "Rimuovi foto dal mio profilo"? Perché la tua app web suppone che io sia così stupido? In realtà, le applicazioni Google come GMail mostrano l'approccio corretto. Puoi rimuovere, eliminare, distruggere ciò che vuoi e, quando lo fai, l'app visualizza un piccolo link "Annulla".

3. "Vuoi partecipare al nostro miglior sondaggio?" . Bene, in realtà ero lì per visitare il tuo sito Web, ma poiché mi dai fastidio con i tuoi messaggi fastidiosi, preferirei andare altrove.

4. "Il clic destro è disabilitato su questo sito Web per proteggere le foto protette da copyright" . Bene, in realtà ho fatto clic con il pulsante destro del mouse per cambiare la lingua del controllo ortografico prima di inviare il mio commento. Certo, lo spedirò senza controllare l'ortografia.

Conclusione: dal punto di vista dell'esperienza dell'utente, le applicazioni utilizzano le finestre di messaggio in modo errato per la maggior parte del tempo.

Ma aspetta! Molti siti Web di bassa qualità sostituiscono fastidiose caselle di avviso con fastidiosi messaggi JQuery con uno sfondo semitrasparente che copre tutta la pagina. Quindi gli svantaggi rimangono.

Bene, ci sono altri motivi per non usare le finestre di messaggio nelle applicazioni web:

2. Progettazione: le caselle di avviso hanno un proprio design

Non è possibile progettare una casella di avviso. Non puoi cambiare il suo colore, le sue dimensioni, il suo carattere. Questo lo rende ancora più fastidioso per l'utente: stavi lavorando con un'app Web e il tuo flusso di lavoro è interrotto da un messaggio che sembra provenire dal nulla e non corrisponde nemmeno all'aspetto visivo dell'app. Senza contare che la lingua dei pulsanti corrisponde anche alla lingua del sistema operativo / browser, non a quella dell'applicazione web.

Per i progettisti, i messaggi JavaScript sono molto più potenti delle caselle di avviso.

Sono anche molto più estesi. Puoi aggiungere grassetto e corsivo, puoi scegliere i tuoi pulsanti (che ne dici di: "Ci scusiamo ma la password che hai inserito non è valida. [Reimposta la mia password] [Provane un'altra] [Annulla]"?) ².

3. JavaScript: il flusso dell'applicazione si interrompe

Quando viene visualizzata una finestra di avviso, JavaScript si interrompe fino a quando l'utente non fa clic. Su un sito Web, potrebbe essere ok. Con un'app Web, spesso diventa un problema.

4. Sandbox: non forzare l'utente a riavviare il suo computer

Ricordi i siti Web scadenti che mostrano un numero infinito di finestre di messaggio ? L'unico modo per gli utenti senza sufficiente background tecnico per poter continuare a lavorare era di fatto riavviare il computer. Questo ci porta a un problema: le caselle di avviso non rientrano nell'ambito del sito Web o dell'applicazione Web. Non sei autorizzato a impedire all'utente di accedere ad altre schede del browser³.

Lo stesso problema ha costretto i browser a risolverlo in diversi modi. Firefox, ad esempio, consente l'accesso ad altre schede quando si visualizza un avviso nella scheda. Chrome, d'altra parte, ti consente di verificare che non desideri più ricevere caselle di avviso da una pagina, ma blocca comunque l'accesso ad altre schede.

Sebbene l'approccio di Firefox sia perfettamente valido, quello di Chrome può essere criticato (poiché blocca ancora ogni scheda) e causa un problema: cosa succede se l'utente fosse gravemente infastidito da diverse finestre di messaggio emesse dalla tua app e controllato il caso, quindi hai provato a mostrare qualcosa di veramente importante? Bene, l'utente non lo vedrà mai.

Il fatto rimane lo stesso, la maggior parte degli utenti sarà infastidita dalle caselle di avviso, quindi non sono ancora molto facili da usare e possono bloccare gravemente un utente senza sufficiente background tecnico. In linea, i messaggi JavaScript potrebbero bloccare la pagina, ma non il browser stesso. Poiché il modello di app Web è una sorta di sandboxing, in cui ad esempio non è possibile accedere alla tastiera dell'utente o riavviare il computer o leggere i file dal disco rigido o passare a schermo intero o utilizzare due monitor, le caselle di avviso con il loro effetto di blocco interrompono gravemente questo modello sandboxing .

Ultimo ma non meno importante, cosa accadrebbe se l'utente fosse su un'altra scheda quando l'applicazione ha deciso di mostrare la casella di avviso? Cosa succede se l'utente sta facendo qualcosa di importante e non desidera interagire con la tua app in questo momento?

^{¹ Informazioni su Face 3, The Essentials of Interaction Design , Alan Cooper, Robert Reimann e David Cronin, ISBN 978-0-470-08411-3; Capitolo 25: Errori, avvisi e conferme.}

^{² Questo è solo un esempio. Per favore, non farlo nelle tue applicazioni web, dal momento che è davvero una scelta di design scadente.}

^{³ Se si desidera un confronto con il mondo delle app desktop, un messaggio JavaScript incorporato è come una finestra di messaggio di un'applicazione desktop. Una finestra di avviso in un browser, invece, è come una finestra che appare dal nulla, impostata come la più in alto, su uno sfondo opaco a schermo intero che ti impedisce di accedere a qualsiasi altra applicazione desktop. Qualsiasi app che deciderà di farlo una volta sul mio computer verrà rimossa immediatamente e per sempre.}

In conclusione: le finestre di dialogo di richiesta, conferma e avviso predefinite corrispondono allo stile del browser, non allo stile del sito. La maggior parte delle persone dell'interfaccia utente desidera che tutte le finestre di dialogo fluiscano con l'interfaccia utente del proprio sito. Usano finestre modali per presentare messaggi e raccogliere dati utilizzando gli stessi caratteri e colori dell'interfaccia utente del sito, non il grigio e il blu predefiniti di MSIE o FF.

Stai aggiungendo overhead solo se non hai bisogno di dialoghi elaborati altrove, cosa che probabilmente fai. A quel punto non fa molta differenza se la funzionalità è inclusa come parte del browser o come parte del framework che stai usando, e puoi anche mantenere tutti i tuoi popup apparire coerenti.

Mentre puoi fare molto con javascript e senza framework, ricordo com'era lo sviluppo in javascript prima che i framework fossero disponibili, e non vorrei tornarci.

Perché i browser non li gestiscono molto bene . Come avrai notato, in genere sono finestre di dialogo modali e non solo impediscono agli utenti di spostarsi e ridimensionare il proprio browser, ma impediscono anche l'accesso ad altre schede, il che è molto fastidioso.

Per le finestre di dialogo come conferma e modifica, penso ancora che il browser dovrebbe applicare il comportamento, e per l'ultimo browser Firefox puoi vedere che hanno risolto il problema che ho menzionato sopra. Usano negli avvisi di pagina che hanno l'ambito della pagina corrente.

Pertanto, ti suggerisco di ignorare il comportamento degli avvisi in modo che tutti i browser possano gestire (almeno gli avvisi) in modo più elegante.

Alcuni motivi riassunti:

• Questa è l'API standard e gli sviluppatori possono capire cosa stai cercando di fare.
• È più facile da usare e ha un aspetto migliore.
• Supporto della piattaforma, i siti mobili potrebbero aver bisogno dell'API nativa.