Il termine UI o interfaccia utente viene utilizzato spesso quando si parla di sviluppo di applicazioni. La prima cosa che un cliente vede quando apre un'applicazione è il modo in cui è progettata, ed è logico che questo sia un aspetto dello sviluppo web molto importante. Un'interfaccia utente semplice e facile da usare può aumentare i tassi di conversione di un'applicazione web di quasi il 200%. L'interfaccia utente è parte integrante del processo di sviluppo del software.
Poiché si tratta principalmente di ciò che il cliente vede, le interfacce utente sono sviluppate dagli ingegneri front-end. Diversi framework front-end, come React.js, flutter e altri, rendono semplice ed efficiente lo sviluppo di belle interfacce utente. Tuttavia, lo sviluppo tradizionale può essere un processo lungo, soprattutto quando si tratta di aggiornamenti. App store come Apple Store e Google Play Store spesso richiedono agli sviluppatori un lungo processo per implementare modifiche importanti all'interfaccia utente. È qui che SDUI, o sviluppo di applicazioni con interfaccia utente guidata dal server, può fare la differenza.
L'interfaccia utente guidata dal server o lo sviluppo guidato dal backend possono cambiare le carte in tavola e il loro funzionamento è molto simile a quello dei browser con linguaggi come HTML e CSS. Ma prima di entrare nel merito di come funziona l'SDUI e dei suoi vantaggi, diamo un'occhiata a cosa sia in realtà l'interfaccia utente backend o server-driven.
Cos'è l'interfaccia utente guidata dal server?
L'interfaccia utente di un'applicazione o di un servizio si riferisce al suo aspetto e alle sue sensazioni. Un progettista di UI deve occuparsi di come vengono mostrati i singoli aspetti dell'applicazione, dell'estetica e della reattività della pagina web su più dispositivi. Questo perché è l'area della schermata iniziale in cui i consumatori si impegnano con il sito.
L'interfaccia utente di un sito web è definita dal suo codice HTML. I clienti possono ricevere rapidamente questo codice quando visitano un sito che utilizza lo sviluppo dell'interfaccia utente lato server. Quando gli utenti utilizzano un'applicazione di questo tipo, il sito, il design, i CSS, i JavaScript e il materiale del sito vengono caricati durante la richiesta originale.
Nello sviluppo tradizionale di un'applicazione mobile, un programmatore progetta e confeziona il design e l'aspetto dell'interfaccia utente nel ciclo di rilascio. Il pacchetto software viene caricato su app store come Google Play Store, dove viene esaminato prima di essere reso disponibile per il download da parte dei clienti. Le interfacce utente di queste app sono rese interattive dissociando l'interfaccia utente dal contenuto che presenta. Le informazioni vengono spesso scaricate da un server o da un backend e incorporate nell'interfaccia utente, anche se quest'ultima è un componente del codice dell'app. Questo è il caso abituale di un ciclo di rilascio in caso di aggiornamento.
Consideriamo il caso in cui gli sviluppatori debbano aggiungere alcune modifiche importanti all'interfaccia utente dell'applicazione. Come abbiamo detto sopra, gli sviluppatori devono passare attraverso un intero ciclo di rilascio per introdurre queste modifiche. Questo perché la logica che detta la visualizzazione delle informazioni è integrata nella schermata iniziale del programma. Dopo aver apportato i miglioramenti necessari in questo ciclo di rilascio, devono passare attraverso un altro ciclo di revisione, test e approvazione del Play Store. Se l'applicazione deve essere rilasciata su entrambe le piattaforme iOS e Android, il ciclo di rilascio deve essere completato due volte. Questo può essere un processo lungo e molto probabilmente avrete bisogno di sviluppatori separati per le due piattaforme, poiché devono essere codificate in lingue diverse. Quando anche piccole modifiche dell'interfaccia utente raggiungono gli utenti dopo il ciclo di rilascio, possono passare mesi.
Differenza dal rendering lato client
Lo sviluppo tradizionale fa uso del rendering lato client. In questo caso, il design della pagina, i CSS e i JavaScript vengono recuperati dopo la richiesta del client. A volte alcuni contenuti non vengono inclusi, costringendo JavaScript a eseguire ulteriori richieste per avere la possibilità di produrre l'HTML necessario.
Questo approccio ha i suoi vantaggi, ma si scontra con il problema di cui sopra quando si tratta di aggiornamenti. Tuttavia, a volte può essere utile. Se, ad esempio, solo una piccola parte del sito web è stata modificata durante l'uso del rendering lato client, non è necessario renderizzare nuovamente l'intera pagina. Il rendering dell'interfaccia utente lato client assicura che tutti i dati necessari siano stati caricati completamente. Per questo motivo, l'interfaccia utente lato client diventa molto veloce e reattiva. Il rendering lato client consente inoltre di coinvolgere gli utenti in modo interattivo.
Per il rendering lato server, è necessario mantenere lo stesso script sia sul lato client che su quello server dell'applicazione, il che potrebbe comportare costi operativi più elevati e ritardi nello sviluppo. Le applicazioni lato client di facile utilizzo offrono un alto livello di prestazioni. Ma solo quando gli script JavaScript necessari hanno completato il caricamento. Per questo motivo, in tali applicazioni possono verificarsi problemi di prestazioni durante l'utilizzo di telefoni cellulari e di una connessione Internet lenta. La varietà di dispositivi mobili oggi disponibili può anche rendere difficile prevedere il funzionamento del rendering lato client. Gli sviluppatori costruiscono l'interfaccia utente lato client con l'aiuto di librerie come Ember.js, backbone.js e altre.
Vantaggi dell'interfaccia utente guidata da server
Il prodotto finale di un'interfaccia utente guidata dal server non è diverso da un'interfaccia utente lato client. Quali sono i vantaggi offerti da SDUI?
Aggiornamenti rapidi
L'SDUI offre numerosi vantaggi quando gli sviluppatori devono aggiornare un'applicazione. Il ciclo di rilascio di un nuovo aggiornamento può richiedere anche settimane. Con SDUI questo può essere accelerato. Gli ingegneri devono solo utilizzare il backend o un aggiornamento lato server. Non hanno bisogno di testarlo perché non stanno creando nuovo codice. Inoltre, il ciclo di rilascio non richiede l'invio della versione aggiornata dell'applicazione agli app store come Google Play Store. Non è quindi necessaria l'approvazione di Apple o Google. Le modifiche che prima richiedevano mesi o settimane possono ora essere effettuate in poche ore o giorni. Queste modifiche nel ciclo di rilascio si riflettono sia su un'app iOS che su un'app Android, poiché le modifiche vengono apportate direttamente al server.
Più facile da implementare
La strategia backend o guidata dal server è in genere più semplice se gli sviluppatori stanno creando una pagina web statica. Inoltre, non devono preoccuparsi di potenziali problemi di SEO perché il sito web crea HTML statico, consentendo ai motori di ricerca di vedere il loro materiale. Riducendo il lavoro del browser, si riduce anche la possibilità di bug imprevisti.
Indicizzazione dei social media più semplice
Come i crawler dei motori di ricerca, anche i bot dei social media hanno difficoltà ad analizzare il materiale JavaScript. Ad esempio, le Twitter Card non supportano il rendering lato client. L'approccio al rendering lato server può essere preferibile se la condivisione sui social network è una componente significativa del vostro piano di marketing. Il rendering di un'applicazione basato sul server è anche meno complesso e più sicuro. Vediamo questo aspetto in dettaglio.
Riduzione della complessità
In determinate condizioni, lo sviluppo dell'interfaccia utente basato sul back-end o sul server può essere molto meno complesso rispetto alle divisioni front-end e back-end. Dal punto di vista dello sviluppatore, lo sviluppo dell'interfaccia utente guidato dal server riduce lo stress cognitivo. Senza dover considerare due ambienti di programmazione, lo sviluppatore può concentrarsi maggiormente sul valore aggiunto dell'applicazione che sta creando. L'eliminazione della duplicazione riduce notevolmente anche la complessità di queste applicazioni. Non è necessario identificare il software API di backend e il software dell'interfaccia utente, perché la logica di verifica è gestita in un'unica sede.
Sicurezza
Lo sviluppo dell'interfaccia utente guidato dal server non rende mai visibili le sue specifiche al browser e fornisce solo i dati precisi necessari per modificare l'interfaccia utente. Rispetto allo scenario in cui i programmatori trasmettono i dati appropriati per un determinato contatto dell'interfaccia utente, questa è una strategia di sviluppo intrinsecamente più sicura. Di conseguenza, gli endpoint API non riveleranno troppe informazioni al browser JavaScript. In questo modo è più difficile che si verifichi un hack o una violazione dei dati. Questo aspetto è molto importante per mantenere la reputazione di un'azienda e vitale per la logica aziendale.
Team full-stack
I team di sviluppo sono spesso divisi in gruppi diversi. Ciò richiede una certa integrazione delle varie parti del software una volta terminati i singoli componenti. Una rigida segregazione frontend-backend può causare un certo distacco tra i team, poiché le varie aree richiedono conoscenze specialistiche. Questo rende più difficile per gli sviluppatori considerare l'intera logica di business end-to-end, perché si occupano solo di una parte.
Se siete un ingegnere full-stack, questo sarà molto più facile da gestire. I potenziali svantaggi o vantaggi dei componenti dell'interfaccia utente possono essere facilmente compresi. I team full-stack possono implementare lo sviluppo dell'interfaccia utente guidata dal server e la necessità di integrazione può essere ridotta in una certa misura.
Svantaggi dell'interfaccia utente guidata dal server
Sebbene l'uso del backend o del rendering guidato dal server sembri un concetto semplice, la profondità dell'idea aumenta di pari passo con la complessità dell'applicazione e della logica aziendale, alcuni dei principali svantaggi associati alle interfacce utente guidate dal server sono:
Tempi di caricamento più lunghi
Lo svantaggio fondamentale di un rendering guidato dal server è che il server o il backend crea una nuova pagina web per ogni connessione con un client. Il client deve poi accedere nuovamente a questa pagina. Questa attività può comportare una mancanza di reattività e un notevole aumento dei tempi di caricamento. Sebbene il rendering backend o lato server sia ottimo per la creazione di siti HTML statici, può rallentare la visualizzazione delle pagine web o della schermata iniziale nelle applicazioni più complesse, a causa delle regolari chiamate al server.
Più costoso
Per lanciare un'applicazione server-driven è necessario acquisire un server o un backend serverless, con conseguente aumento dei costi operativi. Il processo può essere costoso e richiedere molte risorse, poiché il rendering guidato dal server non è lo standard per le pagine web in JavaScript. Per le aziende più piccole potrebbe essere difficile reperire fondi per tali server.
Incompatibilità e dimensioni maggiori dell'HTML
Il rendering lato server è incompatibile con alcuni strumenti e programmi di terze parti. Le applicazioni server-driven hanno anche una dimensione HTML maggiore, come risultato della condizione di idratazione integrata. Questo aspetto deve essere tenuto in considerazione, poiché rappresenta un possibile rischio se viene applicato in modo improprio.
Storia dell'interfaccia utente server-driven
Negli anni '60 e '70 i computer erano enormi, costosi e utilizzati principalmente dalle grandi aziende. Poiché era impraticabile per ogni utente avere un computer grande quanto una stanza, fu creata la tecnologia mainframe, che permetteva a più persone di utilizzare un sistema informatico. L'interfaccia utente, creata utilizzando i risultati dei calcoli dei comandi del terminale, veniva poi riportata sui monitor per essere presentata. Questi terminali divennero i primi thin client. I thin client sono stati così definiti a causa della loro potenza di calcolo estremamente limitata e della dipendenza da una macchina esterna per la produzione dell'interfaccia utente.
Il personal computer è nato in seguito allo sviluppo del microprocessore alla fine degli anni '70, che ha ridotto drasticamente il prezzo e le dimensioni dei computer. Le applicazioni venivano scaricate e gestite separatamente sul browser di ciascun utente. Il PC era un computer autonomo dotato di tutti i componenti necessari per la visualizzazione dell'interfaccia utente. Queste workstation completamente autonome furono i primi thick client.
I siti web o le applicazioni visualizzate con un browser web potevano godere di molti dei vantaggi del thin client grazie all'ampia disponibilità di Internet negli anni '90. Tutti coloro che disponevano di un browser web, come i computer, erano in grado di visualizzare l'interfaccia utente. Chiunque disponesse di un browser Web e di un servizio Internet poteva utilizzare le capacità di calcolo centralizzate su computer dedicati, noti come server. Utilizzando l'HTML, un linguaggio di markup standard, i server creavano l'applicazione dell'interfaccia utente e la trasmettevano al browser web dell'utente. I browser Web dovevano essere impostati su ogni browser remoto, ma avevano esigenze di prestazioni molto inferiori e spesso erano in grado di risolvere i problemi operativi di un'organizzazione.
Negli anni 2000 i telefoni cellulari hanno iniziato a progredire e ad avere la capacità di eseguire applicazioni in modo indipendente. Quando si utilizzava un cellulare come thin client per visualizzare le pagine web, il server o il backend doveva trasmettere l'intera applicazione dell'interfaccia utente al telefono via Internet, proprio come avveniva per i personal computer. A quel tempo, però, le reti mobili erano lente. Era quindi frustrante sfogliare le pagine web.
Quando l'iPhone ha debuttato nel 2007, ha rivoluzionato ciò che si poteva fare con uno smartphone. L'iPhone è arrivato con una serie completa di programmi installati, invece di richiedere agli utenti di ottenere il software attraverso i siti web o un'applicazione. Apple ha introdotto l'App Store e Android ha adottato il Google Play Store, consentendo agli sviluppatori esterni di creare applicazioni. Queste applicazioni offrivano un'esperienza utente di gran lunga superiore, perché tutto ciò che era necessario per mostrare l'interfaccia utente era incluso nell'applicazione e poteva essere utilizzato senza servizio Internet.
Negli ultimi quarant'anni la distribuzione del software si è alternata tra thin e thick client, con le applicazioni native, che sono thick client, predominanti sui dispositivi mobili. Alcuni dei vantaggi del thin client sono stati estesi alle applicazioni native da SDUI. Con una strategia di sviluppo SDUI, i server possono controllare porzioni dell'interfaccia utente di un'applicazione nativa e inviarle via web agli smartphone degli utenti. L'interfaccia utente di un'applicazione nativa può essere modificata rapidamente senza dover installare una nuova versione del software.
Framework e strumenti per lo sviluppo server-driven
Mentre il server esegue il rendering di un'applicazione, il rendering lato client viene eseguito dal browser. Esistono diversi framework attualmente disponibili e alcuni dei più utilizzati sono:
È un framework JavaScript UI gratuito e open-source che può essere combinato con alcuni altri strumenti per creare un ambiente di sviluppo full-stack per applicazioni online.
Si tratta di un toolkit JavaScript che consente di creare elementi riutilizzabili per l'interfaccia utente e di comporli in modo semplice per costruire programmi enormi e altamente scalabili.
- Angolare
Angular Universal è uno strumento di sviluppo backend o guidato dal server.
Interfaccia utente server-driven e AppMaster
Oggi è possibile creare applicazioni e programmi anche con pochissima o quasi nessuna esperienza di codifica. Questo è possibile con l'aiuto di piattaforme e strumenti no-code. Tali piattaforme consentono agli sviluppatori e ai non programmatori di creare un'applicazione software utilizzando le interfacce utente e la configurazione piuttosto che la programmazione informatica tradizionale. Il no-code ha reso lo sviluppo di software più facile e accessibile.
Ciò è possibile grazie all'aiuto di piattaforme no-code come AppMaster. Con AppMaster è possibile progettare un'applicazione anche senza alcuna esperienza di codifica. Inoltre, non dovrete preoccuparvi dei diritti del codice sorgente creato, che vi apparterrà. Il codice può anche essere generato rapidamente.
La strategia server-driven di AppMaster consente di aggiornare le app in tempo reale. È possibile accedere all'hardware di dispositivi come iPhone e iPad direttamente con un'interfaccia utente backend o server-driven. La vostra applicazione arriva sul mercato quasi 10 volte più velocemente rispetto allo sviluppo tradizionale e agli aggiornamenti dell'interfaccia utente. Con AppMaster potete sfruttare l'utilità dello sviluppo dell'interfaccia utente guidata dal backend.
Conclusioni
La domanda finale se lo sviluppo guidato dal server sia adatto alla vostra applicazione dipende dalla sua funzionalità. Se la vostra applicazione è dinamica e presenta molti elementi, SDUI potrebbe essere una buona idea. Oltre ai vantaggi sopra menzionati, aiuta anche i siti web e le applicazioni a posizionarsi nella classifica SEO. È importante comprendere i vantaggi e gli svantaggi dello sviluppo dell'interfaccia utente guidata dal server prima di implementarla. L'SDUI a volte necessita di maggiori risorse e, se la si utilizza, si deve essere in grado di fornirle.
Se volete solo costruire un sito web statico, che volete caricare velocemente, allora lo sviluppo lato client più semplice potrebbe fare al caso vostro. In definitiva, dovreste valutare le esigenze della vostra applicazione e la logica di business che state implementando e decidere se lo sviluppo backend o server-driven fa al caso vostro.
