Protocolli di rete

Protocolli di rete

I protocolli sono un insieme di regole utilizzate dalle due macchine per scambiarsi informazioni e specifica cosa deve essere comunicato, in che modo e quando. Se le due macchine sono remote, si parla di protocollo di rete. Una caratteristica comune dei protocolli di rete è il loro essere strutturati in livelli sovrapposti. Il livello superiore esegue richieste al livello sottostante e i livelli uguali su macchine diverse conversano tramite lo stesso protocollo. Uno dei vantaggi dei protocolli di rete è la progettazione di uno strato che deve esaminare solo alcuni aspetti del problema. Ogni strato non dipende dall’implementazione degli altri strati. Ogni strato fornisce servizi comuni a tutte le funzioni dello strato superiore.

1.1 Modello OSI

Il modello OSI è uno standard per le reti di calcolatori che stabilisce per l’architettura logica di rete una struttura composta da una pila di protocolli di comunicazione di rete suddivisa in 7 livelli, i quali insieme eseguono le funzionalità di rete. I livelli del modello OSI sono i seguenti:

Livello Fisico: definisce il modo in cui di dati sono fisicamente convertiti in segnali digitali sui media di comunicazione (impulsi elettrici, modulazioni della luce, ecc.)

Livello Collegamento Dati: definisce l’interfaccia con la scheda di rete e la condivisione del media di trasmissione.

Livello rete: permette di gestire l’indirizzamento e il routing dei dati, cioè il loro invio tramite la rete.

Livello trasporto: è incaricato del trasporto dei dati, della loro divisione in pacchetti e delle gestione degli eventuali errori di trasmissione.

Livello sessione: definisce l’apertura e la distruzione delle sessioni di comunicazione tra i terminali di rete.

Livello presentazione: definisce il formato dei dati manipolato dal livello applicativo (loro rappresentazione, eventualmente loro compressione e loro codifica) indipendentemente dal sistema.

Livello applicazione: assicura l’interfaccia con le applicazioni. Si tratta quindi del livello più vicino agli utenti, gestito direttamente da alcuni software.

1.2 TCP/IP

I due protocolli TCP e IP furono concepiti da Bob Kahn e Vinton Cerf nel 1974, lo scopo era permettere l’interconnessione delle reti di calcolatori allora esistenti, come quella militare ARPANET, SATNET e altre network tecnologicamente diverse e indipendenti.
Rappresenta in un certo modo l’insieme delle regole di comunicazione su internet e si basa sulla nozione d’indirizzamento IP, cioè il fatto di fornire un indirizzo IP ad ogni terminale di rete per poter inviare dei pacchetti di dati.
Il modello TCP/IP, ispirato al modello OSI, riprende l’approccio modulare, ma ne contiene solo quattro:

Il livello Accesso di rete è il primo livello della pila TCP/IP,rappresenta i mezzi per realizzare una trasmissione di dati attraverso una rete. Il livello di accesso di rete contiene tutte le specifiche riguardo la trasmissione di dati su una rete fisica.
Si incarica delle seguenti nozioni:

  • Invio dei dati sul collegamento.
  • Coordinamento della trasmissione dei dati.
  • Formato dei dati.
  • Conversione dei segnali (analogico/digitale).
  • Controllo degli errori all’arrivo.

Definisce il formato dei pacchetti, sistema di indirizzamento globale e il meccanismo di instradamento dei pacchetti.
Il livello internet è il livello più importante dato che è quello che definisce i pacchetti di dati, e che gestisce le nozioni d’indirizzamento IP. Esso permette l’invio dei pacchetti di dati verso dei terminali remoti. Comprende 5 protocolli, i più importanti sono i protocolli IP, ARP e ICMP.

Il livello trasporto permette a delle applicazioni che girano su terminali remoti di comunicare. Contiene due protocolli che permettono alle due applicazioni di scambiare dei dati indipendentemente dai livelli inferiori.

Questi protocolli sono:

  • TCP: Tcp fornisce un livello di trasporto affidabile e orientato alla connessione. Per affidabile s’intende che prima di inviare i dati il server esegue l’handshaking, cioè chiede al client se è pronto a riceverli. Per orientato alla connessione s’intende la numerazione dei pacchetti in modo che il client li riceva in modo ordinato. Viene utilizzato per la sua sicurezza.
  • UDP: Udp fornisce un servizio di trasporto datagram-oriented (non affidabile) e non orientato alla connessione. I pacchetti quindi vengono inviati senza chiedere al client se è pronto e inviandoli in modo disordinato. Viene utilizzato per la sua velocità.
    Il livello applicazione contiene le applicazioni di rete che permettono di comunicare grazie ai livelli inferiori.
    I software di questo livello comunicano quindi grazie a TCP o UDP.
    Le applicazioni di questo livello sono di differenti tipi, ma la maggior parte sono dei servizi di rete, cioè delle applicazioni fornite all’utente per assicurare l’interfaccia con il sistema operativo.

1.2 APPLICAZIONI DI RETE

Le applicazioni di rete sono composto da diversi elementi , in esecuzione su macchine differenti, che operano in modo indipendente e che possono scambiare informazioni. Le applicazioni sono processi comunicanti e distribuiti. La comunicazione avviene utilizzando i servizi offerti dal sottosistema di comunicazione. La cooperazione può essere implementata secondo vari modelli. Il modello più diffuso è quello client/server.

 

Fonte:  www.brickster.it

JavaScript

JavaScript

In informatica JavaScript è un linguaggio di scripting orientato agli oggetti e agli eventi, comunemente utilizzato nella programmazione Web lato client per la creazione, in siti web e applicazioni web, di effetti dinamici interattivi tramite funzionidi script invocate da eventi innescati a loro volta in vari modi dall’utente sulla pagina web in uso (mousetastiera, caricamento della pagina ecc…).

Tali funzioni di script, utilizzati dunque nella logica di presentazione, possono essere opportunamente inserite in file HTML, in pagine JSP o in appositi file separati con estensione .js poi richiamati nella logica di business. Ultimamente il suo campo di utilizzo è stato esteso alle cosiddette Hybrid App (app ibride), con le quali è possibile creare app per più sistemi operativi utilizzando un unico codice sorgente basato appunto su JavaScript, HTML e CSS.

Java, JavaScript e JScript

Il cambio di nome da LiveScript a JavaScript si ebbe più o meno nel periodo in cui Netscape stava includendo il supporto per la tecnologia Java nel suo browser Netscape Navigator. La scelta del nome si rivelò fonte di grande confusione. Non c’è una vera relazione tra Java e JavaScript; le loro somiglianze sono soprattutto nella sintassi (derivata in entrambi i casi dal linguaggio C); le loro semantiche sono piuttosto diverse, e in particolare i loro object model non hanno relazione e sono ampiamente incompatibili.

Dato il successo di JavaScript come linguaggio per arricchire le pagine webMicrosoft sviluppò un linguaggio compatibile, conosciuto come JScript. La necessità di specifiche comuni fu alla base dello standard ECMA 262 per ECMAScript, di cui sono state pubblicate otto edizioni da quando il lavoro iniziò, nel novembre 1996.

Aspetti strutturali

Le caratteristiche principali di JavaScript sono:

Altri aspetti di interesse: in JavaScript lato client, il codice viene eseguito direttamente sul client e non sul server. Il vantaggio di questo approccio è che, anche con la presenza di script particolarmente complessi, il web server non viene sovraccaricato a causa delle richieste dei client. Di contro, nel caso di script che presentino un codice sorgente particolarmente grande, il tempo per lo scaricamento può diventare abbastanza lungo. Un altro svantaggio è il seguente: ogni informazione che presuppone un accesso a dati memorizzati in un database remoto deve essere rimandata ad un linguaggio che effettui esplicitamente la transazione, per poi restituire i risultati ad una o più variabili JavaScript; operazioni del genere richiedono il caricamento della pagina stessa. Con l’avvento di AJAX tutti questi limiti sono stati superati.

 

Fonte: https://it.wikipedia.org/

PHP – Hypertext Preprocessor

PHP – Hypertext Preprocessor

Installato su oltre 240 milioni di siti web (il 39% del totale) e presente su oltre 2,1 milioni di server (i dati si riferiscono al dicembre 2013), il PHP è uno dei linguaggi di programmazione maggiormente diffusi in ambito web. Nato nel 1995 in Canada per mano del programmatore d’origine groenlandese Rasmus Lerdorf, oggi lo sviluppo e il mantenimento dei PHP sono realizzati dal The PHP Group e distribuito con licenza open source (non compatibile, però, con i dettami dello GNU General Public Licence).

L’acronimo PHP, nella sua accezione originaria, sta per Personal Home Page ma negli anni è stato sostituito da un più attuale (e ricorsivo) PHP: Hypertext Preprocessor (PHP: preprocessore di ipertesti in italiano).

Le caratteristiche del PHP

Il PHP è un linguaggio di programmazione interpretato (ovvero eseguito direttamente dal computer o dal server senza la necessità di essere “tradotto” in linguaggio macchina), creato in origine per lo sviluppo di pagine web dinamiche. Oggi trova applicazione soprattutto nella creazione di applicativi web sul fronte server, ma può essere utilizzato anche per la realizzazione di script a riga di comando e programmi stand-alone ad interfaccia grafica.

Per molti versi, questo linguaggio di programmazione deriva la sua sintassi dal C e da Perl. Si tratta di un linguaggio a tipizzazione debole – è possibile modificare il tipo di una variabile anche nel corso dell’esecuzione del programma stesso – e sostanzialmente di alto livello (ovvero con una sintassi, semantica e grammatica molto simili a quelle del linguaggio umano).

La creatura di Rasmus Lerdorf è in grado di interfacciarsi con diverse tipologie di database: dal MySQL al Microsoft SQL Server passando per MariaDB, Oracle e molti altri ancora. Supporta, inoltre, numerose tecnologie web come il linguaggio di markup XML, i protocolli di comunicazione SOAPIMAPFTP e lo standard per sistemi distribuiti CORBA.

La storia di PHP

Lo sviluppo di questo linguaggio di programmazione ebbe inizio nel 1994, quando Rasmus Lerdorf era alle prese con la creazione di script Common Gateway Interface (“Interfaccia comune per gateway” in italiano) in Perl da utilizzare per gli aggiornamenti periodici del suo sito web. Questi piccoli tool svolgevano compiti tutto sommato semplici e ripetitivi come mostrare il suo curriculum vitae e registrare il numero di visitatori alla sua pagina personale.

Successivamente Lerdorf decise di riscrivere da capo gli script, utilizzando il linguaggio C anziché Perl. Questo per due motivi principali: prima di tutto per migliorare le prestazioni degli script e, in secondo luogo, per estendere le loro capacità sino a renderli in grado di interagire con altri form web presenti nel sito e comunicare con i vari database legati alle sue pagine. Per questo motivo lo sviluppatore canadese decise di chiamare questo nuovo linguaggio – nato dall’ibridazione di C con Perl – Personal Home Page/Forms Interpreter o PHP/FI.

Con questa configurazione, il PHP/FI poteva essere utilizzato per sviluppare piccolissime applicazioni web dinamiche. La prima release pubblica del linguaggio – chiamata “Personal Home Page Tools (PHP Tools) version 1.0” – servì a Lerdorf per scoprire bug eventualmente sfuggiti al suo occhio e migliorarne sintassi e semantica. Venne rilasciata l’8 giugno 1995, dopo quasi dodici mesi di lavoro serrato.

Inizialmente il PHP non era pensato – né tantomeno realizzato – per essere un linguaggio di programmazione a sé stante. Con il passare del tempo, e al crescere della comunità di sviluppatori web che lo utilizzava, si decise di dare una sistematizzazione al corpus di funzioni e script realizzati. Da questo lavoro nacque la seconda release di PHP/FI, lanciata nel novembre 1997.

La seconda versione, però, non ebbe grande fortuna e fu sostituita nell’arco di pochi mesi. Grazie al lavoro dei programmatori Zeev Suraski e Andi Gutmans, il parser di PHP fu riscritto completamente, rendendolo più efficiente e funzionale. Ciò portò al rilascio di PHP 3.0 nel giugno 1998.

Una volta rilasciata la terza versione del linguaggio di programmazione per il web, Suraski e Gutmans iniziarono a lavorare sulla riscrittura del core di PHP. Ciò portò allo sviluppo del cosiddetto Zend Engine, motore di scripting che interpreta il linguaggio e lo traduce in pagine web. La quarta release di PHP, “spinta” dallo Zend Engine, fu rilasciata il 22 maggio 2000, sostituita quattro anni dopo (circa) da PHP 5.0.

Rispetto alla precedente, la nuova versione presentava varie novità: dal supporto migliorato per il paradigma della programmazione orientata agli oggetti al PHP Data Object (un’estensione che fornisce un’interfaccia grafica leggera ma efficace per accedere a database).

Copyright © CULTUR-E

Architettura Client / Server

Client / Server

In informatica il termine sistema client-server  (letteralmente cliente-serviente) indica un’architettura di rete nella quale genericamente un computer client o terminale si connette ad un server per la fruizione di un certo servizio, quale ad esempio la condivisione di una certa risorsa hardware/software con altri client, appoggiandosi alla sottostante architettura protocollare.

Più semplicemente, i sistemi client/server sono un’evoluzione dei sistemi basati sulla condivisione semplice delle risorse: la presenza di un server permette ad un certo numero di client di condividerne le risorse, lasciando che sia il server a gestire gli accessi alle risorse per evitare conflitti di utilizzazione tipici dei primi sistemi informatici.

Esempi di sistemi client/server:

Che cos’è la tecnologia lato server?

Una tecnologia lato server è usata nello sviluppo di siti con elementi dinamici e nelle applicazioni web; si basa sull’uso di script che vengono eseguiti dal web server con l’aiuto dei linguaggi di scripting più adatti, quando un client richiede i contenuti corrispondenti. Spesso il compito degli script è quello di raccogliere i giusti dati da un database ed inserirli nel sito web. L’utente vi accede tramite pagine HTML, ma il codice sorgente degli script rimane completamente nascosto e non è quindi visionabile.

L’uso di questi script lato server presuppone che il client continui a inviare altre richieste al web server per far arrivare agli utenti le nuove informazioni modificate. Ciò significa da una parte un sovraccarico delle capacità del server, cosa che si ripercuote sui tempi di risposta del web server, e dall’altra prevede una connessione esistente al server, indispensabile per far visualizzare l’offerta web.

Agli albori del World Wide Web gli script lato server avvenivano quasi esclusivamente quando gli sviluppatori scrivevano i programmi in C ed eseguivano script in Perl o dalla riga di comando. Queste applicazioni venivano eseguite ed interpretate dal sistema operativo del server, in modo da poter trasmettere il risultato del web server tramite una Common Gateway Interface (CGI) al browser richiedente. Molti web server moderni possono nel frattempo eseguire gli script direttamente, ad esempio grazie ad appositi moduli. Oggigiorno il linguaggio di scripting lato server più utilizzato è PHP, cioè il linguaggio di programmazione rilasciato nel 1995 e che si basa molto su C e Perl.

Che cos’è la tecnologia lato client?

Anche la tecnologia lato client viene utilizzata dagli sviluppatori web per realizzare progetti con contenuti dinamici. A differenza della variante lato server, gli script non vengono però programmati dal server, bensì elaborati ed eseguiti dal client richiedente. Per questo si integrano gli script nel documento HTML o XHTML o si scrivono in un file separato, che si collega al documento. Se l’utente apre una pagina o un’applicazione web con uno script lato client, il web server invia un documento HTML e uno script al browser, che lo esegue e presenta il risultato finale. Gli script lato client possono inoltre contenere istruzioni concrete per il browser, indicando ad esempio come devono reagire a precise azioni dell’utente o ad un click su un pulsante. Spesso non è necessario che il client stabilisca un nuovo contatto con il web server.

Visto che gli script vengono eseguiti nel browser dell’utente, è possibile visionare il codice sorgente, al contrario di quanto avviene per gli script lato server. L’interpretazione di questi script presuppone che il linguaggio di programmazione corrispondente venga capito dal browser. Dato che anche finestre pop-up e strumenti di tracking si basano su script lato client e ne influenzano così i tempi di caricamento, ci sono diverse estensioni per il browser che bloccano questi script.

Il linguaggio di scripting lato client più importante è JavaScript, che è stato sviluppato dal predecessore di Mozilla, Netscape, e rilasciato nel 1995 con la versione precedente del browser Navigator 2.0, conosciuto all’epoca con il nome di LiveScript. Si è diffuso velocemente ed è diventato così un linguaggio di scripting universale per tutti i browser comuni.

Da citare è anche Shockwave Flash (SWF), nonostante presenti delle limitazioni significative: il linguaggio orientato agli oggetti è un componente importante del Flash Player di Adobe, che è stato per molto tempo il software principale per tutti i video nel World Wide Web. Per via di diverse falle di sicurezza e dello sviluppo di nuove tecniche, come HTML5, i video e le animazioni Flash, un tempo molto diffuse, sono ormai sempre meno utilizzate. Agli inizi del web erano anche molto popolari tecnologie quali Microsoft Silverlight e Java applet.

Script lato client vs. script lato server

Il luogo di esecuzione degli script ha un’influenza notevole sulla struttura dei progetti web. Se la maggior parte degli script vengono trasmessi dal browser, il sito o l’applicazione web saranno più “leggeri” per il server, visto che non è responsabile della loro esecuzione. Così le risorse server vengono notevolmente alleggerite, anche se si possono verificare riduzioni della performance per gli utenti che vi accedono.

Basandosi solo su JavaScript, che è una tecnologia lato client, gli sviluppatori devono fare i conti con una maggiore complessità perché molti meccanismi di framework efficienti, come ASP.NET, devono riprodurre il modello MVC.  Altri problemi nascono dal fatto che, sempre nel caso di script lato client, si viene informati che il rispettivo browser supporta i linguaggi di scripting utilizzati con tutte le funzionalità e che l’utente non usa estensioni che ne bloccano l’uso.

Per evitare di far sovraccaricare il client o il server, dovreste cercare di trovare un buon compromesso tra script lato server e lato client e preoccuparvi di attuare misure aggiuntive, come il caching dei contenuti statici e utilizzare tecnologie moderne come AJAX, per fare in modo che il vostro progetto web si carichi il più velocemente possibile.

L’ultima tecnologia citata è un’abbreviazione per “Asynchronous JavaScript and XML“, che descrive la possibilità della trasmissione dei dati asincrona tra client e server. Senza dover caricare completamente la pagina ogni volta, il web server può reagire alle richieste e agli input dell’utente quasi in tempo reale e scambiare così i dati con il browser. Un classico esempio per la messa in atto della tecnica AJAX sono i Google Suggests, cioè i suggerimenti di ricerca di Google, che compaiono automaticamente sul motore di ricerca mentre si scrive una parola chiave.

Fonte: www.wikipedia.org

Cos’è l’UI design?

L’UI design (acronimo di User Interface design) è un sottoinsieme dell’UX design, in tutto e per tutto la sua “anima visual”. Ed è anche la mansione più facilmente travisata e soggetta a libera interpretazione da parte delle aziende negli annunci di lavoro.
Mentre la User Experience è un agglomerato di azioni focalizzate all’ottimizzazione di un prodotto, l’UI design si occupa prettamente della presentazione del prodotto stesso (o del brand, del servizio, dell’azienda), il che per alcune compagnie implica una conoscenza obbligatoria di brand design e/o front end development, mentre per altre è sufficiente essere esperti di graphic design.
Nessuna delle due scuole di pensiero è più o meno corretta dell’altra: si tratta in soldoni di diverse facciate della medesima disciplina.
L’UI designer è infatti deputato a tutto ciò che riguarda la parte visual e interattiva di un prodotto web, in primis l’interfaccia che si presenta all’utente e che rappresenta il primissimo impatto con il brand.
Mi trasmette fiducia? Mi sta guidando verso ciò di cui ho bisogno? Dove sono portato a cliccare?
Lo scopo ultimo è quello di guidare l’utente all’interno della pagina, indicandogli con chiarezza e precisione dove può trovare ciò che cerca esclusivamente attraverso l’interfaccia.

Mentre l’UX designer non ha necessariamente bisogno di conoscere il codice, all’UI designer viene sempre più spesso richiesto di approcciarsi alla programmazione web per poter costruire una migliore interattività con l’utente. Da questo punto di vista, la sua figura e quella del web designer si stanno lentamente fondendo e diventando un’unica mansione.
L’UI designer è anche focalizzato sullo storytelling come parte integrante della presentazione di un brand, e spesso stende una style guide contenente tutti gli aspetti cruciali della brand identity (utilizzo del logo, font, ausili grafici per i social media…) che serve ad uniformare e rendere coerente la comunicazione.
A lui è affidato il compito di trovare il miglior modo per trasmettere valori, mission e vision aziendale attraverso la comunicazione visiva.

Quale dei due aspetti è più importante?

Non si tratta di decidere se dedicarsi ad una o all’altra mansione: entrambe sono irrinunciabili.
Se una pagina è efficientissima dal punto di vista dell’esperienza utente ma è esteticamente inguardabile, probabilmente non è stato fatto un buon lavoro di UI design.
Se al contrario la pagina è accattivante e ben costruita ma presenta evidenti problemi di navigazione, manca alla base un processo di UX design.
Le due discipline si completano a vicenda e vanno sempre curate in egual misura.

Scegliere in quale delle due specializzarsi dipende dalle attitudini e dal carattere: un individuo più portato a creare sicuramente avrà un interesse maggiore per l’UI design, mentre una persona orientata anche all’analisi, alla ricerca e al coordinamento di un team troverà probabilmente la sua strada nell’UX design.

UX: il processo di design

Non esiste una definizione unica e standard di processo UX che vale per tutti i progetti, ma piuttosto una serie di fasi che possono essere reiterate durante tutto il ciclo di vita del prodotto al fine di migliorarlo. Il processo può essere più rapido e snello per progetti piccoli, in cui alcune fasi ed attività non sarebbero neanche praticabili (lancio in Beta, interviste, personas, ecc…) o comunque avrebbero un costo troppo elevato rispetto ai possibili benefici. Per avere un’idea più chiara vediamo in cosa consistono le fasi del processo.

Strategia

Come suggerisce il nome stesso, in questa fase si studia e si definisce la visione strategica del prodotto, che normalmente rappresenta l’azienda o comunque un brand ed implica una visione a lungo termine.

La strategia alla base di un progetto UX definisce il ruolo che il prodotto deve avere all’interno dell’azienda stessa e del mercato, gli obiettivi del prodotto e come verranno misurati i relativi risultati. In sintesi, è una fase strategica finalizzata a capire cosa si vuole da quel prodotto ecosa deve rappresentare.

Tipicamente questa fase non è in carico al team di UX (o almeno non del tutto) ed avviene solo nelle grandi aziende e per prodotti che prevedono investimenti ingenti e/o grandi numeri in termini di ricavi.

In progetti complessi, la strategia è però fondamentale per creare le linee guida e gli input per le successive fasi del processo.

Ricerca

Questa fase comprende tutte le attività di ricerca o di scoperta relative al nostro progetto, che normalmente si concentrano sugli utenti e sui competitor. In progetti molto complessi questa fase è significativa, mentre per piccoli siti o prodotti viene saltata o resa essenziale.

L’attività di ricerca comporta una raccolta di dati a partire dall’osservazione, da colloqui e questionari sottoposti agli utenti. I risultati di questa fase sono molto importanti per l’ottimizzazione della UX.

Analisi

In questa fase si analizzano i dati raccolti durante la ricerca o a seguito di altre attività. Raccogliere, organizzare e “capire” una serie di dati può aiutare a comprendere perché una cosa funziona o meno, fornendo spunti utili ai designer per trovare o migliorare alcune soluzioni. Per un prodotto nuovo, si definiscono gli scenari e le caratteristiche del nostro prodotto.

Design

La fase di design del processo UX serve per mostrare le idee agli utenti e ricevere i loro feedback. Per farlo, si realizzano schizzi su carta, wireframe, prototipi interattivi a bassa fedeltà per evitare che l’utente si concentri sulla grafica, il brand o dettagli visivi. La progettazione parte dalle informazioni raccolte nelle fasi precedenti e si concentra sulla struttura, il layout e i macro-contenuti. È una fase collaborativa e iterativa in cui non si presenta un prodotto finito ma piuttosto qualcosa su cui lavorare insieme per cominciare a definire il progetto e rifinirlo man mano.

Produzione

In questa fase in si comincia ad implementare veramente il prodotto con le sue caratteristiche e in accordo ai requisiti definiti nelle fasi precedenti. Le attività consistono principalmente nello sviluppo tecnico e di visual design, inclusi i relativi test.

È grazie a queste attività che le idee diventano il prodotto, ed è interessante notare come anche profili tecnici come gli sviluppatori partecipino (più o meno consapevolmente) al processo di User Experience.

Al termine di questa fase, i clienti/stakeholder e gli utenti vedranno una versione ad alta fedeltà del prodotto, con grafica, contenuti, risorse e funzionalità reali.

Applicare il processo di UX

Applicare questo processo in tutte le sue fasi è molto spesso difficile e costoso in termini di tempo e risorse. Alcune fasi si sovrappongono e difficilmente esistono figure così specializzate che si occupano di una singola attività.

Il concetto principale, punto chiave delle metodologie Agile, è che il processo UX deve essere:

  • iterativo ed incrementale;
  • user-centrico;
  • basato sui feedback.

Proprio per questo si tende a “fare” piuttosto che analizzare oppure ad usare strumenti che permettono di testare velocemente e raccogliere feedback senza implementare e rilasciare in produzione la soluzione alternativa (A/B testing).

User-centered design

Una tipologia più specifica di processo che mette al primo posto l’utente finale è lo user-centered design (UCD). Il processo UCD ripropone le fasi di progettazione e sviluppo del ciclo di vita, ma con focus primario sulla comprensione profonda di chi userà il prodotto e del suo contesto d’uso.

Non esiste una definizione unica del processo e delle sue attività, ma piuttosto il concetto di individuare i bisogni dell’utente finale e di soddisfarli.

Con questa metodologia, il design del prodotto viene sempre testato dall’utente (presente durante tutte le fasi) e la validazione avviene attraverso la verifica della sua soddisfazione.

Le forze che guidano lo sviluppo di un prodotto sono gli utenti reali e i loro bisogni, non le tecnologie.

UX design

In questa fase di progettazione si comincia ad essere “operativi”, realizzando bozze in grado di visualizzare idee ed informazioni. Esistono diverse terminologie per indicare queste bozze in base al loro grado di fedeltà rispetto al prodotto “definitivo” (nel nostro caso, un sito web).

Esiste una sorta di workflow interno che porta un draft da bassa ad alta fedeltà: sketch, wireframe, prototipo, mockup. Vediamo insieme i termini e le loro differenze.

Sketch

Letteralmente, indica uno schizzo su carta realizzato con penna o matita in modo rapido ed approssimativo. Si può cambiare, cancellare, buttare e rifare velocemente, e proprio per questo è efficace per fissare idee e proposte segnando appunti, note e dubbi. La loro realizzazione è a costo zero. Lo sketching si può considerare una parte della fase di wireframing, perchè uno sketch è la versione cartacea e spesso la base di partenza di un wireframe.

Wireframe

Il wireframe è un documento digitale che rappresenta lo scheletro di un sito.

Il termine indica nello sviluppo di grafica 3D un “modello in fil di ferro”, quindi la struttura di un oggetto, privo di texture e tutti gli elementi decorativi. Questa versione a bassissima fedeltà del design (spesso bianco e nero) si concentra sui macro-contenuti, l’organizzazione delle informazioni e come l’utente interagisce con l’interfaccia. La suaessenzialità visiva permette di concentrarsi sull’usabilità e la funzionalità ed è per questo uno strumento molto utile, soprattutto nel design di un prodotto nuovo e di major features.

Funge da documentazione e facilita la comunicazione (raccolta e scambio di feedback).

Prototipo

Il prototipo è la rappresentazione da media ad alta fedeltà del prodotto che permette di simulare l’interazione dell’utente con l’interfaccia. C’è chi sovrappone il termine con con quello di wireframe interattivo, ma il prototipo è più dettagliato e si avvicina maggiormente al prodotto finale, sia in termini di aspetto visuale (non è una bozza in bianco e nero) che di interazione. Il suo focus è quindi l’interattività ed abilità allo user-testing. Prototipi iper dettagliati (sia graficamente che con gestione di micro interazioni) possono essere molto simili al progetto finale, in questo caso per realizzarli sono necessari dei mockups da importare a cui viene “solo” aggiunta l’interazione.

Questa attività può avere un costo elevato e quindi non sempre è necessario o conveniente farla.

Mockup

Il mockup è il prototipo grafico dell’interfaccia dell’applicazione, in pratica il visual design o la “grafica”. Mostra contenuti e struttura definiti nei wireframes ma si concentra sull’aspetto visuale del prodotto introducendo aspetti grafici legati a stile, colori, forme, distribuzione degli spazi, ecc…

I mockup sono, per definizione, ad alta fedeltà: si realizzano con software di image editing e vengono esportati in immagini che rappresentano le schermate statiche del sito. L’approvazione dei mockups da parte degli stakeholders permette l’inizio dello sviluppo tecnico.

La creazione dei mockup rientra già nella sfera di UI design vera e propria e quindi all’interno della fase di produzione della UX e non più di progettazione.