Interfacce di dialogo nelle applicazioni web professionali
Le interfacce di dialogo costituiscono uno dei mezzi più efficaci per stabilire una comunicazione bidirezionale fra l'utente e il sistema garantendo la continuità del processo di elaborazione dei dati.
Diffusamente impiegate in buona parte dei siti e delle piattaforme web, sono diventate praticamente indispensabili e necessarie nella gestione degli automatismi delle applicazioni web professionali o complesse per garantire all'utente una UX (User Experience) di cui diversamente non godrebbe.
Le interfacce di dialogo, talvolta denominate erroneamente come pop-up o finestre di dialogo, sono delle maschere di comunicazione fra l'utente e il sistema, costruite utilizzando il popolarissimo plug-in lightbox di Javascript o mediante i numerosissimi plug-in dei framework di Javascript.
Trattandosi di componenti (o canali) di libera progettazione e personalizzazione - perché concretamente sono composti da un contenitore div generico accodato in fondo al DOM - non hanno vincoli tecnici se non quelli imposti dal sistema di progettazione e possono contenere qualunque tipo di informazione e tag: immagini, testo, moduli, video, streaming, etc.
Generalmente vengono realizzate interfacce di dialogo semplici e composte da pochi campi da trasmettere al sistema per l'elaborazione ma tutto dipendente dall'entità e dalla complessità del progetto.
Nelle applicazioni web professionali spesso si ha a che fare con interfacce di dialogo articolate e costituite da veri e propri moduli di personalizzazione perché rappresentano l'unico modo possibile per elaborare velocemente delle informazioni nel layout sottostante senza effettuare il refresh della pagina. È sicuramente una via contestabile e gli obiettori potrebbero indicare alternative come l'incoporamento del modulo nel layout principale o il redirect a una pagina indipendente composta dal solo modulo con un ritorno automatico alla pagina di provenienza al termine dell'elaborazione. Ma non sempre sono alternative praticabili. Nel primo caso perché il modulo potrebbe essere complesso e notevolmente articolato; e, in base alla composizione del layout principale, un suo eventuale incoporamento potrebbe generare confusione e poca leggibilità, penalizzando la UX. Nel secondo caso, invece, la tipologia di applicazione web potrebbe necessariamente richiedere una interfaccia di dialogo affinché i dati vengano elaborati istantaneamente e laddove ci sia un nesso inscindibile fra le operazioni effettuate nell'interfaccia di dialogo e i dati nel layout sottostante.
Si pensi a un preventivatore professionale per una impresa che preveda un configuratore e combinatore di numerose opzioni con diversi parametri. Per ottenere il preventivo finale, all'operatore potrebbe non bastare la sola selezione delle opzioni desiderate ma potrebbe essere necessario configurarle, personalizzarle. Una interfaccia di dialogo, in questo caso, potrebbe elaborare istantaneamente i dati del preventivatore in base ai prametri selezionati nell'interfaccia stessa, offrendo una visuale chiara e in tempo reale all'operatore. Se questa operazione venisse affidata a una pagina indipendente, l'operatore sarebbe interdetto dal monitoraggio del cambiamento automatico dei dati del configuratore e verrebbe costretto dal sistema a switchare da una pagina all'altra fidandosi della propria capacità mnemonica.
L'utilità dell'interfaccia di dialogo in una applicazione web professionale è indubbia e in certi casi costituisce l'unica soluzione possibile.
L'interfaccia di dialogo, come analizzato, è una pagina richiamata dinamicamente e in modo asincrono. Come tale, l'approccio al suo sviluppo e realizzazione potrebbe variare da caso a caso. Alcuni sviluppatori preferiscono progettare una unica pagina dove, oltre all'interfaccia grafica, includono codice lato-server e codice lato-client. Il mio approccio è differente e prevede lo sviluppo di una pagina di elaborazione che al termine dell'esecuzione dei dati richiama il markup dell'interfaccia (GUI) e l'eventuale richiamo al file Javascript esterno. Questo approccio viene preferito dai miei colleghi perché consente una gestione autonoma dei vari file senza rischiare di compromettere, anche con un semplice refuso, aree di codice non di propria competenza, soprattutto quando si lavora in team e non tutto l'apparato progettuale è stato sviluppato da una sola figura.
Per i miei progetti utilizzo il plug-in fancybox di jQuery, dotato di tutte le funzioni necessarie e facilmente personalizzabile stilisticamente. Attualmente è un plug-in completo nonché costantemente aggiornato.
Dopo aver incluso i suoi componenti all'interno del DOM è sufficiente attivarlo mediante questo semplicissimo comando:
$(selettore).fancybox();
Le personalizzazioni tecniche sono numerose in base alle necessità. È sufficiente far riferimento alla documentazione fornita e dotarsi dell'ultima versione disponibile scaricabile dal sito.
Fonte immagine: Google Immagini
