Pannello 2.0: come sarà il nuovo frontend di Qboxmail

Negli articoli precedenti vi abbiamo mostrato come è composta la nostra architettura software e su cosa ci stiamo concentrando per migliorare il nostro backend mentre stiamo realizzando la versione 2.0 del nostro pannello. Oggi vi parleremo di quello che sicuramente interessa di più ai nostri utenti, l’interfaccia (il frontend, per i più tecnici).

Inutile evidenziare l’importanza dell’interfaccia: un ottimo sistema che offre una pessima interfaccia difficilmente arriverà al successo che merita. L’utente tramite l’interfaccia deve essere in grado di sfruttare a pieno le potenzialità che il sistema offre; è un compito arduo, soprattutto quando il sistema sottostante è complesso come il nostro.

Le scelte tecnologiche in questo caso non sono molte, quando si parla di web l’unica soluzione disponibile è quella di utilizzare HTML5, CSS3 e JavaScript. Come già accennato nell’introduzione il frontend del nostro pannello si basa fortemente su JavaScript, è lui infatti che si occupa di generare client side tutto l’html necessario, che una volta renderizzato dal browser, mostra sul display il pannello con cui l’utente è abituato a interagire.

Non a caso negli ultimi anni una delle figure più ricercate è quella del cosiddetto Sviluppatore Frontend, cioè qualcuno con ottime conoscenze di JavaScript/HTML5/CSS3 e solide fondamenta per quanto riguarda il design e l’usabilità (a tal proposito, dai un occhiata qui se ti senti descritto dalla frase appena letta?). Proprio la forte richiesta di questo tipo di figura rispecchia quali sono le caratteristiche necessarie ad ogni interfaccia:

• capace di offrire ottime performance
• facile, intuitiva e espressiva per l’utente

Senza queste caratteristiche si rischia di finire nel mucchio dei tanti eccezionali prodotti che hanno perso terreno rispetto alla concorrenza a causa di interfacce trascurate o mal realizzate (vi dice niente Android?).

Detto questo, dobbiamo ammettere che ad oggi la nostra interfaccia non è all’altezza della qualità dei nostri servizi. Le cause sono molte, e non siamo qui a cercare scuse, ma finalmente abbiano iniziato a dedicarci a creare un esperienza per i nostri utenti che rispecchi quella che offre il resto della piattaforma.

Design Responsive

La più grossa mancanza attuale è quella di non avere un design responsive, cioè in grado di adattarsi agli schermi di molteplici dimensioni che accedono a internet quotidianamente. Implementare questo tipo di design nel nostro pannello non è semplice come “buttare dentro” uno dei tanti framework disponibili (Bootstrap, Foundation …). La quantità e la diverse tipologie di informazioni che dobbiamo mostrare sono elevate, molto portate per loro stessa natura a essere presentate in tabelle come avviene per nell’attuale versione del pannello.
Chiunque lavori nel campo o semplicemente abbia occhio per questi dettagli è in grado di evidenziare come le tabelle sono poco funzionali quando si tratta di adattarsi a diverse dimensioni. Consultare una tabella su uno schermo da 5 pollici difficilmente risulta in un’esperienza soddisfacente.

Le soluzioni emerse negli ultimi anni riguardanti questo problema sono diverse, dall’utilizzo di tecniche particolari di scrolling per consentire di visualizzare totalmente grandi tabelle (zero rinunce ma pessime in termini di reale usabilità) alla sostituzione completa delle tabelle con le cosiddette card, ormai onnipresenti tra le più moderne web app. Tra le due soluzioni citate esistono diversi step intermedi, la decisione definitiva sulla situazione che adotteremo non è ancora stata presa; la nostra priorità è quella di consentire all’utente di compiere tutte le azioni sui propri domini ed email anche da mobile. Inoltre deve essere semplice e veloce esaminare cosa sta succedendo ad una casella email tramite il nostro ETLive, anche su piccoli schermi e con connessioni lente; il nostro cliente deve essere in grado di analizzare velocemente quale potrebbe essere la causa di eventuali problemi per fornire una risposta veloce al proprio utente.

Per questi motivi il lavoro di ottimizzazione delle interazioni con i form e sulla visualizzazione dei dati sarà affrontato con un approccio mobile-first; il che vuol dire che la progettazione e la prima implementazione sarà interamente concentrata sui dispositivi mobile. Affrontando direttamente la parte più complessa del problema sarà più facile capire cosa deve essere presente e ottimizzato su questo tipo di strumento e poi scalare verso l’alto (tablet e desktop) dove le restrizioni sono decisamente minori (schermi più grandi, connessioni più stabili).

Responsive non si limita alle dimensioni dello schermo, ma significa anche essere più flessibile alle altre condizioni che differiscono quando si utilizzano dispositivi differenti. Ad esempio, scaricare un file javascript da 6/7 MB su mobile, se la linea non è veloce o c’è poco campo può rivelarsi un serio problema. In questo le nuove tecnologie ci vengono incontro, quasi tutti i browser offrono la possibilità di salvare il codice nella propria cache e riscaricarlo solo quando vi sono stati aggiornamenti. Inoltre, è possibile creare file compressi al minimo tramite build system sempre più efficienti, tanto da arrivare a far stare applicazioni un tempo pensanti in poco più di 1 MB.

Tutto è JavaScript

Come già citato, per comporre un applicazione web gli unici strumenti disponibili sono rappresentati dal trittico HTML,CSS e Javascript. Il problema è che i primi due, i più longevi, sono stati concepiti con l’idea di un web statico, concentrato sulla rappresentazione e condivisione di documenti testuali. Questo fa si che i due abbiano un’intrinseca natura statica che rema contro al modo dinamico in cui si fruisce e si fa utilizzo del web. Una pagina web oggi deve sapersi adattare alle diverse caratteristiche dei dispositivi che la visitano, deve poter riprodurre contenuti multimediali e sempre più spesso anche modificarli, lavorando con i bit che la compongono. Questo sarebbe impossibile da ottenere con solo HTML e CSS, proprio per questo è stato creato JavaScript, un linguaggio di programmazione per il web. Le sue risorse sono sempre stato limitate, è infatti un linguaggio di scripting concepito in poco più di una settimana pensato puramente per aggiungere piccoli effetti e un minimo di interattività; ma il ruolo ricoperto dal web oggi lo ha portato ad un evoluzione frenetica e costante che ne ha ampliato le capacità e lo ha reso uno dei linguaggi più adottati al mondo.
Oggi il web è zona franca: se vuoi creare un prodotto fruibile da tutte le piattaforme senza dover creare 5/6 applicazioni complete utilizzando altrettanti linguaggi e tecnologie differenti l’unica soluzione universale è il web.

Necessita, è questa la causa principale dell’evoluzione frenetica di JavaScript.

Oggi è possibile utilizzarlo anche per la programmazione lato server, realisticamente infatti lo stack di molte web app moderne è il seguente:

• API implementate con NodeJS
• Sistema di Build (scritto in JavaScript stesso) che “compila” i diversi file e librerie JS in un unico minimizzato e incomprensibile file JS
• browser che implementa un motore(magari anch’esso scritto in Javascript ) in grado di interpretare il file emesso nel passaggio precedente e lo esegue come una vera e propria applicazione nativa nel proprio ambiente.

Tra i file che vengono “compilati” nel secondo passaggio sono inclusi file HTML e CSS. Esistono diverse soluzioni in grado in grado di scrivere codice JS che poi si occupa di generare dinamicamente tag HTML e regole CSS. Questo dona una totale dinamicità a questi due linguaggi di markup.

Fatta eccezione delle API implementate con Nodejs (noi preferiamo ancora Rails) questo sarà anche il nostro stack per il frontend. E’ un ambiente complicato, e la continua evoluzione lo rende ancora più complesso da inseguire, ma i vantaggi sono tremendi. Con questi strumenti è possibile creare applicazioni complesse e che fanno concorrenza alle controparti native.

React e Redux, l’importanza dei design pattern

Come scritto poche righe fa, la complessità con questo tipo di soluzione è alta. È molto acceso il dibattito tra chi odia questa continua evoluzione, che lascia molte cose incomplete, e chi invece ne apprezza la filosofia e prova a tenerne il passo.Qui a Qboxmail pensiamo che come spesso accade, la verità sia nel mezzo:

rifiutarsi di seguire il flusso significherebbe perdersi tante possibilità, mentre cercare di restare sempre sulla cresta dell’onda abbatterebbe la produttività.

La nostra isola felice l’abbiamo trovata in ReactJS e nel suo ecosistema.

Per farla breve: ReactJS è un framework, ideato da Facebook, che promuove la scrittura di applicazioni come un insieme di componenti indipendenti che crea strutture complesse. Il concetto non è nulla di nuovo, è molto simile a quello di Programmazione ad oggetti, solo che piuttosto che essere implementato a livello di costrutti del linguaggio si pone a un livello logico superiore (si potrebbe creare un framework simile a reactjs con qualsiasi linguaggio). Questa filosofia si applica con una serie di design pattern e best practices che riescono a dare un senso e delle regole ben precise a un linguaggio povero di strutture complesse come JavaScript.

Se ReactJS ti permette di creare componenti riutilizzabili e indipendenti, Redux è un piccolo framework che ti da le API per farli comunicare tra loro e utilizzare il loro stato per definire lo stato dell’intera applicazione, e lo fa molto bene in solo 2kb. Anch’esso è la realizzazione pratica di un altro concetto introdotto da facebook. Avere pattern da seguire è molto importante in progetti grossi, a volte è facile buttarsi a scrivere codice senza regole, o provare a imporsele ma trascurarle alla prima difficoltà. Ma questo risulta senza che ce ne si accorga in software difficile da mantenere, da farne il debug in caso di problemi e poco trasparente.

Scegliere un design pattern e seguirne le regole migliora la qualità del codice del programma e ne consente di poter evolversi con l’ecosistema stesso. È importante che il prodotto sopravviva allo sviluppatore e seguire delle regole è l’unico modo per ottenere questa caratteristica per software complessi.

React e Redux saranno gli strumenti con cui comporremo il nostro nuovo frontend, il nostro archivio (Qbvault coming soon…) già li utilizza e quindi possiamo sfruttare componenti già creati, migliorandoli. E se fatto bene, migliorare un componente utilizzato in due applicazioni ha il pregio di migliorare in in colpo solo entrambe.

Con questi obiettivi vogliamo fornire un pannello moderno che consenta ai nostri clienti di gestire i propri domini in totale autonomia, e che gli renda facile e immediato l’accesso a tutte le informazioni di cui hanno bisogno.