Università degli Studi di Padova

Transcript

1 Università degli Studi di Padova Dipartimento di Matematica Corso di laurea in Informatica Progettazione e Sviluppo di un Sito Web aziendale tramite CMS Tesi di Laurea Triennale Laureando: Marco Begolo Relatore: prof.ssa Ombretta Gaggi Anno Accademico 2012/2013

2 ii

3 A chi mi è stato a fianco in questi quattro anni... iii

4 iv

5 Indice 1 Introduzione L Azienda Il Progetto Obiettivi Analisi dei Requisiti Analisi degli Attori Scenari d uso Analisi dei Requisiti Suddivisione in base alle aree di appartenenza Suddivisione in base alla priorità Catalogazione Specifica dei requisiti Requisiti di contenuto Requisiti Strutturali Requisiti Comportamentali Requisiti di Accessibilità Requisiti Navigazionali Requisiti di Presentazione Requisiti dei Servizi Tracciamento dei requisiti Analisi delle Tecnologie Tecnologie WEB Linguaggio di markup Linguaggio di formattazione Linguaggio di scripting Server-side Linguaggio di scripting Client-side Database Management System (DBMS) Tecnologie WEB ausiliarie CMS (Content Management System) Struttura dei CMS Drupal Joomla! WordPress Framework v

6 vi INDICE Bootstrap Foundation Gumby Conclusioni sull utilizzo di front-end framework Librerie JQuery Less JQuery Mobile Strumenti di sviluppo IDE (Integrated Development Environment) XAMPP Progettazione e Processo di Sviluppo Architettura Software Architettura Model-View-Controller (MVC) Architettura 3-Tier Architettura Multi-Tier Modello di Progettazione Descrizione del modello di progettazione adottato Progettazione Back-End Progettazione della base informativa Progettazione della struttura dei contenuti Progettazione di applicazioni e servizi Gallerie Mappa dinamica Breadcrumb Slider News ed Eventi Most Clicked Links Our History Progettazione Front-end Progettazione di applicazioni e servizi Gallerie Mappa dinamica Breadcrumb Slider News ed Eventi Most Clicked Links Our History Progettazione del Mockup Realizzazione dei Wireframe Realizzazione dei Mockup

7 INDICE vii 7 Sviluppo dell area amministrativa Installazione e configurazione del CMS Implementazione della base informativa Implementazione delle applicazioni e dei servizi Gallerie Mappa dinamica Breadcrumb Slider News ed Eventi Most Clicked Links Our History Sviluppo del Tema Grafico Metodologia di sviluppo dell interfaccia grafica Creazione di un nuovo Theme Template Header e Footer Scripting client-side Fogli di stile Media Queries e Breakpoint Font e tipografia Accessibilità e qualità del software Verifica dell accessibilità Validazione HTML5 e CSS Controllo Cross-Browser Test Portabilità Strumenti di verifica Conclusioni Considerazioni sul raggiungimento degli obiettivi Problemi riscontrati Considerazioni finali Bibliografia 97 Glossario 101

8 viii INDICE

9 Elenco delle figure 1.1 Logo dell azienda Mappa concettuale dei contenuti del sito Logo Drupal Logo Joomla Screenshot della schermata di back-end in Joomla Logo WordPress Screenshot della schermata di back-end in WordPress Logo Bootstrap Logo Foundation Logo Gumby Logo JQuery Logo Less Pannello amministrativo di XAMPP Rappresentazione UML del pattern MVC Modello web per la separazione di Struttura, presentazione e comportamento Architettura 3-Tier[15] Architettura 4-Tier Esempio di Progettazione Lineare Modello di Progettazione adottato Custom Post Type nella Dashboard di WordPress Schermata per la gestione delle categorie in WordPress Effetto parallasse Effetto parallasse simulato con più piani Wireframe versione Mobile Wireframe versione Desktop - Home Page Wireframe versione Desktop - Prodotti Mockup Home Page Mobile Mockup Home Page Desktop Mockup Products Mobile Mockup Products Desktop Mockup Menù Desktop Mockup Menù Tablet ix

10 x ELENCO DELLE FIGURE 7.1 Esempio di Meta Box nell area amministrativa Area amministrativa del plugin NextGEN Gallery Anteprima del plugin NextGEN Gallery - Thumbnail Anteprima del plugin NextGEN Gallery - Formato intero Esempio di mappa con visualizzazione per regioni Mantenimento della qualità di immagine per immagini vettoriali Esempio di mappa con visualizzazione con marcatori Esempio di Breadcrumb in layout Mobile Screenshot d esempio delle principali fasi dello Slider Esempio di randomizzazione dei link in Home Page Screenshot d esempio per la sezione Our History Gerarchia di Template in WordPress[19] Parametri di valutazione della qualità del software Risultato del test di verifica statica sull accessibilità Risultato del test di verifica statica del codice di markup Risultato del test di verifica statica del codice CSS Screenshot d esempio per lo strumento di analisi di Chrome Screenshot d esempio per il primo bookmarklet Screenshot d esempio per il secondo bookmarklet

11 Elenco delle tabelle 2.1 Tabella degli Attori Tracciamento dei Requisiti Elenco dei file di Template realizzati per il progetto Elenco degli script Javascript realizzati dal laureando Elenco dei fogli di stile utilizzati e loro descrizione xi

12 xii ELENCO DELLE TABELLE

13 xiii Everything should be made as simple as possible, but not simpler. Albert Einstein The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. Tim Berners Lee Ringraziamenti Grazie alla prof.ssa Gaggi, per avermi aiutato molto pazientemente durante il periodo di tirocinio e nello svolgimento della tesi. Grazie a Stefania e Mattia, per avermi guidato durante il tirocinio aziendale. Grazie a tutti i professori del corso di laurea di Informatica che con la loro guida e la loro professionalità sono riusciti a guidarmi nel mio percorso accademico e hanno aperto nuove prospettive per il mio futuro. Grazie ai miei amici, perché ci sono sempre stati. Grazie alla mia famiglia, per avermi sempre sostenuto e incoraggiato. Padova, 11 ottobre 2013 Marco Begolo

14 xiv

15 Capitolo 1 Introduzione 1.1 L Azienda Figura 1.1: Logo dell azienda Bedeschi S.p.A. è un azienda padovana che opera nel settore del trattamento delle materie prime dal 1908, rendendola una delle aziende con maggior esperienza in Europa e nel mondo. Si occupa della produzione di macchinari per l estrusione di laterizi [g], bulk material handling [g], impianti di frantumazione e allestimento di petroliere. I punti di forza dell azienda sono l esperienza centenaria, la conduzione familiare che ha caratterizzato l intero sviluppo sin dal 1908 e soprattutto la presenza massiccia a livello mondiale. Questi punti dovranno assolutamente essere enfatizzati nel nuovo sito in quanto caratterizzano estremamente l azienda e la filosofia con la quale viene guidata. 1.2 Il Progetto Il progetto consiste nel realizzare il nuovo sito internet per l azienda Bedeschi. Il precedente sito risulta insoddisfacente in quanto presenta solo alcune gallerie di immagini poco documentate e localizzate, una brevissima storia aziendale e alcuni contatti. Il sito dovrà rispettare alcuni princìpi base quali accessibilità e adattabilità, mentre la sua realizzazione dovrà essere effettuata seguendo i princìpi della qualità del software. 1.3 Obiettivi Oltre, ovviamente, a realizzare il sito, il progetto si prefigge gli obiettivi di: formare il tirocinante riguardo l intero ciclo della realizzazione di una piattaforma web, dall analisi allo sviluppo 1

16 2 CAPITOLO 1. INTRODUZIONE formare il tirocinante riguardo alcuni aspetti della Qualità del Software in ambito web Attraverso l analisi approfondita delle necessità del committente, il tirocinante si è impegnato a definire e soddisfare i requisiti in modo da soddisfare al meglio le richieste del cliente.

17 Capitolo 2 Analisi dei Requisiti Le attività di Analisi sono fondamentali per la buona riuscita di un qualunque tipo di progetto, non solo software. Queste attività consistono nel definire efficientemente gli obiettivi che devono essere soddisfatti affinché il progetto possa ritenersi completato. È fondamentale differenziare i requisiti in base alla loro natura. Infatti, a meno di non trovarsi di fronte a progetti estremamente banali (nel qual caso probabilmente, anche se erroneamente, non si effettuerebbe alcun tipo di analisi preliminare strutturata), vi è innanzitutto una differenziazione riguardo a cosa sia necessario analizzare. Per questo progetto in particolare si è deciso di effettuare tre tipologie di analisi, differenti non per lo scopo o la struttura ma per l ambito di analisi. Questa scelta è dovuta al fatto che l atto del visitare un sito web coinvolge diverse entità; l utente che visita il sito, il sito vero e proprio e (meno ovvio) gli scenari d uso dello stesso. 2.1 Analisi degli Attori Bedeschi S.p.A. è una ditta specializzata nella progettazione e costruzione di tre settori particolari: frantumazione materie minerarie, allestimento petroliere, creazione di fornaci. Il target di utenza risulta pertanto estremamente ridotto e ben definito. Sarà quindi opportuno (ed è stato richiesto dal committente) pensare fin dal principio ad un organizzazione che incentivi questa tipologia di utenza a visitare il loro sito, mentre non è assolutamente necessario che sia incentivata la permanenza da parte di un visitatore casuale. Andiamo ora ad analizzare i possibili attori. Per ognuno di essi saranno riportati profilo, tipologia di connessione ad Internet (in caso possano emergere connessioni particolarmente lente), conoscenza del settore, obiettivi nei confronti del visitatore ed, infine, importanza dello stesso. Utente casuale Profilo: utente che può imbattersi casualmente nel sito Connessione: qualsiasi (56kb 40Mb) Conoscenza del settore: nulla Obiettivi nei suoi confronti: nessuno Importanza: minima 3

18 4 CAPITOLO 2. ANALISI DEI REQUISITI Potenziale cliente Startupper Profilo: un potenziale cliente da poco entrato nel mercato Connessione: business (7Mb 40Mb) Conoscenza del settore: medio-alta Obiettivi nei suoi confronti: comunicare i princìpi dell azienda e la qualità del servizio e dei prodotti. Dare un idea vaga dei costi per evitare disguidi (i prodotti potrebbero essere troppo impegnativi per piccole imprese) Importanza: massima Potenziale cliente Esperto Profilo: un utente, già cliente di altri competitor, in cerca di valide alternative Connessione: business (20Mb 40Mb) Conoscenza del settore: avanzata Obiettivi nei suoi confronti: comunicare i princìpi dell azienda e la qualità del servizio e dei prodotti. L utente dev essere portato a riflettere sulle differenze rispetto al proprio attuale fornitore, e il confronto deve essere sfavorevole per i competitor. Importanza: massima Cliente Profilo: un utente che è già cliente e che cerca informazioni e assistenza Connessione: business (20Mb 40Mb) Conoscenza del settore: avanzata Obiettivi nei suoi confronti: il cliente deve essere accolto molto bene, quindi è opportuno fornire strumenti efficienti e mirati per migliorare la sua esperienza, ad esempio fornire un servizio assistenza o dei contatti chiari, facilmente reperibili e completi. Importanza: massima Competitor Profilo: un utente i cui interessi coincidono con quelli del competitor Connessione: business (20Mb 40Mb) Conoscenza del settore: avanzata Obiettivi nei suoi confronti: il competitor non deve venire a conoscenza di strategie chiave che potrebbero favorirlo nel mercato. Importanza: elevata Esperto web Profilo: un utente che non ha interessi particolari rispetto ai servizi /prodotti, ma che ha comunque degli interessi nei confronti del portale. Potrebbe essere una buona fonte di pubblicità (es.:

19 2.2. SCENARI D USO 5 Connessione: business (20Mb 40Mb) Conoscenza del settore: nulla-media Obiettivi nei suoi confronti: questa tipologia di utente è interessata esclusivamente alla presentazione piuttosto che al contenuto, tuttavia una buona presentazione porta dei vantaggi non trascurabili. Importanza: bassa È possibile visualizzare le informazioni essenziali riassuntive riguardo agli attori in Tabella 2.1. Attore Utente casuale Potenziale cliente Startupper Potenziale cliente Esperto Importanza Obiettivi nei suoi confronti Minima Massima Massima Nessuno Comunicare i princìpi dell azienda e la qualità del servizio e dei prodotti. Dare un idea vaga dei costi per evitare disguidi (i prodotti potrebbero essere troppo impegnativi per piccole imprese) Comunicare i princìpi dell azienda e la qualità del servizio e dei prodotti. L utente dev essere portato a riflettere sulle differenze rispetto al proprio attuale fornitore, e il confronto deve essere sfavorevole per i competitor. Cliente Massima Il cliente deve essere accolto molto bene, quindi è opportuno fornire strumenti efficienti e mirati per migliorare la sua esperienza, ad esempio fornire un servizio assistenza o dei contatti chiari, facilmente reperibili e completi. Competitor Elevata Il competitor non deve venire a conoscenza di strategie chiave che potrebbero favorirlo nel mercato. Esperto Web Bassa Un utente che non ha interessi particolari rispetto ai servizi /prodotti, ma che ha comunque degli interessi nei confronti del portale. Potrebbe essere una buona fonte di pubblicità. Tabella 2.1: Tabella degli Attori 2.2 Scenari d uso Vediamo i diversi scenari d uso del sito per i quattro target d utenza fondamentali (ovvero con importanza maggiore).

20 6 CAPITOLO 2. ANALISI DEI REQUISITI Potenziale cliente Startupper Questa tipologia d utente dev essere incentivata a scegliere Bedeschi come collaboratore/- fornitore. Siamo avvantaggiati in quanto non provengono da altri competitor, perciò non saranno portati ad analizzare aspetti particolarmente critici nella scelta del fornitore. Tuttavia è plausibile (e prudente) immaginare che un potenziale cliente non stia semplicemente visitando il sito, ma che stia confrontando l offerta con quelle dei competitor. Per questo sarà necessario enfatizzare gli aspetti positivi che possono dare maggiore visibilità rispetto a quanto possono fare i competitor. Inoltre, questa tipologia di utenza visiterà il sito in modo molto superficiale ad una prima occhiata. Pertanto sarà necessario comunicare delle informazioni in modo veloce, diretto ed efficace per incentivare l utente ad approfondire la navigazione nel sito. (Es.: le informazioni sullo slider potrebbero essere rivolte a questa tipologia di utenza). Possiamo ora identificare alcuni punti fondamentali di cui tenere conto nella progettazione: Enfatizzare i princìpi aziendali Fornire in home page contenuti accattivanti che prolunghino la permanenza sul sito Potenziale cliente Esperto Un utente esperto nel settore potrebbe essere cliente di competitor, o esserlo stato in passato nel caso di ex dipendenti/soci, o ancora aver avuto delle esperienze non del tutto soddisfacenti con i competitor e quindi cercare un nuovo fornitore. In generale si tratta di un utente che non solo sa molto bene cosa cerca, ma ha anche un elevato livello di attesa. In questo caso è quindi opportuno fornire delle informazioni dettagliate e soprattutto un buon feedback dell azienda tramite referenze e best works (major realizations). Inoltre, se possibile, è opportuno enfatizzare gli elementi di forza rispetto ai competitor. A questa tipologia di utenza sono rivolti quindi i seguenti obiettivi: Offrire contenuti di dettaglio completi e di qualità (senza cercare necessariamente la quantità), possibilmente andando a puntare su elementi critici per i competitor (evidenziando quindi i punti di forza di Bedeschi rispetto ai propri competitor). Enfatizzare i princìpi aziendali Cliente Un cliente visiterà il sito con obiettivi ben diversi da quelli di un potenziale cliente. Generalmente per organizzazioni di questo tipo il sito web non offre servizi e utilità particolarmente utili a chi è già cliente. Oltre a fornire un area riservata in cui condividere documenti riservati al singolo cliente potrebbe essere interessante aggiungere delle modalità per mettersi in contatto con l azienda in modo semplice (ad esempio tele assistenza/help desk via Twitter, faq [frequently asked questions], ecc...) e creare un sistema di feedback reciproco. Lasciare una referenza (anche con video intervista) non è utile solamente al produttore ma anche a chi rilascia la referenza. Tuttavia, in seguito a più colloqui con il personale e l amministrazione di Bedeschi, sono emerse diverse difficoltà nel pensare a come migliorare l esperienza utente dei clienti. Sono state fatte diverse proposte interessanti, ma si è giunti alla conclusione che fornire un

21 2.3. ANALISI DEI REQUISITI 7 sistema di assistenza generale semplice, solido ed efficace potrebbe essere troppo dispendioso in proporzione all effettiva utilità; a differenza di altri ambiti, il tipo di commercio effettuato da Bedeschi è estremamente personalizzato da cliente a cliente. Questo significa che i singoli clienti avranno necessità e problemi estremamente eterogenei, rendendo comunque necessaria una tipologia di assistenza incentrata sul singolo cliente (o sulla singola commissione [g] ), e complicando notevolmente la progettazione di un sistema che sia allo stesso tempo semplice da usare ed effettivamente utile. A questo proposito si è deciso di non fornire ai clienti l accesso ad informazioni o aree dedicate. Competitor Il competitor avrà a disposizione le medesime informazioni dei potenziali clienti e dei clienti, per questo è necessario tenere a mente che alcune caratteristiche salienti dei prodotti e delle installazioni Bedeschi dovranno essere nascosti. Tuttavia tale principio è incoerente con quanto detto precedentemente, ovvero che sarà necessario mettere in evidenza i punti di forza dell azienda rispetto ai competitor. Riconosciamo dunque una situazione critica nel momento in cui una stessa informazione sia molto vantaggiosa se rivolta ad una certa tipologia d utenza (potenziale cliente) e allo stesso tempo sia estremamente controproducente se rivolta ad un competitor. Non potendo fare previsioni a priori sarà necessario valutare di caso in caso il rapporto fra vantaggi e svantaggi dovuti all inserimento di informazioni critiche. Per quanto riguarda i competitor, dunque, dovremo osservare i seguenti princìpi: Evitare di pubblicare contenuti (soprattutto immagini) critici che possano in qualche modo avvantaggiare i competitor 2.3 Analisi dei Requisiti Al fine di gestire e verificare al meglio il lavoro di Analisi è necessario identificare dei requisiti atomici che devono essere rispettati, sia nella progettazione che nel risultato. L identificazione e la catalogazione di tali requisiti, dunque, saranno fondamentali ma allo stesso tempo molto critici. Una delle principali difficoltà che frequentemente si incontra nella stesura di un documento dei requisiti è causata dalla inerente duplicità del contesto a cui esso è rilevante. Il contesto d uso, da un canto, esige la massima semplicità e chiarezza della descrizione dei requisiti, con astrazione da dettagli tecnici e aspetti propri della realizzazione che non siano pertinenti all uso del sistema. Il contesto produttivo, d altro canto, prescrive la verificabilità di ogni requisito attraverso procedure di collaudo, il che spesso richiede precisione formale e dettagli tecnici non appropriati a questo contesto. Per superare questo divario fra livelli di astrazione nella descrizione, sono state proposte varie tecniche di specifica di requisiti, il cui grado di formalità varia notevolmente, dalla informalità di descrizioni narrative in linguaggio naturale, alla semi-formalità di descrizioni che usano notazioni diagrammatiche convenzionali e standardizzate, fino alla rigorosa formalità di specifiche matematicamente ben fondate e verificabili. In base all esperienza personale, al contesto applicativo e alla metodologia di comunicazione avuta con l azienda si è deciso di applicare i princìpi per la definizione e catalogazione dei requisiti che andremo a vedere in seguito.

22 8 CAPITOLO 2. ANALISI DEI REQUISITI Suddivisione in base alle aree di appartenenza Prendiamo ad esempio due requisiti che chiameremo A ( Il sito dev essere realizzato in tonalità di rosso ) e B ( il sito dovrà rispettare il principio della portabilità ). Il primo è evidentemente relativo alla presentazione del sito, e andrà quindi ad influire sul design. Il requisito B, invece, è chiaramente inerente al comportamento del sito, influenzando di conseguenza l interfaccia grafica. È dunque opportuno che tali requisiti siano trattati in ambiti differenti, quello relativo alla presentazione per il requisito A e quello relativo al comportamento per il requisito B. Vedremo ora una descrizione degli ambiti sufficienti ad ottenere una buona suddivisione dei requisiti[12] (tra parentesi il numero utilizzato per la catalogazione dei requisiti, vedi Sezione 2.3.3). Requisiti di contenuto (1): definiscono cosa deve comunicare il sito. Requisiti strutturali (2): definiscono come devono essere comunicati i contenuti. Requisiti comportamentali (3): definiscono come si deve comportare il sito in situazioni di accesso differenti. Requisiti di accessibilità (4): poiché molti requisiti di ambiti diversi fanno a loro volta parte del concetto di accessibilità (ad esempio, la portabilità del sito è sia un requisito di accessibilità che comportamentale) con questa categoria faremo riferimento ai requisiti il cui unico scopo è quello di fornire/migliorare l accessibilità (in particolar modo fanno parte di questa categoria molte delle direttive di accessibilità pensate per gli utenti non normodotati). Requisiti navigazionali (5): definiscono le modalità di navigazione del sito. Requisiti di presentazione (6): definiscono il design. Requisiti dei servizi (7): definiscono i servizi e le modalità per accedervi che il sito deve offrire (ad esempio requisiti inerenti alla parte amministrativa) Suddivisione in base alla priorità È opportuno differenziare i requisiti rispetto alla loro importanza. Saranno definite tre tipologie di priorità dei requisiti: Requisiti Obbligatori: tali requisiti devono essere implementati, pena il mancato raggiungimento degli obiettivi. L insieme di tali requisiti (ed il loro soddisfacimento) rappresenta il valore reale del prodotto. Requisiti Desiderabili (*): tali requisiti dovrebbero essere implementati, non sono fondamentali ma danno valore aggiunto, hanno quindi un elevata utilità. Requisiti Opzionali (**): sono requisiti relativamente utili o successivamente trattabili. Il loro soddisfacimento è facoltativo ma renderebbe il sistema più completo.

23 2.4. SPECIFICA DEI REQUISITI Catalogazione Una volta determinati i requisiti sarà necessario codificarli affinché possano essere efficientemente verificati. Sarà utilizzata una catalogazione semplice composta da due numeri, X e Y, e una lettera (R), disposti nel seguente modo RX.Y dove con X si indica l ambito del requisito (da 1 a 7, vedi Sezione 2.3.1) e con Y il numero di requisiti all interno di quell ambito. Ad esempio, con la dicitura R1.3 si indica il requisito numero 3 dell ambito Requisiti di Contenuto ( Mission: la descrizione in breve dei princìpi aziendali e della missione di Bedeschi., si veda la Sezione per maggior chiarezza). 2.4 Specifica dei requisiti Nonostante sia stata più volte ribadita l importanza di un adeguata attività di analisi non è stato spiegato come essa debba avvenire. Non è semplice definire una prassi che permetta di identificare e catalogare i requisiti, soprattutto se si vuole garantire un certo livello di definizione degli stessi, in quanto questi spesso evolvono nel tempo per diversi motivi. Proprio per questo si è deciso di applicare una metodologia Agile [g], in generale per lo sviluppo dell intero progetto, in particolare per l identificazione dei requisiti. I vantaggi dovuti a questa scelta sono molteplici, ma in particolare ciò che ha permesso di scegliere tale soluzione è stata l estrema disponibilità da parte dell azienda nel collaborare gradualmente durante l intero sviluppo del sito. Segue ora l elenco dei requisiti identificati durante l intero periodo di sviluppo del progetto, suddivisi in base ai diversi ambiti visti precedentemente. I requisiti non segnati sono requisiti obbligatori, i requisiti desiderabili sono contrassegnati da un asterisco (*) e quelli opzionali da due (**) Requisiti di contenuto Questa tipologia di requisiti definisce esclusivamente quali contenuti devono essere presentati. Il primo passo per ottenere ciò è stato un colloquio con il committente, seguito dalla creazione (da parte dell azienda) di una mappa concettuale [g] che riportiamo in Figura 2.1. Figura 2.1: Mappa concettuale dei contenuti del sito

24 10 CAPITOLO 2. ANALISI DEI REQUISITI Da questa mappa si è arrivati a costruire il seguente elenco di (requisiti di) contenuti: Sezione About Us (1): in questa sezione dev essere raccontata l azienda in tutti i suoi aspetti. Our History (2): la storia aziendale a partire dal Mission (3): la descrizione in breve dei princìpi aziendali e della missione di Bedeschi. Key people (4): una descrizione delle figure chiave nella direzione attuale dell azienda. Commitment to Quality ISO (5): l impegno dell azienda nel garantire i massimi standard qualitativi. Global Presence (6): la presenza territoriale di Bedeschi nel mondo Job Opportunities (*) (7): eventuali opportunità di lavoro. Contact Us (8): la pagina contenente i vari contatti, sia della sede centrale che di quelle distaccate, comprensivi di , telefono e posizione geografica. News and Events (9): devono essere disponibili delle news relative a ultimi lavori effettuati, partecipazioni a fiere ecc. Our Customer (10): i clienti dell azienda Reference list (*) (11): una lista dei clienti, possibilmente organizzata geograficamente. Products and Markets (12): una semplice tabella (già presente nelle brochure pubblicitarie del committente) che descrive nel dettaglio i mercati e i prodotti dell azienda. Photo Gallery (13): deve essere disponibile almeno una galleria fotografica. Products (14): visionare nel dettaglio prodotti o famiglie di prodotti, suddivisi secondo i seguenti settori Heavy Clay Mining Bulk Handling Marine Major Realizations (15): i lavori più importanti devono essere pubblicizzati in quanto motivo d orgoglio per l azienda. Most Clicked Links (16): l elenco dei link più interessanti (richiesta esplicita da parte del committente di poter scegliere quali link inserire)

25 2.4. SPECIFICA DEI REQUISITI Requisiti Strutturali Questa tipologia di requisiti definisce come devono essere presentati i contenuti. La maggior parte di essi sono stati individuati tramite colloquio con il committente, ma molti sono stati scelti anche in base a considerazioni personali (discusse successivamente con il committente) dovute all esperienza maturata nel tempo. (1) Il sito deve essere in inglese, con predisposizione all aggiunta di nuove lingue. (2) La sezione Our History deve essere strutturata in linea temporale, ovvero deve essere navigabile muovendosi fra diversi periodi storici. (3) I prodotti devono essere presentati tutti con poche informazioni fondamentali ma d effetto, con la possibilità di visualizzare/scaricare la scheda dettagliata Requisiti Comportamentali Questi requisiti definiscono come deve reagire il sito a metodologie di accesso differenti. (1) Il sito deve essere navigabile da diversi device, rispettando il principio di portabilità (Responsive Web Design). (2) Il sito deve presentare un area amministrativa accessibile solo da determinati utenti (muniti di credenziali d accesso). (3) Per device differenti si deve avere un esperienza di navigazione leggermente differenziata per usufruire delle caratteristiche del device (*) Requisiti di Accessibilità Mantenere un alto livello di accessibilità in un sito web garantisce almeno due vantaggi principali. Il primo è quello di fornire un servizio accessibile con modalità alla portata di utenti con disabilità permanenti, siano esse congenite o acquisite: fanno parte di questa categoria utenti sordi, ciechi, sordo-ciechi, ipovedenti e ciechi ai colori, dislessici, autistici, epilettici, spastici, persone paralizzate o prive degli arti superiori. Sono beneficiari dell accessibilità anche gli anziani che vedono e sentono poco, e in generale chi soffre di malattie degenerative che intaccano progressivamente la vista, l udito, la memoria, l intelletto, la motilità. Infine, tra i beneficiari dell accessibilità vi sono anche persone che non hanno a che fare direttamente con disabilità o malattie: persone dallo scarso livello culturale (generale o specifico), stranieri (rispetto alla lingua del sito), persone dotate di attrezzatura obsoleta, danneggiata o con modalità di utilizzo non standard (ad esempio, utilizzo di una sola mano o comandi vocali). Nonostante questo target d utenza sia particolarmente raro nel settore in cui opera Bedeschi sarà comunque buona norma aderire agli standard di accessibilità in quanto significa conformare il sito a quanto indicato dal WAI [g], ed in generale dal W3C [g]. Inoltre vi è un secondo aspetto da tenere in considerazione, i cui vantaggi sono decisamente più percepibili anche da utenti i cui interessi non rientrano in quelli elencati precedentemente. Un sito accessibile è anche un sito sviluppato e mantenuto pensando alla qualità del software, pertanto sarà un sito ad alta manutenibilità, usabilità ed efficienza. Un buon livello di accessibilità garantisce una buona qualità generale del software, interna

26 12 CAPITOLO 2. ANALISI DEI REQUISITI (verificabilità, manutenibilità, riparabilità, evolvibilità, riusabilità, portabilità) ed esterna (correttezza, affidabilità, robustezza, efficienza, usabilità, ecocompatibilità, scalabilità). In generale, aderire ad un certo livello di accessibilità complessiva porta a molti vantaggi e, al giorno d oggi, è fondamentale per chi sviluppa siti e applicazioni Web. Tuttavia, per quanto interessante, un approfondimento non sarebbe appropriato nella presente trattazione. Vedremo ora i requisiti di accessibilità: (1) Accessibilità definita dalle linee guida priorità 1 (A) del WAI [ org/wai/]. Tale requisito soddisfa inoltre i requisiti della Legge Stanca (Legge 9 gennaio 2004, n. 4, in materia di Disposizioni per favorire l accesso dei soggetti disabili agli strumenti informatici [ _n4.htm]) 1, nonostante il sito non rientri nelle categorie indicate dalla legge stessa[1, 2]. (2) Il sito deve indicare con modalità chiare le informazioni legali essenziali ed obbligatorie (definite nell Articolo 2250 del Codice Civile, successivamente modificato ed ampliato dalla Legge 7 luglio 2009, n. 88, in materia di Delega al Governo per l attuazione di direttive comunitarie ) come previsto dalla Legge Italiana ed Europea[1, 2] Requisiti Navigazionali Definiscono le modalità di navigazione del sito. (1) Deve essere presente un Menù Principale per la navigazione dell intero sito. Questo menù deve essere disponibile in ogni pagina. Oltre al menù principale sono presenti altri menù secondari: (2) Il footer del sito deve contenere un menù ridotto per le pagine i cui contenuti esulano dal mercato del committente ma che si rendono comunque obbligatori, quali informazioni sull accessibilità, informazioni legali, termini d uso, mappa del sito ecc. Questo menù deve essere disponibile in ogni pagina. (3) Per quanto riguarda la sezione 2.4.1, ogni industry deve contenere uno specifico menù per la navigazione all interno dei prodotti della medesima famiglia. Questo menù non deve essere disponibile in ogni pagina, ma solo in quelle interessate Requisiti di Presentazione Definiscono il design e parte dell interfaccia grafica. 1 A seguito della pubblicazione delle WCAG 2.0 da parte dello stesso W3C e dell invito esteso ai 27 paesi membri da parte della Commissione europea di adottare tali raccomandazioni, si è reso necessario costituire un gruppo di lavoro presso l Osservatorio dell accessibilità Web (Formez e DDIT) che ha predisposto la revisione dell allegato A del citato decreto portando i requisiti da 22 a 12, revisione che è stata pubblicata come bozza ad aprile 2010 sul sito del Ministero[Nuovi requisiti e punti di controllo per di accessibilità]. La proposta di adeguamento è stata notificata alla Commissione europea, ai sensi della Direttiva 98/34/CE[Direttiva 98/34/CE] ed è stata emanata sotto forma di decreto dal Ministro Profumo il 20 Marzo 2013 e quindi trasmessa alla Corte dei Conti. Nella Gazzetta Ufficiale n. 90 del 17 aprile 2013 è stato pubblicato il comunicato della circolare n. 61/2013 riguardante i recenti obblighi delle pubbliche amministrazioni in materia di accessibilità e le modalità di redazione degli Obiettivi di Accessibilità (ex art. 9, comma 7, del decreto legge 179/2012). Il decreto attende tuttavia ancora la pubblicazione in Gazzetta Ufficiale, talché ne è attualmente compromessa la validità.

27 2.4. SPECIFICA DEI REQUISITI 13 (N.B. Numerazione dei requisiti assente a causa di probabili cambiamenti nell ordinamento e nella quantità) (1) Il colore dominante deve essere il Rosso Scarlatto. (2) Il logo dell azienda (Immagine 1.1) deve essere ben visibile in tutte le pagine. (3) Il menù principale deve essere a schede 2, i sottomenù (che invece avranno un layout verticale) devono apparire in seguito alla sovrapposizione del dispositivo di puntamento sulla voce principale. (4) Il menù per la versione mobile del sito può avere layout verticale. (5) In home page deve essere presente uno slider [g] dinamico per rappresentare alcune informazioni di maggiore importanza. (6) In home page devono essere presenti le ultime news/eventi inseriti. (7) La home page deve presentare una struttura a blocchi distribuiti in modo sparso. (8) Il layout generale del sito deve tendere più al flat design piuttosto che allo scheuomorfismo [g]. (9) Eventuali riferimenti geografici, o contenuti con riferimenti geografici, devono essere indicati in una mappa interattiva con risoluzione almeno mondiale Requisiti dei Servizi Definiscono i servizi e le modalità per accedervi che il sito deve offrire. (1) Deve essere presente un area amministrativa accessibile esclusivamente da un gruppo selezionato e ristretto di utenti. (2) Deve essere possibile inserire nuove news ed eventi (3) Deve essere possibile aggiornare ed inserire nuovi prodotti aziendali. (4) Deve essere possibile inserire alcune gallerie fotografiche. (5) Deve essere possibile inserire nuovi impianti di Major Realizations (6) Le tipologie di contenuti elencate fin ora devono essere aggiornabili ed inseribili grazie ad un interfaccia grafica intuitiva e rapida. 2 Con menù a schede si intende una disposizione verticale delle voci in menù. Nella maggior parte dei menù alcune voci sono la voce generale di un sottomenù: nei menù a layout verticale tale situazione viene rappresentata comunque in maniera sequenziale (verticale dall alto al basso, spesso utilizzando un rientro dal margine o un colore meno acceso per evidenziare un livello differente). Nei menù a schede, generalmente, solo il livello più alto è rappresentato orizzontalmente, mentre i vari sottomenù appaiono come menù a tendina. In generale un menù a schede è ritenuto poco accessibile in quanto non favorisce la manutenzione del layout, in quanto lo sviluppo in larghezza (dovuto all aggiunta di nuove voci o a nomi particolarmente lunghi) rende molto più difficile mantenere lo stesso layout indipendentemente dalle voci inserite.

28 14 CAPITOLO 2. ANALISI DEI REQUISITI 2.5 Tracciamento dei requisiti A seguire la tabella riepilogativa che tiene traccia di tutti i requisiti precedentemente identificati. Tabella 2.2: Tracciamento dei Requisiti Tipologia Codice Requisito Descrizione Requisiti di Contenuto R1.1 R1.2 R1.3 R1.4 R1.5 R1.6 R1.7* R1.8 R1.9 Nella sezione About Us dev essere raccontata l azienda in tutti i suoi aspetti La sezione Our History deve raccontare la storia aziendale a partire dal 1908 La sezione Mission deve descrivere in breve i princìpi aziendali e la missione di Bedeschi La sezione Key People deve descrivere le figure chiave nella direzione attuale dell azienda La sezione Commitment to Quality ISO deve descrivere l impegno dell azienda nel garantire i massimi standard qualitativi La sezione Global Presence deve mostrare la presenza territoriale di Bedeschi nel mondo La sezione Job Opportunities deve presentare le eventuali opportunità di lavoro La sezione Contact Us deve fornire i vari contatti dell azienda, sia della sede centrale che di quelle distaccate, comprensivi di , telefono e posizione geografica. Devono essere disponibili delle news relative a ultimi lavori effettuati, partecipazioni a fiere ecc.

29 2.5. TRACCIAMENTO DEI REQUISITI 15 Requisiti Strutturali R1.10 R1.11* R1.12 R1.13 R1.14 R1.15 R1.16 R2.1 R2.2 R2.3 La sezione Our Customer deve parlare dei clienti dell azienda e del loro mercato La sezione Reference List deve contenere una lista dei clienti più importanti, possibilmente organizzata geograficamente. La sezione Products and Markets deve contenere una semplice tabella (già presente nelle brochure pubblicitarie del committente) che descrive nel dettaglio i mercati e i prodotti dell azienda. Deve essere disponibile almeno una galleria fotografica. Nella sezione Products deve essere possibile visionare nel dettaglio prodotti o famiglie di prodotti, suddivisi secondo i settori Heavy Clay, Mining, Bulk Handling e Marine La sezione Major Realizations deve contenere i lavori più importanti, i quali devono essere pubblicizzati in quanto motivo d orgoglio per l azienda. Deve essere presente una sezione contenente l elenco dei link più interessanti (richiesta esplicita da parte del committente di poter scegliere quali link inserire) Il sito deve essere in inglese, con predisposizione all aggiunta di nuove lingue. La sezione Our History deve essere strutturata in linea temporale, ovvero deve essere navigabile muovendosi fra diversi periodi storici. I prodotti devono essere presentati tutti con poche informazioni fondamentali ma d effetto, con la possibilità di visualizzare/scaricare la scheda dettagliata.

30 16 CAPITOLO 2. ANALISI DEI REQUISITI Requisiti Comportamentali Requisiti di Accessibilità Requisiti Navigazionali R3.1 R3.2 R3.3* R4.1 R4.2 R5.1 R5.2 R5.3 Il sito deve essere navigabile da diversi device, rispettando il principio di portabilità (Responsive Web Design). Il sito deve presentare un area amministrativa accessibile solo da determinati utenti (muniti di credenziali d accesso). Per device differenti si deve avere un esperienza di navigazione leggermente differenziata per usufruire delle caratteristiche del device. Accessibilità definita dalle linee guida priorità 1 (A) del WAI. Il sito deve indicare con modalità chiare le informazioni legali essenziali ed obbligatorie come previsto dalla Legge Italiana ed Europea. Deve essere presente un Menù Principale per la navigazione dell intero sito. Questo menù deve essere disponibile in ogni pagina. Il footer del sito deve contenere un menù ridotto per le pagine i cui contenuti esulano dal mercato del committente ma che si rendono comunque obbligatori, quali informazioni sull accessibilità, informazioni legali, termini d uso, mappa del sito ecc. Questo menù deve essere disponibile in ogni pagina. Per quanto riguarda la Sezione 2.4.1, ogni industry deve contenere uno specifico menù per la navigazione all interno dei prodotti della medesima famiglia. Questo menù non deve essere disponibile in ogni pagina, ma solo in quelle interessate.

31 2.5. TRACCIAMENTO DEI REQUISITI 17 R6.1 Il colore dominante deve essere il Rosso Scarlatto. Requisiti di Presentazione R6.2 R6.3 R6.4 R6.5 R6.6 R6.7 R6.8 R6.9 R6.10 Il logo dell azienda (Immagine 1.1) deve essere ben visibile in tutte le pagine. Il menù principale deve essere a schede, i sottomenù (che invece avranno un layout verticale) devono apparire in seguito alla sovrapposizione del dispositivo di puntamento sulla voce principale. Il menù per la versione mobile del sito può avere layout verticale. In home page deve essere presente uno slider dinamico per rappresentare alcune informazioni di maggiore importanza. In home page devono essere presenti le ultime news/eventi inseriti. La home page deve presentare una struttura a blocchi distribuiti in modo sparso. Il layout generale del sito deve tendere più al flat design piuttosto che allo scheuomorfismo. Eventuali riferimenti geografici, o contenuti con riferimenti geografici, devono essere indicati in una mappa interattiva con risoluzione almeno mondiale. I link d interesse devono essere presentati con un interfaccia dinamica, ovvero i link devo essere presentati di volta in volta in ordine casuale e con dimensioni casuali.

32 18 CAPITOLO 2. ANALISI DEI REQUISITI Requisiti dei Servizi R7.1 R7.2 R7.3 R7.4 R7.5 R7.6 Deve essere presente un area amministrativa accessibile esclusivamente da un gruppo selezionato e ristretto di utenti. Deve essere possibile inserire nuove news ed eventi Deve essere possibile aggiornare ed inserire nuovi prodotti aziendali. Deve essere possibile inserire alcune gallerie fotografiche. Deve essere possibile inserire nuovi impianti di Major Realizations Le tipologie di contenuti elencate finora devono essere aggiornabili ed inseribili grazie ad un interfaccia grafica intuitiva e rapida.

33 Capitolo 3 Analisi delle Tecnologie Dopo aver definito cosa sviluppare e come, è necessario capire quali strumenti utilizzare. In ambito web dovremo capire quali tecnologie di base utilizzare (linguaggi di markup e fogli di stile), gli strumenti di lavoro (IDE, compilatori, server locali...) ed eventualmente tutti i supporti che potrebbero essere utili allo sviluppo, come ad esempio l utilizzo o meno di framework, librerie, CMS ecc. Andremo ora ad analizzare più nel dettaglio queste differenti categorie di tecnologie, le quali, come vedremo in seguito, sono dovute alla scelta del CMS, ma che risultano comunque estremamente valide per altri fattori. 3.1 Tecnologie WEB L analisi delle tecnologie WEB è stata quella che ha richiesto meno tempo in assoluto, in quanto la scelta è relativamente limitata ed è stata delegata in toto al laureando Linguaggio di markup Il linguaggio di markup che si è deciso di utilizzare è HTML5. La scelta rispetto ad altre versioni di HTML (in realtà il dubbio era relativo esclusivamente ad XHTML in quanto più recente degli altri) è dovuta principalmente ad una prospettiva futura dello sviluppo di tale standard; oltre ad essere di grande interesse per il laureando sia dal punto di vista accademico che curriculare riflette anche la filosofia del committente di aderire ai nuovi standard Linguaggio di formattazione I linguaggi di formattazione che si è deciso di scegliere sono CSS2.1 e CSS3. Questa duplicità è dovuta al fatto che la versione 3.0 di CSS non è ancora diventata standard, perciò il supporto ad essi potrebbe non essere totale, soprattutto su apparecchiature obsolete. Di conseguenza si è deciso di sviluppare su una base (fondamentale) in CSS2.1 arricchita da elementi (non fondamentali per il raggiungimento dei requisiti) CSS3. 19

34 20 CAPITOLO 3. ANALISI DELLE TECNOLOGIE Linguaggio di scripting Server-side Come linguaggio di scripting Server-side si è deciso di utilizzare PHP. Oltre ad essere il cuore del CMS adottato (che sarà analizzato in seguito), la cui scelta quindi risulta obbligatoria, offre diversi vantaggi: buona esperienza del laureando nello sviluppo di applicazioni PHP e buona conoscenza del linguaggio stesso ampio supporto del linguaggio in diversi ambiti, sia per quanto riguarda lo sviluppo (vi è una vastissima scelta di applicazioni che simulano un server in locale con supporto al PHP) che per la messa in linea del portale (la popolarità di questo linguaggio è in costante crescita, e ad oggi è utilizzato da oltre l 80% dei siti web) in generale questo linguaggio è ampiamente utilizzato e supportato anche grazie all estrema semplicità di utilizzo e flessibilità Linguaggio di scripting Client-side Per lo scripting client-side si è deciso di utilizzare Javascript in quanto è ampiamente supportato ed utilizzato, inoltre lo stesso laureando possiede una discreta esperienza nello sviluppo con questo linguaggio Database Management System (DBMS) Analogamente a quanto detto per PHP, anche per il DBMS non vi era possibilità di scelta in quanto il CMS adottato lavora con MySQL. Tuttavia, pure per il DBMS valgono le considerazioni di solidità e supporto fatte per PHP e anche in questo caso il laureando gode di una discreta esperienza nello sviluppo con questa tecnologia. 3.2 Tecnologie WEB ausiliarie Nella sezione 3.1 abbiamo discusso delle tecnologie WEB fondamentali per poter realizzare un sito dinamico che rispetti i requisiti precedentemente identificati. In questa sezione invece vedremo quali tecnologie ausiliarie saranno utilizzate per semplificare lo sviluppo del sito. Negli anni infatti hanno preso sempre più piede potenti strumenti di sviluppo che, in alcuni casi, hanno permesso anche ad utenti totalmente privi di conoscenze di programmazione di sviluppare dei buoni siti impiegando relativamente poco tempo. Oltre ai potenti CMS (Content Management System) vi sono innumerevoli framework (quali HTML5boilerplate, Foundation ecc.) che permettono di sviluppare velocemente e con semplicità anche l interfaccia grafica in quanto offrono una soluzione ai principali problemi che vengono tipicamente affrontati dagli sviluppatori meno esperti CMS (Content Management System) I Content Management System (in italiano sistema di gestione dei contenuti) sono un particolare tipo di software installabile su server web con lo scopo di fornire (come dice il nome) un sistema standard di gestione dei contenuti. Questa necessità è nata dal fatto che negli anni la figura del webmaster si è diversificata e specializzata, di conseguenza si sono venute

35 3.2. TECNOLOGIE WEB AUSILIARIE 21 a creare diverse figure professionali differenti, come web-designer e web-developer, differenziando molto fra chi sviluppa e chi pubblica, arrivando al punto che moltissimi degli utenti che pubblicano attivamente contenuti su web non sono in grado di sviluppare. La necessità di poter pubblicare contenuto senza avere conoscenze tecniche del settore ha portato molti sviluppatori a dover fornire un sistema di inserimento e gestione dei contenuti ai propri clienti. Tali sistemi rispondevano a richieste fondamentalmente standard, permettendo così la nascita dei primi CMS nella seconda metà degli anni 90. In realtà la prima azienda a fornire un vero e proprio sistema di gestione dei contenuti fu CNET, nel 1995, un network online su tecnologia ed elettronica di consumo, che rese pubblico (in parte) il proprio sistema di gestione degli articoli. Negli anni sono nati e falliti moltissimi CMS con potenzialità, caratteristiche e scopi differenti; vi sono sia CMS specializzati (per la realizzazione di blog, forum, wiki, e-commerce, gestionali) che general purpose. In ogni caso tutti presentano dei vantaggi sia per lo sviluppatore (il quale non dovrà realizzare alcun tipo di sistema personalizzato per i propri clienti) sia per chi dovrà gestire i contenuti (l interfaccia grafica elimina la necessità di conoscenze tecniche). L utilizzo dei CMS, inoltre, obbliga gli sviluppatori a separare il più possibile il contenuto dalla presentazione, concetto fondamentale dell accessibilità e della qualità del software web. Al giorno d oggi la quasi totalità degli sviluppatori web professionisti utilizza un sistema di gestione dei contenuti, sia esso a pagamento, open-source o sviluppato in proprio. Questa tendenza è dovuta agli evidenti vantaggi che essi offrono, ovvero: Forte separazione fra contenuto, struttura e presentazione. Struttura di base per lo sviluppo del sito: lo sviluppatore si dovrà preoccupare di scegliere ed adattare il CMS più consono alle esigenze proprie e del cliente, oltre che a realizzare un template grafico. Sistema di gestione dei contenuti: l utente che dovrà mantenere aggiornati i contenuti del sito avrà a disposizione un interfaccia grafica intuitiva e realizzata attorno alle proprie esigenze (ad esempio con la presenza di tipologie personalizzate di contenuti). Ampio supporto esterno: i CMS più utilizzati offrono centinaia (se non migliaia) di estensioni (o plugin) che permettono di ampliare in tutti i modi le funzionalità del CMS e del sito. Questi vantaggi sono gli stessi che hanno spinto il laureando ad utilizzare un CMS per lo sviluppo di questo progetto Struttura dei CMS Come detto precedentemente i CMS possono essere di diversa natura, dividendosi in due macro-categorie, ovvero dedicati e general purpose, nonostante molti CMS dedicati hanno una flessibilità tale (dovuta anche alla presenza di template ed estensioni) da poter essere utilizzati per molti scopi differenti. Forum: questa tipologia di portali è una di quelle che più si presta all utilizzo di un CMS. Il forum, infatti, è formato fondamentalmente da utenti, messaggi e discussioni. Queste categorie di informazione ben distinte fra di loro rendono quasi naturale il passaggio all utilizzo di un sistema che permetta agli utenti avanzati (moderatori ed amministratori) di gestire discussioni ed utenti, ma anche gli utenti stessi possono

36 22 CAPITOLO 3. ANALISI DELLE TECNOLOGIE gestire in modo semplice i propri messaggi. Alcuni esempi di CMS dedicati ai forum sono VBulletin (a pagamento), phpbb e MyBB. Blog: i blog sono dei siti (generalmente personali) in cui un gruppo ristretto di utenti pubblica frequentemente articoli di qualsiasi natura con la possibilità di inserire commenti. Anche questa tipologia di portale si presta molto all utilizzo di CMS, il più famoso dei quali è probabilmente WordPress, il quale inizialmente è nato come piattaforma di blogging per poi evolversi fino a diventare un CMS estremamente flessibile (anche grazie alla florida comunità di sviluppatori). Wiki: un sito di tipo wiki offre la possibilità ad una community molto vasta (come può essere quella di un forum) di creare e modificare delle pagine ricche di contenuti. L esempio maggiore di wiki è Wikipedia, che peraltro utilizza il CMS MediaWiki. E-commerce: i siti di e-commerce presentano generalmente tutti lo stesso tipo di problema, ovvero fornire al cliente (il commerciante) un sistema online per l inserimento, modifica e cancellazione di articoli in vendita e la possibilità da parte di terzi di acquistare online (generalmente con carta di credito, ma anche con molti altri metodi). Questi siti hanno necessità profondamente differenti da quelli visti finora, e nella maggior parte dei casi sono realizzati con CMS strettamente dedicati come Magento. Piccoli siti di e-commerce possono comunque essere realizzati con CMS general purpose. General Purpose: i CMS general purpose sono dei sistemi estremamente flessibili, ma spesso richiedono anche un livello d impegno per l apprendimento piuttosto elevato. Questa difficoltà è dovuta al fatto che è possibile personalizzare le funzionalità del CMS con l ausilio di un gran numero di plugin ed estensioni, che tuttavia devono essere gestiti efficientemente e con criterio per mantenere un buon livello prestazionale. Esempi di questa tipologia sono Drupal e Joomla. Ciò che accomuna tutti i CMS è di fornire un interfaccia back-end per la gestione dei contenuti, un interfaccia front-end per la loro visualizzazione ed un database per la memorizzazione. Moltissimi CMS sono sviluppati in PHP e MySQL (WordPress, PHP-Nuke), e alcuni permettono anche di scegliere se utilizzare database MySQL, PostgreSQL, SQLite ecc. Tuttavia non sono rari CMS sviluppati con altri linguaggi server-side quali Perl (WebGUI), Python (Django), Java (Magnolia), ASP.NET (DotNetNuke) e altri meno comuni 1. Dopo aver deciso di utilizzare un CMS per la realizzazione del progetto vedremo quali sono stati presi in considerazione prima di scegliere WordPress. 1 Per maggiori dettagli:

37 3.2. TECNOLOGIE WEB AUSILIARIE Drupal Figura 3.1: Logo Drupal Il primo CMS preso in considerazione è Drupal. Nato come bulletin board system, divenne un progetto libero (con licenza GPL) a partire dal La comunità di sviluppo conta più di sviluppatori, rendendolo uno dei CMS con più utenti attivi. Il principale punto di forza di questo CMS è la sua estrema flessibilità; Drupal è strutturato in moduli, divisi in due categorie, quelli che compongono il core e quelli aggiuntivi realizzati dagli sviluppatori della comunità, oltre a fornire la possibilità di realizzare i propri moduli o modificarne di esistenti. Questa tipologia di struttura fa in modo che il core sia estremamente basilare, fornendo le funzionalità minime, ma estremamente ampliabile; la comunità stessa di Drupal fornisce più di 600 distribuzioni dedicate[3], come Commerce Kickstart per la realizzazione di siti di e-commerce o OpenFolio per portfolio grafici e fotografici. I moduli interagiscono con il core grazie ad un sistema di hook, o callback, che permette agli stessi di inserire particolari funzioni nel processo di esecuzione di Drupal. La grande quantità di moduli disponibili (oltre ) e la struttura che permette una fortissima personalizzazione lo rendono uno dei CMS più potenti ed adattabili, ma proprio per questa sua caratteristica e per il sistema di hook non semplicissimo da padroneggiare ha una curva di apprendimento piuttosto ripida che lo rende poco adatto ad essere utilizzato in un progetto di questo tipo, a meno di non conoscerne già le basi. In realtà le funzionalità base del core sarebbero sufficienti per riuscire a sviluppare efficientemente il sito, ma personalmente ho incontrato diverse difficoltà a realizzare un template grafico, il quale, a differenza di altri CMS, viene utilizzato anche per la parte back-end, aumentando considerevolmente la complessità del template stesso (l interfaccia front-end ha obiettivi e caratteristiche completamente diversi da un interfaccia back-end). Conclusioni Nonostante alla fine abbia deciso di scartarlo a causa dell elevata difficoltà di apprendimento, ritengo che Drupal sia il più promettente dei CMS presi in considerazione. La sua estrema flessibilità fa in modo che il tempo di apprendimento necessario per

38 24 CAPITOLO 3. ANALISI DELLE TECNOLOGIE padroneggiarlo a dovere venga ammortizzato nel tempo, rendendolo quindi indicato ai professionisti o comunque ad utenti che prevedono di utilizzarlo a lungo termine. Inoltre il continuo sviluppo della comunità è buona garanzia proprio per un utilizzo a lungo termine Joomla! Figura 3.2: Logo Joomla Joomla! è nato nel 2005 come fork [g] del CMS Mambo, la cui ultima release risale al 2008, e sviluppato dall associazione no profit Open Source Matters. Come tutti i CMS analizzati, anche Joomla! è un software open source distribuito sotto licenza GPL v.2 e sviluppato interamente in PHP. La forte impronta open source del team di sviluppo ha portato alla sponsorizzazione da parte del team stesso di altri componenti open source sviluppati esternamente, come ad esempio Joomlaboard (per la gestione di forum), Joom!Fish (per le funzionalità multilingua) e Community Builder (per creare community e gestirne i numerosi utenti). A differenza di molti CMS, Joomla! divide le proprie estensioni in tre differenti categorie: Moduli: sono estensioni che permettono di aggiungere semplici funzionalità al sito. Generalmente si limitano ad aggiungere piccole porzioni di codice necessario a mostrare elementi di informazione o funzionalità. Un esempio potrebbe essere un modulo per l inserimento di un calendario all interno del sito. Componenti: si tratta di estensioni specifiche che permettono di aggiungere funzionalità particolarmente complesse. Un esempio è Joomlaboard, il quale permette di creare e gestire dei forum, o JoomPhoto Mobile per la gestione completa di gallerie. I componenti si differenziano dai moduli proprio per la loro complessità: i moduli infatti si limitano ad aggiungere semplici funzionalità, i componenti invece spesso estendono il CMS stesso fornendo anche delle funzionalità agli amministratori. Plugin: come i moduli sono estensioni relativamente poco complesse, ma invece di aggiungere funzionalità visibili dall utente finale solitamente si limitano a fornire dei particolari servizi che restano in background. Diversamente da altri CMS (come WordPress) l installazione delle estensioni avviene in modo automatico, ovvero tramite interfaccia grafica amministrativa. Oltre alle categorie di estensioni appena viste, Joomla!, come quasi tutti i CMS, permette l installazione e l utilizzo di template, dei quali esiste un fiorente mercato, sia libero che a pagamento. L interfaccia amministrativa, a differenza di Drupal, è standard (si può vedere in Figura 3.3), favorendo così l utente (amministratore) meno esperto, per il quale lavorare su un interfaccia standard rende più semplice confrontarsi con altri utenti dello stesso tipo. Tuttavia l interfaccia grafica (amministrativa) è stata rivoluzionata più volte fra le differenti versioni, mettendo in sordina il vantaggio di un interfaccia standard.

39 3.2. TECNOLOGIE WEB AUSILIARIE 25 Figura 3.3: Screenshot della schermata di back-end in Joomla Questo tipo di frammentazione fra le versioni si può verificare anche nella compatibilità delle estensioni: queste, infatti, difficilmente vengono realizzate e testate cross-version, rendendo particolarmente insidiosa la migrazione da una versione all altra[4]. Inoltre ritengo che la scelta del metodo di versionamento sia piuttosto bizzarra poiché è molto incentrata sullo sviluppo delle versioni di tipo LTS [g] lasciando poco tempo di rodaggio alle versioni di transizione[4], per le quali il numero di estensioni disponibili diminuisce drasticamente; considerando la scarsa compatibilità cross-version delle estensioni questo non è un problema da poco. Fra il 2005 ed il 2011 questo software ha ricevuto numerosi premi, oltre ad una crescita esponenziale della community, delle estensioni e del gradimento pubblico. Tuttavia negli ultimi mesi Joomla! ha sofferto un drastico calo di attenzione da parte della comunità tecnica e di sviluppo, nonostante resti ampiamente utilizzato. La comunità, nonostante sia molto grande, presenta una bassa percentuale di utenti esperti, abbassandone così la qualità generale. Conclusioni Joomla! gode di molti vantaggi come una community molto vasta, un gran numero di estensioni, una grande diffusione generale e una discreta semplicità di utilizzo (probabilmente è il CMS più utilizzato da utenti non esperti), tuttavia soffre di problemi non banali che ne minano il futuro, in particolar modo la scarsa attenzione da parte della comunità di sviluppatori e utenti esperti e l evidente frammentazione nella produzione di versioni compatibili fra loro. Per questi motivi mi è sembrato il CMS meno adatto fra quelli analizzati per realizzare un progetto a lungo termine.

40 26 CAPITOLO 3. ANALISI DELLE TECNOLOGIE WordPress Figura 3.4: Logo WordPress WordPress nasce nel 2003 come fork di b2/cafelog per mano di Matt Mullenweg, il quale sarà poi classificato nel 2007 come la sedicesima persona più importante del web secondo la rivista PC World[5] proprio grazie a questo software. Inizialmente WordPress nasce come piattaforma software per il personal publishing, dando inoltre la possibilità di creare il proprio sottodominio personale in wordpress.com, il che non lo differenziava molto da altre piattaforme di blogging quali MySpace e Tumblr se non per la forte personalizzazione del design. Con il tempo ed il susseguirsi di release sempre più innovative (e soprattutto retrocompatibili) WordPress è diventato un vero e proprio CMS, compiendo l ultimo passo con la versione 3.0 che introdusse i Custom Post Types. Come i CMS già analizzati WordPress è sviluppato totalmente in PHP, basandosi sul DBMS MySQL (tuttavia, a differenza di Drupal e Joomla! non supporta altri tipi di database), è distribuito con licenza GPL ed è uno dei CMS più utilizzati in assoluto. Fornisce un interfaccia back-end standard (Figura 3.5), rimasta quasi invariata sin dalla sua prima versione, allo stesso tempo completa ma semplice e intuitiva. Nonostante di per sé sia un CMS orientato al blogging ed al personal publishing, grazie ai numerosissimi plugin ed alla forte personalizzazione che ammette è di fatto un CMS General Purpose (come già detto, in particolar modo dall introduzione dei Custom Post Type).

41 3.2. TECNOLOGIE WEB AUSILIARIE 27 Figura 3.5: Screenshot della schermata di back-end in WordPress 2.8 La comunità che ruota attorno a WordPress è veramente molto grande, sia per numero di siti che lo hanno adottato, sia come numero di utenti attivi nei forum tecnici. Inoltre, come Joomla!, possiede un ricco mercato di template (sia gratuiti che a pagamento). È interessante notare che il team di sviluppo di WordPress è sempre stato molto attento a realizzare un prodotto che rispetti gli standard web e l accessibilità; infatti, annualmente vengono pubblicati nuovi temi di default che fungono benissimo da scheletro di base per sviluppare dei template che rispettino tali princìpi (l ultimo, twenty-twelve, rispetta anche il principio di portabilità con una struttura adattiva progettata molto bene per tutti i tipi di dispositivi). Conclusioni Nonostante non sia ancora maturo rispetto alle proprie possibilità, Word- Press riesce a riunire i vantaggi dei due CMS visti precedentemente, coniugando una gran quantità di componenti aggiuntivi ad una comunità vasta, attiva e tecnicamente preparata che ne garantisce un buon sviluppo. Fornisce un interfaccia amministrativa di qualità ed intuitiva, permettendo anche agli utenti meno esperti di gestire efficientemente i contenuti. Infine, i fattori che più hanno inciso sulla scelta finale sono la discreta conoscenza di questo sistema da parte sia del laureando che dai dipendenti aziendali che dovranno gestire i contenuti del sito in futuro.

42 28 CAPITOLO 3. ANALISI DELLE TECNOLOGIE Framework Con la crescita esponenziale del web e dei dispositivi in grado di accedervi è aumentata molto anche la complessità del lavoro dei web-designer e web-developer. Si pensi alla progettazione web che si faceva una quindicina di anni fa; layout tabellari (o, peggio, in frame) per gestire pagine dalle dimensioni fisse, accesso esclusivo da PC Desktop con monitor di dimensioni standard e browser dalla limitata capacità. Oggi invece dobbiamo considerare la moltitudine di dispositivi di accesso, con risoluzioni dei monitor che variano anche del 400%, connessioni a velocità estremamente differenti, utenti con necessità diverse fra loro, e questa eterogeneità aumenta sempre più di giorno in giorno. Basti pensare che già oggi quasi il 15% degli accessi ad internet avviene tramite dispositivi mobile[6] (smartphone o tablet), con una crescita esponenziale, e molti utenti accedono ad internet quasi esclusivamente da dispositivi mobile. Per gli sviluppatori è dunque diventato fondamentale comprendere appieno l importanza di una progettazione mobile-oriented, o quantomeno mobile-friendly, parallelamente all introduzione di nuove tecniche di programmazione mirate a facilitare lo sviluppo di sistemi web. Il veloce cambiamento di metodologie di accesso ha portato gli sviluppatori a realizzare soluzioni temporanee come la duplicazione del sito (versione mobile e desktop), le quali, nel caso di sviluppatori più pigri, si sono anche consolidate nel tempo, introducendo ulteriori problematiche e venendo meno ad alcuni princìpi di accessibilità. Finalmente, con l introduzione delle Media Queries in CSS3 (diventate W3C recommended stadard nel giugno 2012), si è arrivati ad una soluzione accettabile che permette di realizzare layout relativamente semplici e che rispettino i princìpi per una buona progettazione. Chiaramente l introduzione di nuove tecnologie porta sempre ad un incremento della complessità generale nella progettazione; queste soluzioni, quindi, risultano vantaggiose a patto di riuscire a gestirle efficientemente. A questo scopo sono nati i primi framework adattivi, ovvero delle strutture (HTML e CSS) basilari che offrono la possibilità di realizzare in modo semplice e veloce dei layout standard e portabili, ovvero in grado di adattarsi automaticamente al supporto di visualizzazione (o meglio, alle sue dimensioni e caratteristiche). In realtà la maggior parte dei framework realmente utilizzati non si limitano ad essere un semplice strumento per lo sviluppo di layout con struttura flessibile, ma incorporano diverse tecnologie che facilitano e migliorano lo sviluppo generale del front-end. Generalmente le feature aggiuntive consistono in librerie ampiamente utilizzate che aiutano molto lo sviluppatore, come ad esempio JQuery, Modernizr 2 e less 3. Oltre ad eventuali librerie aggiuntive, quasi tutti i framework forniscono uno stile semplice (e generalmente gradevole) per elementi basilari dei siti web, come campi di form, bottoni, breadcrumb [g], icone 4, tabelle e molto altro. 2 Con l introduzione di nuove tecnologie (candidate a diventare standard) i browser web incontrano parecchie difficoltà ad uniformarsi fra loro. Modernizr è una libreria Javascript che fornisce degli ottimi strumenti per automatizzare la differenziazione di parti critiche di codice fra un browser e l altro 3 less è una libreria Javascript che effettua una sorta di preelaborazione del codice CSS permettendo allo sviluppatore di utilizzare delle caratteristiche normalmente non disponibili (come l introduzione delle variabili in CSS) che velocizzano e semplificano lo sviluppo e la verifica del codice. Per dettagli si veda la Sezione Ad oggi nel web vengono utilizzate una gran quantità di icone in formato vettoriale grazie agli icon-font, ovvero dei particolari tipi di font i cui caratteri non rappresentano i normali caratteri alfanumerici, ma delle icone. Tali set di icone vengono spesso utilizzati in framework o in librerie dedicate allo sviluppo di GUI. Il principale vantaggio di questi elementi è la qualità grafica (sono immagini vettoriali, quindi non perdono qualità cambiandone dimensione) e, soprattutto, la ridotta dimensione fisica dei file che le contengono.

43

44

45 3.2. TECNOLOGIE WEB AUSILIARIE Conclusioni sull utilizzo di front-end framework L analisi dei precedenti framework ha evidenziato come non ci siano molte differenze fra i diversi sistemi. Tutti infatti offrono non solo un sistema di griglie per realizzare layout flessibili, ma anche una serie di strumenti ed elementi grafici che semplificano molto il lavoro degli sviluppatori, annullando la necessità di modificare elementi grafici standard a favore dell utilizzo di quelli forniti dal framework stesso. Le differenze che si possono avere tra un framework ed un altro sono relative a pochi dettagli, come la presenza o meno di particolari feature (come palette dei colori o iconfont), che non sono sufficienti a favorire in modo netto l utilizzo di un software rispetto ad un altro. Un altra differenza può consistere nella presenza o meno di librerie di supporto quali preprocessori CSS e librerie Javascript (JQuery, MooTools, Modernizr). Tuttavia non esistono dei vantaggi netti, perciò le preferenze personali, l esperienza e soprattutto il feeling con un framework sono decisamente più incisivi rispetto alle varie feature per la scelta di uno strumento rispetto ad un altro. Personalmente ho provato due di questi framework, Foundation ed HTML5 Boilerplate (una particolare versione di Bootstrap), senza trovare particolari utilità derivanti dall uso di questa tipologia di strumenti. Questo perché per siti stilisticamente poco complessi è meno redditizio impiegare una discreta quantità di tempo a familiarizzare con lo strumento piuttosto che realizzare solo ciò che è necessario. Layout flessibili di massimo due colonne non sono impegnativi da realizzare, è sufficiente applicare poche regole CSS per ottenere un buon risultato, mentre le icone (oltre che di scarsa utilità) sono facilmente importabili in maniera autonoma, così come le diverse librerie Javascript. Per questi motivi ho deciso di non utilizzare framework front-end; potrebbero essere una buona soluzione per i professionisti del web-design e di design di interfacce grafiche, ma l impegno necessario per imparare ad utilizzare questi strumenti non giustifica i vantaggi effettivi in questo progetto Librerie Oltre agli strumenti visti fin ora esiste un ingente quantità di librerie per semplificare il lavoro degli sviluppatori. Generalmente in ambito web le librerie più utilizzate sono sviluppate in Javascript. Di seguito vedremo una breve analisi di quali librerie siano state prese in considerazione e quali siano state adottate per lo sviluppo del progetto JQuery Figura 3.9: Logo JQuery JQuery è la libreria Javascript di maggior successo in assoluto. È una libreria General Purpose, in quanto non si occupa di fornire strumenti dedicati (a differenza, ad esempio, di JQuery Mobile) ma semplicemente fornisce una sintassi semplificata e più efficiente per tutte le operazioni effettuabili tramite Javascript.

46

47 3.3. STRUMENTI DI SVILUPPO JQuery Mobile Questa libreria offre una notevole estensione di JQuery (il quale è richiesto per il suo funzionamento) offrendo molte funzionalità aggiuntive per dispositivi mobile. In realtà JQuery Mobile nasce dalla necessità di utilizzare JQuery per lo sviluppo di applicazioni mobile trasformate in applicazioni native specifiche tramite framework quali PhoneGap 7, perciò possiede moltissimi strumenti dedicati allo sviluppo di interfacce grafiche. Per gli sviluppatori web il maggior vantaggio di questa libreria consiste nel fornire nuovi eventi tipici dei display touchscreen. Conclusioni Questa libreria è stata utilizzata per via degli eventi touchscreen che fornisce. 3.3 Strumenti di sviluppo Per lo sviluppo del progetto sono stati utilizzati diversi software. Di seguito verranno brevemente analizzati e descritti, motivandone la scelta o l esclusione IDE (Integrated Development Environment) Per sviluppare software web con le tecnologie sopraindicate non è necessario dotarsi di compilatori. Il codice infatti viene totalmente interpretato, quindi è sufficiente realizzare il codice sorgente ed inserirlo nel server web di destinazione. Per questo motivo potrebbe essere sufficiente sviluppare utilizzando unicamente un semplice editor di testo. Tuttavia, per qualunque tipo di progetto non banale, è buona norma utilizzare strumenti che aiutino lo sviluppatore nella produzione ed organizzazione di codice. A questo scopo sono dedicati gli IDE (Integrated Development Environment), ovvero dei software che integrano, oltre all editor di testo, diversi strumenti per lo sviluppo, quali compilatore/interprete e debugger. L IDE utilizzato per lo sviluppo del progetto è il software Adobe Dreamweaver. I motivi che hanno portato il laureando a scegliere questo strumento sono diversi; innanzitutto l esperienza maturata nel tempo, ma soprattutto le caratteristiche dell IDE stesso. Dreamweaver infatti offre diversi strumenti utili agli sviluppatori, come ad esempio il controllo integrato delle diverse specifiche degli standard web in cui si sta sviluppando: è possibile scegliere se effettuare una validazione del codice in diversi standard, in particolar modo XHTML 1.0 Strict e HTML5, oltre a CSS2.1 e CSS3, e (seppur in modo più grezzo) permette anche la validazione WCAG (A, AA e AAA). È inoltre possibile impostare alcune preferenze rispetto ai browser e valutarne la compatibilità con il codice. Altre caratteristiche salienti di Dreamweaver consistono nel poterlo collegare direttamente ad un repository [g] e nel disporre anche di un client FTP per il trasferimento di dati in remoto. Per il resto Dreamweaver non si differenzia molto da altri software di sviluppo web; la funzione di autocompletamento è disponibile per moltissimi linguaggi, dal PHP al CSS (per il quale l ho trovata estremamente utile), ed è possibile modificarla/aggiornarla in base allo standard cui si vuole aderire. Permette anche di gestire non solo i singoli file ma anche un 7 PhoneGap è un framework cross-platform che permette di sviluppare applicazioni mobile utilizzando tecnologie web quali HTML, CSS e Javascript, realizzando in ultima fase una versione dedicata nel linguaggio nativo del device per cui si desidera sviluppare.

48 34 CAPITOLO 3. ANALISI DELLE TECNOLOGIE intero progetto, con la possibilità di creare uno spazio di lavoro con riferimenti dinamici ai file. Da evitare assolutamente lo strumento di progettazione visiva (spesso questo software è criticato credendo erroneamente che il suo punto di forza sia la possibilità di realizzare un layout tramite interfaccia grafica). Sono stati presi in considerazione anche altri software quali Aptana Studio 3, che tuttavia non hanno convinto appieno il laureando che ha comunque optato per il software Dreamweaver XAMPP XAMPP è un software Open Source multipiattaforma, sviluppato dal team Apache Friends, per la simulazione in locale di un server web. Il nome è il risultato dell acronimo delle tecnologie che mette a disposizione: la X sta per multipiattaforma, la A sta per Apache (il server web), la M per MySQL (il DBMS), la prima P per PHP e la seconda per Perl. Si distingue dai suoi diretti concorrenti (WAMP, LAMP, MAMP) per la caratteristica di essere multipiattaforma (nonostante sia necessario scaricare e installare pacchetti diversi) e perché include nativamente il supporto a Perl. Nonostante non sia indicato nell acronimo, XAMPP offre anche la possibilità di configurare un server Tomcat per l esecuzione di codice JSP (il quale, a differenza di PHP, deve essere parzialmente compilato in quanto utilizza in parte il linguaggio Java). Alcune caratteristiche che ho trovato particolarmente utili sono la possibilità di scaricare il software in modalità Portable (ovvero senza necessità di installazione, dando l opportunità di inserirlo in supporti removibili e di riuscire a sviluppare da qualunque postazione in caso di emergenza) e la presenza del software PhpMyAdmin per la gestione dei database. È possibile vedere il pannello amministrativo di XAMPP in Figura Figura 3.11: Pannello amministrativo di XAMPP. Nello screenshot in questione sono attivi i servizi Apache e MySQL.

49 3.3. STRUMENTI DI SVILUPPO 35 La caratteristica principale di XAMPP e delle sue alternative è che questi software permettono di installare un server web in locale, in modo da velocizzare le operazioni di test. Infatti può risultare frustrante dover attender l upload via FTP di tutti i file modificati prima di poter procedere con i test. Inoltre, in caso di assenza di connessione ad internet risulterebbe impossibile verificare il funzionamento del codice lato server, oltre al fatto che non è sempre facile ottenere uno spazio web gratuito privo di pubblicità e limitazioni che non dovranno poi essere presenti nel sito finale. Personalmente ho sviluppato diversi progetti utilizzando questo software, e non ho mai riscontrato problemi particolarmente insidiosi, anzi ho notato che la curva di apprendimento di questo software non è assolutamente elevata (eccezion fatta per Tomcat e lo sviluppo in JSP, che tuttavia non è inerente al presente progetto). Un aspetto particolarmente interessante è la possibilità di poter modificare la cartella contenente i vari progetti (cartella htdocs). Per quanto banale questa feature mi ha permesso di utilizzare una cartella sincronizzata online su spazio cloud tramite terzo software (Dropbox) per ottenere un primo livello di backup.

50 36 CAPITOLO 3. ANALISI DELLE TECNOLOGIE

51 Capitolo 4 Progettazione e Processo di Sviluppo Nonostante l analisi sia la prima attività da affrontare nello sviluppo di qualunque progetto, il processo probabilmente più critico consiste nella progettazione, la quale si basa appunto sull analisi. L alta criticità di questo processo è implicita nella sua natura, in quanto lo scopo della progettazione è di definire come i requisiti precedentemente specificati debbano essere soddisfatti, trasformando quindi i requisiti (input) in direttive (output). Questa fase dunque si prefigge l obiettivo di dare delle sintetiche direttive nella realizzazione della soluzione al problema precedentemente identificato, e se svolta in modo efficiente garantisce un basso livello di complessità nella realizzazione finale della soluzione. 4.1 Architettura Software In Ingegneria del Software la fase di Progettazione prevede anche la definizione di quale architettura software utilizzare. Tuttavia in ambito web non è possibile applicare canonicamente questa attività, in quanto utilizzare architetture differenti da quelle normalmente utilizzate porterebbe ad errori progettuali ormai identificati e risolti da tempo. Il pattern architetturale [g] MVC, ad esempio, prevede l utilizzo di tre componenti principali, ognuna delle quali ha uno specifico compito: Model fornisce i metodi per accedere ai dati View visualizza i dati contenuti nel model e si occupa dell interazione con utenti e agenti Controller riceve i comandi dell utente (in genere attraverso il view) e li attua modificando lo stato degli altri due componenti Analizziamo ora se questa tipologia di architettura è applicabile in ambito web Architettura Model-View-Controller (MVC) Come detto in precedenza, l architettura MVC[11, 14] (Figura 4.1) è composta da tre livelli fondamentali: Model, View e Controller. Mentre gli elementi del Controller sono facilmente 37

52 38 CAPITOLO 4. PROGETTAZIONE E PROCESSO DI SVILUPPO identificabili (si limita a gestire delle richieste da parte dell utente, elaborarle ed indirizzarle all oggetto destinatario), le parti di View e Model tendono a confondersi e sovrapporsi. La View infatti si occupa di organizzare i dati, presi dal Model, per poi mostrarli all utente. Già questa attività presenta una leggera sovrapposizione con il compito del Model; si pensi ad una banale pagina PHP che interroga il database per mostrare il risultato della query all utente. L accesso ai dati del DB (quindi la query) viene eseguita nella medesima pagina PHP che si occupa di stampare la struttura html con cui mostrare i dati (la formattazione viene fatta a parte), attività inerente appunto alla parte View. Questa incoerenza potrebbe essere risolta limitando l accesso ai dati (interrogazione al DB) ad una pagina, la quale passa i dati ad una seconda pagina che si occupa di inserirli all interno di una struttura HTML. Tuttavia anche questa soluzione non sembra perfetta, in quando tenderebbe ad aumentare sensibilmente il numero di pagine, le quali dovrebbero come minimo risiedere su due differenti directory, creando a questo punto una discreta confusione nel codice. Figura 4.1: Rappresentazione UML del pattern MVC Anche l atomicità del Controller non è così evidente. Si pensi ad una pagina contenente un form [g] : tale pagina allo stesso tempo si occupa di fornire il form per l inserimento dei dati (compito che dovrebbe essere riservato alla View) e reindirizzare l utente ad una nuova pagina, mettendo i dati inseriti in allegato alla richiesta (compito demandato al Controller). Questo tipo di architettura, dunque, si presta poco all utilizzo con il linguaggio PHP. La situazione migliora nel caso si utilizzi la tecnologia JSP, la quale per sua natura è più orientata all utilizzo di pattern architetturali; nel caso di MVC, i compiti del Model vengono assolti dai JavaBeans, quelli del View dalle pagine.jsp e quelli del Controller dalle Servlet. In generale credo che l utilizzo del modello MVC si presti in maniera troppo forzata alla progettazione web. Se analizziamo la struttura generale di un sito web[10] identifichiamo tre elementi fondamentali e fortemente disgiunti: Presentazione Struttura Comportamento

53 4.1. ARCHITETTURA SOFTWARE 39 Figura 4.2: Modello web per la separazione di Struttura, presentazione e comportamento. Se pensiamo di portare questi tre elementi su livelli separati notiamo come i dati, a partire dalla richiesta fino ad arrivare alla presentazione, passano attraverso tutti e tre i livelli. In questo caso quindi è più saggio fare riferimento ad un architettura multi-tier. La più utilizzata è decisamente l architettura 3-tier, ma ritengo che l inserimento di un ulteriore livello aiuti a mantenere una maggiore separazione logica fra i componenti Architettura 3-Tier Come si evince dal nome il modello 3-Tier[15] è composto da tre livelli disgiunti, chiamati Tier, ciascuno dei quali si occupa di una specifica funzione. La caratteristica principale dei modelli a tier è che ogni livello comunica esclusivamente con i due livelli adiacenti (se presenti), superiore ed inferiore.

54 40 CAPITOLO 4. PROGETTAZIONE E PROCESSO DI SVILUPPO Presentation tier The top-most level of the application is the user interface. The main function of the interface is to translate tasks and results to something the user can understand. >GET SALES TOTAL >GET SALES TOTAL 4 TOTAL SALES Logic tier This layer coordinates the application, processes commands, makes logical decisions and evaluations, and performs calculations. It also moves and processes data between the two surrounding layers. GET LIST OF ALL SALES MADE LAST YEAR ADD ALL SALES TOGETHER Data tier Here information is stored and retrieved from a database or file system. The information is then passed back to the logic tier for processing, and then eventually back to the user. QUERY SALE 1 SALE 2 SALE 3 SALE 4 Database Storage Figura 4.3: Architettura 3-Tier[15] Primo livello Presentation Tier: questo livello (il più alto) si occupa esclusivamente della presentazione del contenuto. Secondo livello Application/Logic Tier: il livello intermedio ha lo scopo di definire ed implementare la logica con la quale ottenere i dati. Nel caso di siti dinamici, l Application Tier consiste nell insieme degli elementi che si occupano di effettuare interrogazioni al database e di elaborare i dati dai livelli adiacenti. Terzo livello Data Tier: questo livello (il più basso) si occupa della memorizzazione e dell accesso ai dati. Pensiamo nuovamente alla pagina PHP descritta in precedenza (Sezione 4.1.1). In questo caso la richiesta viene ricevuta dal Presentation Tier, il quale la demanda al livello inferiore. L Application Tier ha il compito di interpretare la richiesta e, conseguentemente, reagire. Nel caso di una richiesta http ad una pagina viene fornita la pagina stessa. Se la richiesta di tale pagina (la cui elaborazione resta nel livello intermedio) necessita di un accesso al database allora si passa al livello inferiore (Data Tier) tramite interrogazione. Il risultato della query viene nuovamente passato all Application Tier, il quale si occupa di elaborare i dati ricevuti. A questo punto i dati della query sono pronti per essere inseriti all interno di una struttura (HTML), la quale sarà poi formattata e visualizzata dal Presentation Tier.

55 4.1. ARCHITETTURA SOFTWARE 41 Con questo modello la richiesta di una pagina che richieda un accesso al database avviene in maniera molto meno confusa. L unica eccezione si ha nel momento in cui i dati elaborati nell Application Tier devo essere strutturati. La struttura di una pagina web, infatti, dovrebbe essere disgiunta sia dalla presentazione che dal comportamento. A tal proposito quindi è opportuno inserire un ulteriore livello fra il Presentation Tier e l Application Tier Architettura Multi-Tier In generale il modello Multi-Tier[15] è una specializzazione del 3-Tier, dove il Presentation Tier (primo livello) ed il Data Tier (ultimo livello) continuano ad essere presenti, mentre l Application Tier viene suddiviso in più livelli. Generalmente questo pattern architetturale viene utilizzato quando si rende necessaria una rigida separazione fra i livelli, rendendo possibile la comunicazione ad un livello solo con i due a lui adiacenti. In questo caso ho deciso di applicare un architettura personalizzata alle esigenze precedentemente descritte, in quanto non ho trovato altri pattern che permettessero il medesimo livello di separazione. L architettura creata è composta da quattro livelli, e può quindi essere chiamata 4-Tier. Tre di questi livelli fanno riferimento alle attività descritte in Figura 4.2. Primo livello Presentation Tier: resta invariato, e si occupa delle attività inerenti alla Presentazione Secondo livello Structure Tier: si occupa delle attività inerenti alla Struttura, quindi inserisce i dati elaborati dal livello più basso per strutturarli in modo che possano essere formattati nel livello più alto. Terzo livello Behaviour Tier: si occupa delle attività inerenti al Comportamento, quindi preleva i dati dal livello inferiori, li elabora e li invia al livello superiore affinché possano essere strutturati. Quarto livello Data Tier: resta invariato, occupandosi semplicemente della memorizzazione e dell accesso ai dati presenti nel database. Questa architettura (che, di fatto, è un 3-Tier modificato) è facilmente distribuibile su un architettura client-server, dove il primo livello (Presentation Tier) risiede sul client (o meglio, i file necessari vengono inviati al client, il quale si occuperà di interpretarli, svolgendo quindi le funzioni del Presentation Tier), mentre i restanti livelli risiedono sul server. Figura 4.4: Architettura 4-Tier

56

57 4.2. MODELLO DI PROGETTAZIONE 43 Figura 4.6: Modello di Progettazione adottato Descrizione del modello di progettazione adottato Analisi dei requisiti La prima fase di questo modello prevede che innanzitutto venga fatta una corretta analisi dei requisiti. Infatti prima di poter cominciare un progetto è necessario capire e definire con precisione quali siano gli obiettivi e le necessità. È importantissimo notare che l analisi dei requisiti tiene conto anche delle categorie di utenti che dovranno accedere. Input: considerazioni e necessità del committente, con partecipazione dello sviluppatore. Output: specifica dei requisiti Dati e informazioni Nella seconda fase si passa alla progettazione della base informativa. Questo non significa solo progettare la base di dati che li supporterà (nel caso debba essere progettata, se si utilizzano CMS generalmente questa attività non va effettuata), include anche le attività di definizione dei contenuti e della loro strutturazione (ad esempio, pagine inerenti ad uno stesso argomento dovranno presumibilmente risiedere nella medesima sezione). Input: requisiti Output: funzionalità Applicazioni e servizi In questa fase vengono progettati le applicazioni ed i servizi che il sito deve fornire. Ad esempio, l utilizzo di elementi dinamici come ultime news, gallerie di immagini ecc. devono essere definiti e progettati in questa fase.

58 44 CAPITOLO 4. PROGETTAZIONE E PROCESSO DI SVILUPPO Input: requisiti Output: funzionalità Accessibilità e Usabilità Questa è probabilmente la fase meno dipendente dalle altre in quanto si occupa della progettazione di elementi che devono rispettare delle norme generali inerenti a diversi ambiti dello sviluppo web. In altre parole si tratta di applicare delle best practice per la progettazione generale dell organizzazione del sito atte a garantirne un certo livello di qualità. Input: requisiti e norme di accessibilità e usabilità Output: direttive sull organizzazione Interfaccia e stile La penultima fase prevede la progettazione dell interfaccia grafica e del design. Nonostante non sia essenziale al raggiungimento dello scopo del progetto generalmente tende ad alzare di molto il gradimento complessivo del prodotto. Questa fase è quella che generalmente è meno controllabile in termini di tempo, o meglio quella per cui è più difficile realizzare una pianificazione attendibile, in quanto spesso lo sviluppatore si trova costretto a rivedere il proprio lavoro in seguito a richieste non prevedibili (da parte del committente) e modifiche dettate dai gusti personali del cliente e dello sviluppatore stesso. Problemi di questo tipo possono essere controllati affidando le attività di progettazione di questa fase a specialisti del settore (visual designer). Input: requisiti Output: interfaccia grafica e stile Strumenti e manutenzione L ultima fase prevede la progettazione di tutti gli elementi necessari affinché il sito possa diventare effettivamente fruibile dagli utenti. Le attività comprese in questa fase possono essere attività di SEO, configurazione del server, installazione/adattamento di strumenti non strettamente inerenti al progetto stesso (come dump di dati o distribuzione su più server). Input: requisiti (anche impliciti dovuti alle disponibilità del cliente o dello sviluppatore) Output: fruibilità del sito

59 Capitolo 5 Progettazione Back-End Generalmente con back-end, in ambito web, si fa riferimento alla parte amministrativa del sito. Nel mio caso l utilizzo del CMS WordPress ha permesso di risparmiare molto lavoro (sia in fase di progettazione che in fase di sviluppo) in quanto l obiettivo dei CMS è proprio quello di fornire uno strumento per semplificare la gestione dei contenuti senza doverlo realizzare in toto. Tuttavia è stato necessario adattare la struttura del CMS ai requisiti emersi durante la fase di analisi. 5.1 Progettazione della base informativa Progettare la base informativa significa progettare non solo i contenuti nella forma in cui verranno presentati, ma anche il supporto che li memorizzerà e soprattutto la struttura per rappresentarli. L attività di realizzazione dei contenuti, in genere, richiede un alto livello di impegno da parte del committente, ed è un compito che è bene assegnare ad una figura professionale dedicata, quali information-designer e content-curator. Tuttavia per questo progetto tale attività è stata svolta in parte dal committente ed in parte dal laureando proprio per via dell assenza di una figura specializzata in questo compito. Come già detto l attività di progettazione del database è stata totalmente demandata al CMS. L attività che invece ha richiesto più impegno ed attenzione da parte del laureando consiste nella progettazione della struttura dei contenuti Progettazione della struttura dei contenuti Nativamente WordPress offre solo due tipologie di contenuti, Page e Post, oltre ai contenuti Multimedia e Comments per permettere la gestione di file multimediali (generalmente immagini, ma anche audio e video) e per i commenti (ricordiamo che WordPress nasce come CMS blog-oriented). È fondamentale comprendere appieno la differenza fra Page e Post: Post: i contenuti di tipo Post sono i classici contenuti dei blog. Infatti, in un blog, il redattore degli articoli è tenuto a pubblicare contenuti di qualsiasi natura ma con una certa frequenza, permettendo ai visitatori di lasciare dei commenti. La caratteristica 45

60 46 CAPITOLO 5. PROGETTAZIONE BACK-END principale di un Post è di essere estremamente legato alla propria data di pubblicazione. Un blog infatti dev essere uno strumento di pubblicazione il più possibile attivo, con inserimenti giornalieri di contenuti, e possibilmente con una vasta comunità di lettura che sia anche attiva con i propri commenti. Generalmente i blog offrono anche la possibilità di sfogliare l archivio dei post, ovvero l insieme di tutti i post organizzati solitamente per mese ed anno. Page: i contenuti statici che non si prestano ad essere catalogati come Post vengono invece pubblicati come Page (pagine). Un esempio potrebbe essere la pagina Biografia del blog personale di qualcuno: la biografia di una persona, infatti, non cambia spesso, quindi è opportuno immaginare di crearla come Page piuttosto che come Post. Questa differenziazione fra Post e Page ha permesso a WordPress di essere utilizzato come CMS per siti classici, ovvero siti di poche decine di pagine statiche, senza la possibilità di interventi da parte dei visitatori. Tuttavia la situazione è migliorata notevolmente dall introduzione dei Custom Post Type. I Custom Post Type permettono di definire una (o più) nuova tipologia di contenuto che diverrà un alternativa allo stesso livello di Post e Page. Nel caso di questo progetto tale funzionalità calza perfettamente con la necessità del committente di produrre contenuti specifici per ogni area di produzione (Industry). Si faccia riferimento alla Sezione per maggiori dettagli. Abbiamo quindi creato cinque ulteriori tipologie di contenuti, ovvero: Marine Products [R1.14] Mining Products [R1.14] Bulk Handling Products [R1.14] Heavy Clay Products [R1.14] Major Realization [R1.15] L ultima categoria (Major Realization) non rientra nelle precedenti, tuttavia anche questa si presta alla definizione di un Custom Post Type dedicato. In Figura 5.1 si può vedere il risultato dell aggiunta dei Custom Post Type nella schermata amministrativa.

61

62 48 CAPITOLO 5. PROGETTAZIONE BACK-END 5.2 Progettazione di applicazioni e servizi Negli ultimi anni si è molto sentito parlare di Web 2.0. Questo termine è stato coniato nel 2004 da Tim O Reilly, e indica l insieme di applicazioni che hanno aumentato il livello di interazione fra utente e sito web quali blog, forum, chat, wiki, e-commerce, social network ecc.[17]. Sebbene il termine Web 2.0 sia piuttosto controverso, è innegabile il cambiamento radicale avvenuto rispetto al web statico degli anni passati. Ciò che è profondamente cambiato (da un punto di vista non tecnico) è l approccio con cui si intende fornire un servizio all utente: non ci si limita più a fornire semplicemente dell informazione, ma si vuole offrire un vero e proprio strumento che permetta di interagire con la stessa. Al giorno d oggi, quindi, un sito web non dovrebbe semplicemente fornire un contenuto, ma anche una serie di servizi ed applicazioni che ne siano a stretto contatto. Sebbene l utilizzo di un CMS rientri in questa filosofia, restano da definire ulteriori strumenti per fornire all utente finale (e non solo all amministratore) un esperienza più completa e coinvolgente Gallerie Come da requisito [R1.13] deve essere possibile inserire (a scelta del committente) una o più gallerie di immagini all interno di una qualunque sezione del sito. Per fare questo WordPress offre una notevole quantità di plugin, che permettono una gestione facilitata delle immagini e delle gallerie. Nella fase di progettazione non è necessario identificare un plugin in particolare, tuttavia è bene esplicitare delle caratteristiche essenziali, in modo da guidare il futuro lavoro di ricerca ed implementazione. Le caratteristiche ricercate (con riferimento al back-end) sono le seguenti: Possibilità di inserire una galleria in un punto qualunque di qualunque tipo di articolo (post, pages ed eventuali Custom Post Type) grazie all interfaccia amministrativa di WordPress. Possibilità di gestire le singole gallerie, potendo aggiungere o eliminare immagini anche a distanza di tempo. Possibilità di scegliere fra più layout di presentazione Mappa dinamica Con riferimento al requisito [R6.9] è necessario implementare una mappa dinamica il cui scopo sia quello di poter inserire dei riferimenti relativi a dati geolocalizzati. Il requisito [R1.6] specifica che dev essere esplicita la presenza di Bedeschi sul territorio mondiale, quindi si rende necessario che la mappa abbia risoluzione almeno mondiale. Inoltre nella sezione Major Realizations [R1.15] potrebbe essere necessario poter inserire dei marcatori per indicare dove si trovino i lavori di maggior spessore. Per questo è necessario che la mappa sia configurabile ad aree geografiche oppure a marcatori. Altre considerazioni utili riguardano l integrabilità della mappa nell ambiente di sviluppo. Cercheremo dunque uno strumento che offra le seguenti caratteristiche: La mappa deve avere risoluzione almeno mondiale La mappa deve essere configurabile ad aree geografiche e a singoli marcatori

63 5.2. PROGETTAZIONE DI APPLICAZIONI E SERVIZI 49 La mappa dev essere implementata utilizzando strumenti leggeri, quindi sarebbe opportuno che venga costruita da uno script che utilizzi immagini vettoriali piuttosto che raster (bitmap). La mappa dev essere dinamica, ovvero deve permettere di cambiare scala, in modo analogo alle mappe di Google Maps. La mappa dev essere adattiva Breadcrumb Facendo riferimento all area amministrativa è necessario poter fornire la breadcrumb [g] per ogni pagina del sito. A questo proposito sarà quindi opportuno utilizzare uno strumento per la loro creazione e configurazione (WordPress non offre nativamente questa funzionalità). L utilizzo di breadcrumb si rende necessario (nonché opportuno) da requisito [R4.1] inerente all accessibilità Slider Come da requisito [R6.5] dev essere disponibile uno slider [g] dinamico per la presentazione dei contenuti. Per realizzare questa funzionalità dev essere possibile per l amministratore poter inserire, rimuovere o modificare una slide, senza dover mettere mano al codice. Il numero di slide, quindi, non può (né deve) essere noto a priori, pertanto sarà necessario sviluppare uno script che permetta di riconoscere dinamicamente il numero di slide. Non è necessario esplicitare altri elementi progettuali relativamente al back-end News ed Eventi I servizi relativi all inserimento di news ed eventi (quindi post) sono tutti forniti dal CMS. Per l inserimento è possibile vedere in Figura 5.1 come la prima voce del menu amministrativo riguardi proprio i post. Non è quindi necessario definire altre linee guida per la progettazione back-end di questo servizio Most Clicked Links Come richiesto nel requisito [R1.16] i link devono poter essere scelti dal committente. Per questo in home page è stata dedicata una sezione contenente dei semplici link HTML, i quali vengono poi modificati da uno script Javascript (realizzato dal laureando) che ne randomizza l ordine e le dimensioni con cui si presentano. Questo script ha l obiettivo di dare un idea di casualità dovuta alle diverse visite del sito [R6.10]. La possibilità di scegliere i link da mostrare piuttosto che ricavare i link effettivamente più visitati è dovuta al fatto che generalmente le pagine più visitate di un sito di questo genere sono quelle inerenti ai contatti e la home page. Il committente invece desidera pubblicizzare le pagine più interessanti dal punto di vista dell offerta proposta e delle caratteristiche che rendono l azienda uno dei leader nel settore. La gestione dei link è possibile modificando il contenuto della pagina di Home Page tramite l editor di testo incluso in WordPress.

64 50 CAPITOLO 5. PROGETTAZIONE BACK-END Our History Questa sezione, come specificato nel requisito [R2.2], deve essere presentata con una linea temporale. Per enfatizzare il senso di temporalità si è deciso di implementare un interfaccia di tipo Parallax (parallasse [g] ). Per via della complessità di quest effetto questa sezione è stata gestita completamente dal laureando, esternamente al CMS, e non è stato previsto alcun metodo per la sua modifica che non necessiti di modificare direttamente il codice.

65 Capitolo 6 Progettazione Front-end Nell ambito della programmazione web, con front-end si fa riferimento alla parte del sito visibile a tutti gli utenti che desiderano visitarlo; il front-end include sia l interfaccia con cui vengono presentati i contenuti, sia l insieme dei contenuti (destinati all utente in questione), sia i servizi che vengono offerti. 6.1 Progettazione di applicazioni e servizi Nella Sezione 5.2 sono stati progettati e descritti alcuni servizi individuati durante la fase di Analisi. Tuttavia la progettazione fatta nel capitolo precedente era inerente esclusivamente agli aspetti relativi il back-end, ovvero la parte amministrativa, rendendo necessario precisare ulteriori aspetti relativi alla progettazione front-end. A seguire la progettazione (inerente al front-end) delle applicazioni e dei servizi sviluppati Gallerie Dopo aver identificato le caratteristiche fondamentali inerenti il back-end è necessario definire le caratteristiche relative al front-end. Dall analisi fatta precedentemente non sono emersi particolari requisiti di presentazione, quindi ho deciso di procedere di mia iniziativa previa conferma da parte del committente. Le caratteristiche ricercate (con riferimento al front-end) sono le seguenti: La galleria dev essere navigabile sia in formato thumbnail (ovvero dev essere disponibile un anteprima delle immagini dalla quale sia poi possibile scegliere l immagine interessata per visualizzarla nel dettaglio) che in formato intero o a schermo intero. La visualizzazione a formato intero deve consentire comunque la navigazione fra un immagine e l altra. La visualizzazione a formato intero deve essere predisposta all inserimento di una didascalia. 51

66 52 CAPITOLO 6. PROGETTAZIONE FRONT-END Mappa dinamica Con riferimento alla Sezione è necessario indicare ulteriori caratteristiche inerenti al front-end della mappa. Non sono stati identificati particolari requisiti di presentazione per quanto riguarda la mappa, perciò la definizione di queste caratteristiche è stata lasciata in massima parte al laureando, sotto approvazione del committente. Le caratteristiche ricercate comprendono: La mappa deve essere rappresentata tramite immagini vettoriali e non bitmap, in modo che possa mantenere la stessa qualità di immagine a qualsiasi risoluzione. Nel caso di una configurazione a regioni geografiche dev essere possibile colorare di rosso scarlatto gli stati in cui è presente almeno un installazione Bedeschi. Dev essere possibile visualizzare almeno i nomi degli stati in cui è presente Bedeschi. Nel caso di una configurazione a markers (marcatori) dev essere possibile inserire ulteriori informazioni per ogni marker, ad esempio un link o una breve descrizione dell impianto Breadcrumb Le breadcrumb si presentano quasi sempre come una sequenza lineare di collegamenti ipertestuali, divisi da un separatore, ordinati gerarchicamente dalla pagina più alta della gerarchia alla più bassa, rispettivamente da sinistra a destra. Non è quindi necessario specificare alcun tipo di caratteristica particolare relativamente alla loro presentazione Slider In accordo con il committente si è deciso che lo slider debba presentare le slide con un effetto di tipo fade (dissolvenza), mentre il contenuto testuale deve apparire (di seguito all immagine) con un effetto di scivolamento da sinistra, per poi scomparire scivolando verso sinistra. In modo lineare, le animazioni da eseguire per ogni slide sono le seguenti: Comparsa della slide (solo immagine di sfondo) con effetto fade (dissolvenza) Comparsa del testo da sinistra Scomparsa del testo verso sinistra Scomparsa della slide con effetto fade contemporaneamente alla comparsa della slide successiva Le animazioni devono avere durata molto breve (nell ordine del decimo di secondo), con pause più lunghe per permettere una lettura più agevole (nell ordine dei secondi). Le slide devono presentarsi in maniera temporizzata, creando una sorta di presentazione. Inoltre dev essere disponibile una parte di controllo per permettere all utente di sfogliare le slide in modo libero ed indipendente.

67 6.1. PROGETTAZIONE DI APPLICAZIONI E SERVIZI News ed Eventi Per quanto riguarda la presentazione di news ed eventi è stato deciso, in accordo con il committente, di mostrare le ultime tre news o eventi. Questa scelta è dovuta al fatto che mostrare un numero troppo grande di news rischia di far risultare trascurato il sito in quanto i visitatori si troverebbero di fronte alle stesse news a distanza di molto tempo, e non è possibile garantire un aggiornamento costante a brevi periodi di distanza. Per ogni news o evento si è deciso di mostrare titolo, data di pubblicazione, eventuale immagine di anteprima e excerpt (ovvero il testo in anteprima, solitamente le prime venti parole) Most Clicked Links In accordo con il committente si è deciso di presentare i link di questa sezione in modo diverso dagli altri presenti nel sito. I link in questione devono essere realizzati con colore chiaro su sfondo rosso a media opacità. Inoltre i link vengono ridisposti in modo casuale, e la dimensione dei caratteri è a sua volta modificata in modo casuale entro un certo intervallo Our History Per questa sezione si è deciso di applicare un effetto Parallax con lo scopo di dare una struttura temporale all evoluzione dell azienda. Questa tipologia di effetto ha riscosso un notevole successo negli ultimi due anni nella comunità del web design in quanto permette di enfatizzare molto bene pagine dai pochi contenuti, riuscendo a richiamare l attenzione su contenuti che altrimenti potrebbero risultare poco completi o di scarso interesse. L effetto parallasse si ottiene quando si hanno due oggetti posti a distanze differenti da un punto di osservazione. L immagine che si ottiene cambia se si sposta il punto di osservazione perpendicolarmente rispetto all asse degli oggetti in questione. In Figura 6.1 è possibile vedere un immagine esplicativa. Figura 6.1: Effetto parallasse

68

69

70

71

72 58 CAPITOLO 6. PROGETTAZIONE FRONT-END Figura 6.7: Mockup Home Page Desktop In Figura 6.7 è anche possibile vedere il footer del sito nella parte più bassa, contenente le informazioni legali e di accessibilità. Products Per la sezione Products si è deciso di utilizzare un interfaccia ancora più semplice.

73 6.2. PROGETTAZIONE DEL MOCKUP 59 Per quanto riguarda la visualizzazione mobile (Figura 6.8), dall alto al basso possiamo notare i seguenti elementi: Menù chiuso Breadcrumb Sottomenù della sezione Products Corpo dell articolo, contenente titolo, galleria e testo. Figura 6.8: Mockup Products Mobile I medesimi elementi sono visibili anche in Figura 6.9.

74 60 CAPITOLO 6. PROGETTAZIONE FRONT-END Figura 6.9: Mockup Products Desktop Anche in questo caso si è utilizzato un layout semplice, ma il menù principale resta invariato, quello secondario è inserito in una sidebar a sinistra ed è possibile vedere anche il link per il download di materiale aggiuntivo per quella particolare famiglia di prodotti. Menù Mentre per i contenuti il lavoro di progettazione del Mockup è piuttosto meccanico e segue delle linee standard, ho preferito approfondire l argomento per quanto riguarda i menù. Il sito è principalmente fruibile da tre tipologie diverse di dispositivi: Mobile, Tablet e Desktop. Per ognuna di queste categorie ho deciso di applicare uno stile differente al menù. Per quanto riguarda la versione Mobile è possibile vedere un Mockup in Figura 6.6. Come si può notare il menù è a scomparsa, è quindi sufficiente clicccare sul simbolo + per visualizzare il menù intero. Questa scelta è stata fatta a causa del numero piuttosto elevato di voci. Le voci principali sono su sfondo rosso scarlatto e con allineamento a sinistra. Le voci secondarie, invece, hanno uno sfondo leggermente più scuro e si discostano dal bordo sinistro per enfatizzare la gerarchia. Per il menù desktop è possibile visualizzare un Mockup in Figura 6.10.

75 6.2. PROGETTAZIONE DEL MOCKUP 61 Figura 6.10: Mockup Menù Desktop Come è possibile vedere, il menù per la versione Desktop utilizza un layout a schede, ma tramite evento hover del mouse (o il corrispettivo touchscreen) è possibile aprire il sottomenù a tendina. Infine, il layout per tablet (Figura 6.11) differisce da quello desktop esclusivamente per il logo (è stato omesso il nome aziendale). In questo caso è stato necessario cambiare logo in quanto il menù a schede ha come principale difetto quello di espandersi principalmente in larghezza, la quale in generale in web design è difficilmente gestibile. Per evitare che il menù collassasse a particolari risoluzioni a causa di poco spazio ho deciso di ridurre il logo. Figura 6.11: Mockup Menù Tablet Alcune considerazioni generali inerenti ai menù, per tutti e tre i layout, riguardano il colore (è stato scelto il rosso scarlatto come da direttive del committente) ed il carattere (è stato scelto il Futura Condensed, ovvero lo stesso carattere tipografico utilizzato per il logo aziendale).

76 62 CAPITOLO 6. PROGETTAZIONE FRONT-END

77 Capitolo 7 Sviluppo dell area amministrativa Dopo aver definito, nella fase di progettazione, come risolvere i vari aspetti critici del progetto è necessario procedere con l implementazione di quanto progettato. In questo capitolo è stato descritto il processo di implementazione della parte amministrativa, con l unica eccezione inerente alla Sezione 7.3 in cui sono stati descritti sia aspetti relativi al back-end che al front-end al fine di ottenere una descrizione meno frammentata. 7.1 Installazione e configurazione del CMS Come detto precedentemente, durante le attività di analisi ho identificato in WordPress il candidato ideale per lo sviluppo del progetto. Le attività di analisi, progettazione, implementazione e verifica sono state effettuate con la versione di WordPress. Al momento della scrittura del presente documento WordPress è disponibile nella versione (rilasciata il giorno 11/09/2013). Gli aggiornamenti apportati fra le due versioni non hanno un impatto elevato in termini di performance e sicurezza, pertanto ho deciso di non procedere con l aggiornamento del CMS. Inoltre, oltre a non essere più responsabilità del tirocinante, l aggiornamento è alla portata dell attuale gestore del sito (interno all azienda), dando ulteriore credito alla scelta di utilizzare un CMS per lo sviluppo di un sito web aziendale. L installazione del CMS WordPress non ha richiesto particolari competenze tecniche. Innanzitutto è stato necessario scaricare il pacchetto WordPress dal sito ufficiale[20]. Dopo aver scaricato il pacchetto contenente tutti i file necessari è stato sufficiente inserire la cartella all interno del server come per qualsiasi sito web; WordPress infatti non necessita di installazione in quanto non è un software eseguibile ma si tratta di una sorta di sito web molto complesso ed estremamente personalizzabile da utilizzare come base per costruire il proprio. Prima di effettuare il primo accesso (che porta ad un Wizard di configurazione) è stato necessario impostare alcuni parametri per indicare il database di riferimento, compreso eventuale dominio (nel caso sia diverso da quello in cui risiede il sito). Fatto questo, digitando da browser l indirizzo al dominio su cui è stato installato Word- Press si è avviato un Wizard di configurazione iniziale. Tramite questo wizard è stato possibile impostare altre preferenze (con possibilità di modificarle in seguito) quali nome del sito e creazione del primo utente amministratore. Relativamente agli account amministratori ho deciso di creare un solo account; sarà compito dell azienda decidere se e quanti account aggiungere e con quali privilegi. 63

78 64 CAPITOLO 7. SVILUPPO DELL AREA AMMINISTRATIVA Prima di passare alla realizzazione del tema personalizzato Bedeschi ho dovuto impostare altre preferenze standard, quali formato delle date, disattivazione dei commenti e varie impostazioni di lingua. 7.2 Implementazione della base informativa Come già detto nella Sezione 5.1 per la realizzazione della base informativa ho deciso di utilizzare lo strumento dei Custom Post Type (d ora in avanti abbreviato anche in CPT). La maggior parte dei CMS più evoluti permette la definizione di specifiche tipologie di contenuti. Questo permette al CMS (qualunque esso sia, WordPress incluso) di predisporre all amministratore un area in cui inserire dei contenuti in maniera guidata; ciò significa, quindi, non solo inserire del testo o immagini, ma permette ad esempio di inserire altre tipologie di metadati, quali file, collegamenti ipertestuali, immagini, contenuti multimediali ecc. Oltre a questo, creare dei tipi di contenuto specializzati è corretto anche dal punto di vista dell informazione pura; differenziare fra articoli, prodotti o qualunque altro tipo di contenuto correttamente descritto e specializzato permette una forte distinzione logica fra tutti i contenuti del sito, migliorando la manutenibilità e l organizzazione dell intera base informativa. La creazione di un Custom Post Type in WordPress è relativamente semplice. Tuttavia, la semplice creazione di un Custom Post Type si limita a creare una differente categoria di contenuto, il quale però non si differenzia dai semplici post già disponibili in WordPress. Nel nostro caso non era sufficiente dichiarare semplicemente un nuovo tipo di contenuto, ma per ogni tipologia di prodotto (Mining, Marine, Bulk Handling e Heavy Clay) è stato necessario (nonché specificato nell analisi) predisporre l inserimento di materiale aggiuntivo, in particolare due file.pdf contenenti rispettivamente Brochure di presentazione e Scheda Tecnica del prodotto in questione e un immagine descrittiva. Per fare questo ho dovuto aggiungere dei meta-dati in grado di contenere un riferimento ai file. Inoltre è stato necessario creare anche un semplice form per inserire tali file durante la creazione di un nuovo prodotto. Il codice che segue è un esempio (in particolare per la tipologia di prodotti Mining) di come sia stato possibile implementare tali funzionalità, ed è stato inserito nel file functions.php della cartella contenente il template. Prima di tutto è necessario creare e dichiarare un nuovo CPT dando un nome adeguato: Codice 7.1: Dichiarazione e definizione di un Custom Post Type, compreso il Meta Box per l inserimento dei metadati specificati 1 $args[ label ] = Mining Products ; // Nome del CPT 2 register_post_type( mining_product, $args ); // Dichiarazione di un nuovo CPT, con nome e parametri Fatto questo è necessario arricchire il CPT aggiungendo dei metadati. In questo caso i metadati sono due file.pdf, ma è necessario anche creare un piccolo form (chiamato Meta Box) per il loro inserimento. Esistono alcune funzioni deputate a questo scopo: 3 // Dichiaro il Meta Box e lo associo al CPT desiderato 4 function define_mining_meta_box() { 5 add_meta_box( mining_product_meta_box, 6 ( Product Informations ), 7 mining_meta_box, 8 mining_product, 9 normal );

79 7.2. IMPLEMENTAZIONE DELLA BASE INFORMATIVA } // Definisco il contenuto del Meta Box 13 function mining_meta_box( $post) { 14?> 15 // Inserisco il markup html per la creazione dei campi del form. 16 // Il codice seguente è inserito automaticamente all interno di 17 // un tag <form> e <fieldset> in quanto la funzione di un Meta 18 // Box è quella di fornire un form. 19 <p>add products details: </p> 20 <p> 21 <label for=" mining_product_img" >Image </ label > 22 <input type=" file" id=" mining_product_img" name=" mining_product_img" value=" <? php echo get_post_meta( $post->id, mining_product_img, true);?>" /> 23 </p> 24 <p> 25 <label for=" mining_product_spec" >Specifics </ label > 26 <input type=" file" id=" mining_product_spec" name=" mining_product_spec" value=" <? php echo get_post_meta( $post->id, mining_product_spec, true);?>"/> 27 </p> 28 <p> 29 <label for=" mining_product_brochure" >Brochure </ label > 30 <input type=" file" id=" mining_product_brochure" name=" mining_product_brochure" value=" <? php echo get_post_meta( $post->id, mining_product_brochure, true);?>"/> 31 </p> 32 <?php > 33 } Una volta definito un Meta Box e dopo averlo associato al CPT desiderato è necessario salvare i file sotto forma di meta-dati: 34 function mining_meta_box_save( $post_id) { 35 /* --- security verification --- */ 36 if( defined( DOING_AUTOSAVE ) && DOING_AUTOSAVE) return $post_id; 37 if( page == $_POST[ post_type ]) 38 if(! current_user_can( edit_page, $post_id)) return $post_id; 39 else 40 if(! current_user_can( edit_page, $post_id)) return $post_id; 41 /* - end security verification - */ 42 save_file( mining_product_img, image/ jpeg, $post_id); 43 save_file( mining_product_spec, application/ pdf, $post_id); 44 save_file( mining_product_brochure, application/ pdf, $post_id); 45 } Dopo aver salvato i file interessati come meta-dati è necessario associare le azioni di creazione e salvataggio del meta box e del relativo post rispettivamente alla definizione e salvataggio del meta box personalizzato creato in precedenza: 46 add_action( add_meta_boxes, define_mining_meta_box ); 47 add_action( save_post, mining_meta_box_save ); Infine ho ridefinito una funzione per il salvataggio dei file in WordPress. Questa funzione non è legata ad alcun meta box o CPT in particolare, si limita a salvare un file inserito dall utente nell archivio WordPress. 48 function save_file( $field_name, $file_type, $id) { 49 // Make sure the file array isn t empty 50 if(!empty($_files[$field_name][ name ])) { // Setup the array of supported file types. In this case it s just PDF 53 $supported_types = array( $file_type); // Get the file type of the upload 56 $arr_file_type = wp_check_filetype( basename( $_FILES[ $field_name][ name ])); 57 $uploaded_type = $arr_file_type[ type ];

80

81 7.3. IMPLEMENTAZIONE DELLE APPLICAZIONI E DEI SERVIZI 67 La definizione e dichiarazione dei Custom Post Type e dei relativi meta-box è stata fatta all interno di un unico file, define-metaboxes.php, incluso nel file functions.php. 7.3 Implementazione delle applicazioni e dei servizi In questa sezione sono descritte tecniche e metodologie che hanno permesso di implementare ciò che è stato progettato precedentemente nella Sezione 5.2. Tuttavia, nonostante per i processi di progettazione sia relativamente semplice distinguere fra progettazione back-end e progettazione front-end, non è altrettanto semplice applicare la medesima suddivisione per le attività di sviluppo, in particolar modo nel caso in cui si scelga di utilizzare plugin o librerie esterne a WordPress che forniscono l insieme degli elementi di progettazione back-end e front-end. A questo proposito ho deciso di riunire lo sviluppo delle applicazioni e dei servizi in un unica sezione (a differenza di quanto fatto con la progettazione, la quale è stata divisa nelle Sezioni 5.2 e 6.1), in modo da rendere più chiara e fluente la lettura del documento Gallerie Dopo aver definito le caratteristiche progettuali delle gallerie alle sezioni e è stata possibile la loro implementazione. A differenza di altre applicazioni e servizi è stato deciso di utilizzare un plugin WordPress. Questa scelta è dovuta al fatto che la richiesta di utilizzo di gallerie è estremamente frequente da parte della comunità WordPress, e questo ha permesso lo sviluppo di moltissimi plugin che variano da funzionalità minime ad estremamente complete. Il plugin che è stato scelto è NextGEN Gallery[21], di cui è possibile visualizzare un anteprima dell area amministrativa in Figura 7.2. Figura 7.2: Area amministrativa del plugin NextGEN Gallery

82

83 7.3. IMPLEMENTAZIONE DELLE APPLICAZIONI E DEI SERVIZI 69 Sezione 5.2.2), ovvero ad aree geografiche e a marcatori. In Figura 7.5 è possibile vedere un esempio di visualizzazione a regioni. Figura 7.5: Esempio di mappa con visualizzazione per regioni Come è possibile vedere la mappa rende molto bene la presenza mondiale dell azienda. La scelta del colore rosso è azzeccata in quanto richiama le tonalità del layout [R6.1], ovvero il colore aziendale. Inoltre, come si può notare in Figura 7.6, la mappa è realizzata tramite immagini vettoriali in formato.svg. In questo modo lo zoom 1 non altera la qualità dell immagine visualizzata a risoluzioni differenti. Figura 7.6: Mantenimento della qualità di immagine per immagini vettoriali In Figura 7.7 è invece possibile vedere un esempio di visualizzazione a marcatori. 1 Lo zoom è attivabile tramite i tasti in alto a sinistra del box, tramite scroll del mouse o tramite pinch to zoom. Il pinch to zoom è un particolare tipo di evento associato ai dispositivi di tipo touchscreen (display o trackpad) che consiste nell avvicinare o distanziare due dita (generalmente pollice e indice) rispetto ad un punto sulla superficie interessata.

84 70 CAPITOLO 7. SVILUPPO DELL AREA AMMINISTRATIVA Ogni marcatore indica una diversa installazione Bedeschi nel mondo. Visto la lunga storia dell azienda non è possibile pensare di inserire in maniera chiara tutte le commesse realizzate; per questo motivo tale modalità di visualizzazione viene utilizzata esclusivamente per rappresentare solo le installazioni di maggior spessore. Figura 7.7: Esempio di mappa con visualizzazione con marcatori Come si può notare dallo screenshot, posizionando il cursore sopra ad un marcatore è possibile accedere ad un link. È previsto che i link non siano disponibili per ogni marcatore Breadcrumb Per l implementazione della breadcrumb si è deciso di utilizzare l ottimo plugin di WordPress Breadcrumb NavXT, disponibile nella pagina ufficiale dei plugin WordPress[23]. Questo plugin è estremamente efficiente in quanto permette la personalizzazione di molti aspetti inerenti le breadcrumb. Per quanto riguarda la presentazione è possibile scegliere il simbolo di separazione. Colori e stili dei link possono essere facilmente impostati da CSS grazie all abbondante uso di classi che descrivono posizione e caratteristiche di ogni singolo link. Infine è possibile dare un numero massimo di lettere come lunghezza dei collegamenti ipertestuali e dare alcune direttive per la creazione dell attributo Title dei link. In Figura 7.8 è possibile vedere uno screenshot dell effetto di tale plugin (dove l ultima voce, ovvero la pagina in cui ci si trova, non è un link, coerentemente con le linee guida per l accessibilità[8, 9]). Figura 7.8: Esempio di Breadcrumb in layout Mobile

85 7.3. IMPLEMENTAZIONE DELLE APPLICAZIONI E DEI SERVIZI Slider In seguito a numerose ricerche per identificare un plugin (sia per WordPress che uno generico per JQuery) sono arrivato alla conclusione che slider di questo tipo che garantiscano un buon funzionamento, una discreta pulizia nelle sequenze di animazioni e con layout fluido sono decisamente rari, ed i pochi che garantiscono tutto ciò sono molto pesanti sia in termini di dimensioni dei file sorgente che in termini di elaborazione da parte dei browser (caratteristica notata ad occhio nudo su demo in locale dei plugin stessi). Vista anche la volontà da parte del laureando di approfondire le conoscenze di JQuery e Javascript ho deciso di realizzare uno slider in modo totalmente autonomo. Questa attività ha richiesto una quantità di tempo non indifferente, tuttavia ha permesso di ottenere uno slider efficiente (la sequenza delle animazioni è stata rigidamente definita a priori, confermando i vantaggi dati da una buona progettazione) e soprattutto poco oneroso. La struttura dello script è relativamente semplice: inizialmente sono presenti alcuni parametri per regolare la temporizzazione degli effetti e del cambio slide. Dopodiché alcune istruzioni permettono di configurare la struttura della pagina (nel caso Javascript non sia abilitato lo slider non è visibile). Lo script stesso genera il menù di navigazione delle slide. Il cuore dello script è la funzione che permette di selezionare l i-esima slide, mentre altre funzioni più semplici ricorrono alla funzione precedente per scegliere la slide successiva/precedente. Infine, tramite funzione setinterval(), viene avviata la presentazione. Oltre ai classici eventi sul pannello di controllo della slide sono stati utilizzati (grazie alla libreria JQueryMobile) anche gli eventi per riconoscere il gesto di Swipe (strisciare, scorrere) tipico dei dispositivi touchscreen. Inoltre, assieme a diversi accorgimenti del codice CSS, è stato implementato un layout flessibile che permetta la visualizzazione e l esecuzione dello script su dispositivi di diverse dimensioni. Le abbondanti dimensioni in altezza dello slider sono state richieste esplicitamente dal committente. In Figura 7.9 alcuni screenshot che illustrano il passaggio da una slide all altra (con layout ottimizzato per Tablet). Figura 7.9: Screenshot d esempio delle principali fasi dello Slider

86 72 CAPITOLO 7. SVILUPPO DELL AREA AMMINISTRATIVA News ed Eventi Per quanto riguarda la visualizzazione degli ultimi articoli, WordPress offre una serie di funzioni per poter visualizzare un numero limitato di articoli, deciderne l ordinamento ed i metadati da mostrare. Per questi motivi non è stato necessario ricorrere a strumenti esterni come plugin. Per il risultato ottenuto in Home Page (ultimi 3 post, per ciascuno si visualizzano titolo, data, immagine di anteprima ed anteprima del testo) sono state utilizzate le seguenti funzioni WordPress: get_posts() setup_postdata() get_permalink() get_the_excerpt() get_the_post_thumbnail() the_title() Most Clicked Links La realizzazione di uno script che esegua quanto definito nelle Sezioni e è piuttosto banale. Fissati i valori dell intervallo per quanto riguarda la dimensione dei caratteri è stato sufficiente realizzare una semplice funzione che restituisca dei valori randomici all interno di quell intervallo. Un altra funzione si occupa di riordinare i link in modo casuale. In Figura 7.10 è possibile vedere l effetto dello script in Home Page. Figura 7.10: Esempio di randomizzazione dei link in Home Page Our History Per realizzare l effetto descritto precedentemente nelle Sezioni e ho deciso di utilizzare uno script in maniera analoga a quanto fatto nel sito di London School of Hygiene & Tropical Medicine[24]. Per ottenere quest effetto è stato implementato uno script Javascript (con ampio utilizzo di JQuery) che fa muovere a velocità differenti tre piani sovrapposti, in modo da simulare l effetto parallasse come descritto in Sezione Come è possibile vedere in Figura 7.11 l utilizzo di una linea temporale è molto appropriato per la rappresentazione della storia aziendale.

87 7.3. IMPLEMENTAZIONE DELLE APPLICAZIONI E DEI SERVIZI 73 Figura 7.11: Screenshot d esempio per la sezione Our History

88 74 CAPITOLO 7. SVILUPPO DELL AREA AMMINISTRATIVA

89 Capitolo 8 Sviluppo del Tema Grafico Durante l analisi dei vari CMS disponibili sul mercato ho evidenziato il fatto che Word- Press metta a disposizione una gran quantità di materiale gratuito per gli utenti, sia plugin che Themes (temi). Molti temi WordPress sono rilasciati con licenza GPL v2, pertanto è possibile modificarli e ridistribuirli secondo le metodologie previste da tale licenza. WordPress inoltre permette la creazione di Child Theme, ovvero gerarchie di temi, utilizzando un tema come base da incrementare a piacimento. Tuttavia molti di questi temi (in particolar modo quelli di maggior qualità, ovvero che rispettino al massimo i princìpi di accessibilità) sono piuttosto complessi, in quanto sono composti da diversi template di pagina e fogli di stile. Inoltre, proprio perché studiati per un utilizzo generico, questi temi non forniscono layout particolarmente elaborati. Per il progetto in questione, in seguito all analisi dei requisiti ed alla progettazione, sarebbe stato poco opportuno scegliere un tema padre da utilizzare come punto di partenza per realizzare il tema Bedeschi, in quanto questo richiede pochi elementi fortemente caratterizzati da uno stile particolare, mentre la curva di apprendimento per analizzare e modificare un tema già esistente è piuttosto elevata, soprattutto considerata la complessità dei temi più completi e di qualità. Per questi motivi ho deciso di realizzare un tema apposito senza utilizzare temi di partenza o framework. Prima di descrivere in dettaglio come sia stato implementato il tema è necessario introdurre la metodologia di sviluppo utilizzata. 8.1 Metodologia di sviluppo dell interfaccia grafica Per questo progetto ho deciso di applicare un approccio Mobile-First[18] per la realizzazione dell interfaccia grafica. Questa scelta è dovuta al fatto che le dimensioni ridotte degli schermi dei dispositivi mobile rendono lo sviluppo dell interfaccia grafica relativamente semplice in quanto quasi sempre viene seguito un layout di tipo lineare dall alto al basso, in cui ogni contenuto occupa l intera larghezza del dispositivo; diversamente ci troveremmo di fronte a layout difficilmente interpretabili, magari con la necessità di ingrandire le dimensioni della pagina per riuscirvi ad accedere. Di conseguenza, partire da un layout non complesso semplifica estremamente le attività di ampliamento del layout, in quanto il layout verticale tipico dei dispositivi mobile non si differenzia di molto dal layout naturale che viene assegnato alle pagine non stilizzate. 75

90 76 CAPITOLO 8. SVILUPPO DEL TEMA GRAFICO 1 /* 2 Anche in termini di sviluppo è evidente come questo approccio sia decisamente consigliabile; realizzare un foglio di stile in ottica mobile permette di ottenere un foglio principale relativamente semplice pronto per essere arricchito con ulteriori regole specifiche per tablet, desktop e widescreen. Al contrario, se si decidesse di cominciare strutturando il layout desktop si dovrebbe lavorare molto di più per eliminare le regole desktop in ogni possibile versione mobile. 8.2 Creazione di un nuovo Theme Il sistema WordPress per la creazione di temi è relativamente semplice, in quanto utilizza una logica simile a quella utilizzata finora dai programmatori web non muniti di CMS. Innanzitutto è stato necessario creare una nuova cartella (la directory principale del tema) all interno della cartella contenente tutti i temi WordPress disponibili per l installazione in questione. Questa cartella richiede un solo file per essere riconosciuta dal CMS come tema, ovvero style.css. Questo file deve contenere alcune informazioni fondamentali per permettere il riconoscimento del tema, in particolare: Codice 8.1: Dichiarazione di un Theme 3 Theme Name: Bedeschi 4 Description: Bedeschi is the personal theme for Bedeschi S.p.A. s company website 5 Version: 0.1 Author: Marco Begolo, Bedeschi S.p.A. 6 License: GNU General Public License v2 or later 7 License URI: www. gnu. org/ licenses/gpl-2.0. html 8 9 Bedeschi WordPress Theme, Copyright (C) 2013 Marco Begolo */ Queste informazioni vengono interpretate dal motore del CMS e mostrate all utente al momento della scelta del tema da applicare. Oltre al file in questione, nella medesima cartella è possibile inserire un immagine (generalmente uno screenshot anteprima del tema), con il nome esatto screenshot.png, che viene utilizzata per dare un anteprima del tema nella schermata di amministrazione nel momento in cui viene scelto il tema. Il file style.css, opportunamente commentato, è quindi predisposto ad ospitare le regole per la formattazione dei contenuti. Quasi sempre questo file contiene direttamente le regole CSS da applicare, ma nel mio caso ho preferito limitarmi ad importare vari file.css contenuti in una directory dedicata; questa scelta è dovuta ad una personale preferenza nella suddivisione del codice, in quanto sono stati realizzati fogli di stile differenti per le varie modalità di visualizzazione (tramite mediaqueri) e per il layout di stampa. Nonostante con quest unico file sia possibile formattare i contenuti non è ancora possibile strutturarli come desiderato; le regole verrebbero applicate alla visualizzazione standard dei contenuti fornita da WordPress. Per poter gestire anche la struttura dei contenuti è necessario utilizzare i Template. 8.3 Template WordPress utilizza un metodo particolare per visualizzare i contenuti. Ogni volta che viene richiesta una determinata pagina in realtà viene effettuata una richiesta http con query-

91 8.3. TEMPLATE 77 string [g], la quale identifica un contenuto (page, post, custom post type ecc.) da visualizzare. A seconda del tipo di pagina da visualizzare WordPress utilizza un file.php (che può essere specificato per ogni tipologia di contenuto richiesto, come vedremo in seguito) per strutturare il contenuto e decidere in quale posizione del codice inserire i dati (ed eventualmente metadati) del contenuto. Chiaramente ognuno di questi file ha anche la possibilità di inserire codice statico o staticamente determinato (ovvero, all interno di questi file è possibile effettuare una richiesta di contenuto in maniera indipendente dalla richiesta effettuata dall utente). I file che permettono di definire come strutturare il contenuto vengono chiamati Template. Ne esistono di diversi tipi, generici (come page.php e single.php), specializzati per tipologia di contenuto e addirittura specializzati per singola pagina (o meglio per singolo contenuto, ad esempio nel caso in cui volessimo presentare un determinato post o page in modo diverso dagli altri). La gerarchia completa di come vengono utilizzati questi file è disponibile in Figura 8.1 (a pagina 78). Per realizzare questo progetto sono stati implementati dieci template, dei quali segue una tabella descrittiva (Tabella 8.1): Nome File Descrizione single.php Struttura un singolo POST. È uno dei template generici, in quanto viene utilizzato per qualunque post nel caso non vi siano template più specifici single-bh_product.php Struttura i Custom Post Type di tipo Bulk Handling single-hc_product.php Struttura i Custom Post Type di tipo Heavy Clay single-marine_product.php Struttura i Custom Post Type di tipo Marine single-mining_product.php Struttura i Custom Post Type di tipo Mining single-major_realization.php Struttura i Custom Post Type di tipo Major Realization page.php Struttura una singola PAGINA. È uno dei template generici, in quanto viene utilizzato per qualunque pagina nel caso non vi siano template più specifici page-global-presence.php Struttura la pagina con slug [g] global-presence page-home.php Struttura la pagina con slug home (la home page) page-key-people.php Struttura la pagina con slug key-people Tabella 8.1: Elenco dei file di Template realizzati per il progetto

92 78 CAPITOLO 8. SVILUPPO DEL TEMA GRAFICO Figura 8.1: Gerarchia di Template in WordPress[19]

93 8.4. HEADER E FOOTER Header e Footer La caratteristica principale di un CMS è di rispondere ad una particolare richiesta (http) con un contenuto prelevato dal database (opportunamente gestito). Questa operazione può sembrare banale e non diversa da quella di un qualsiasi sito internet privo di management system, tuttavia è inaccettabile pensare di ripetere le parti ricorrenti del sito (come menu, footer ed altri elementi standard) in ogni singolo contenuto (per motivi di efficienza sia nello storage che nella trasmissione delle informazioni). A tal proposito è necessario indicare al CMS quali sono le parti di codice ricorrente. In WordPress, come già detto, ogni contenuto prelevato viene strutturato grazie a file detti Template. Tuttavia questi file si occupano semplicemente di dare una struttura ai dati e metadati del contenuto in questione. Informazioni come menu, sidebar, footer e logo del sito non fanno assolutamente parte dei dati di un contenuto. Per questo è necessario inserirli in file appositi, che prendono il nome di header.php e footer.php. Questi file contengono le informazioni da inserire ogni volta prima e dopo un contenuto, in qualunque modo esso sia strutturato, e ovviamente possono includere script PHP che vengono elaborati dal server. In realtà quello che succede è che quando un file di template viene richiamato si occupa di richiamare header e footer utilizzando rispettivamente le funzioni WordPress get_header() e get_footer(), ed eventualmente si occupa di posizionare una o più sidebar (barra laterale, tramite le funzioni get_sidebar() o get_dynamic_sidebar()) fra header e footer. Esiste inoltre un ulteriore funzione, get_template_part(), che permette di richiamare parti di template da inserire nel template attuale. Questa funzione può essere utilizzata per aumentare il riuso del codice o per definire ulteriori elementi ricorsivi all interno del layout. Infatti WordPress prevede l esistenza di solo header, footer ed un numero variabile di sidebar, ma pensando a layout meno standard potrebbe essere necessario definire ulteriori elementi ripetuti. 8.5 Scripting client-side Come detto in precedenza, per lo sviluppo di questo progetto è stato fatto un discreto utilizzo di Javascript per realizzare alcuni script client-side. In WordPress, pagine, post e articoli possono essere aggiunti dall area amministrativa (tramite opportuno editor) direttamente in linguaggio HTML, tuttavia non è possibile inserire degli script per motivi di sicurezza e robustezza del software. Per fare ciò è necessario includere gli script desiderati nei template di pagina (o nei file header.php, footer.php, sidebar.php ecc.), sia in modo diretto utilizzando il tag <script>, sia caricandoli da file.js. Bisogna però prestare attenzione al fatto che WordPress fa già di per sé un ampio utilizzo di Javascript: è quindi opportuno pensare sempre alle eventuali dipendenze e prestare attenzione affinché gli script personali non interferiscano con (o non vegano disturbati da) script o librerie già presenti. Ad esempio la libreria JQuery è disponibile di default nell ambiente WordPress; nel caso in cui volessimo utilizzare uno script che faccia utilizzo di JQuery dobbiamo assicurarci che questo sia caricato solo dopo la libreria. Viceversa, se lo script carica autonomamente JQuery si avrebbe una doppia importazione della medesima libreria, con un elevato rischio di conflitti (in particolar modo per versioni differenti della medesima libreria). Questo problema è estremamente frequente, anche perché altre librerie Javascript (ad esempio Mootools, less e Modernizr) sono utilizzate molto spesso.

94 80 CAPITOLO 8. SVILUPPO DEL TEMA GRAFICO Per ovviare a questo problema WordPress è in grado di gestire una coda di inclusione di script. Questa coda serve per gestire in modo esatto l ordine di inclusione degli script ed eventuali dipendenze. La funzione principale per gestire questa coda è wp_enqueue_script(), ma ne esistono molte altre per rimuovere o modificare script dalla coda. Di seguito vediamo un esempio di come sia stata utilizzata questa funzione. Codice 8.2: Contenuto del file page-global-presence.php 1 <? php // Inclusione degli script 2 function my_scripts_method() { 3 wp_enqueue_script( jvectormap, get_stylesheet_directory_uri(). / js/ libs/ jqueryjvectormap min. js, array( jquery )); 4 wp_enqueue_script( jvectormap- world- map, get_template_directory_uri(). / js/ libs/ jquery-jvectormap-world-mill-en.js,array( jvectormap )); 5 wp_enqueue_script( jvectormap- map, get_template_directory_uri(). / js/ map/ map. js, array( jvectormap-world-map )); 6 } 7 add_action( wp_enqueue_scripts, my_scripts_method ); 8?> 9 10 <?php get_header();?> // Inclusione dell header <?php if (have_posts()) :?> // Loop di WordPress 13 <?php while (have_posts()) : the_post();?> 14 // Esiste un post 15 <h2><?php the_title();?></h2> // Stampo il titolo del post 16 <?php the_content();?> // Stampo il contenuto del post 17 <?php endwhile;?> 18 <?php endif;?> <?php get_footer();?> // Inclusione del footer Il codice presentato è un template di pagina, in particolare è il template che struttura la pagina con slug [g] global-presence. Come si può vedere, alla riga 10 viene importato l header, le righe da 12 a 18 viene strutturato il contenuto della pagina (ad esempio, il titolo della pagina viene inserito all interno di un tag h2) e alla riga 20 viene incluso il footer, il tutto in accordo con quanto descritto alle Sezioni 8.3 e 8.4. Si presti ora attenzione alle prime righe: la riga 3 mette in coda uno script di nome jvectormap, con una determinata posizione, in dipendenza con lo script jquery, già dichiarato da WordPress. La riga successiva, invece, include lo script jvectormap-world-map, di cui ne definisce la posizione, dipendentemente dallo script accodato in precedenza, ovvero jvectormap. In questo modo gli script sono stati dichiarati ed inclusi in una coda senza il rischio di conflitti. Inerentemente ai conflitti, è opportuno far notare che gli script JQuery devono essere scritti all interno di un particolare ambiente a causa del carattere speciale $: jquery(document).ready(function ($) { // Codice JQuery }); Infine, si riporta in Tabella 8.2 l elenco degli script realizzati con relativa descrizione.

95 8.6. FOGLI DI STILE 81 Nome File Descrizione show_menu.js Lo script utilizzato per far aprire e chiudere il menù in visualizzazione mobile randomize_links.js Lo script utilizzato per randomizzare i link in Home Page map.js Lo script utilizzato per mostrare la mappa dinamica e per variarla al clic sui radiobutton per la selezione della modalità di visualizzazione slider.js Lo script utilizzato per lo Slider in Home Page Tabella 8.2: Elenco degli script Javascript realizzati dal laureando 8.6 Fogli di stile La realizzazione dei fogli di stile è, in genere, un attività poco complessa che tuttavia tende a diventare estremamente confusionaria nel tempo. Questa caratteristica è data dal fatto che le modifiche da apportare all interfaccia grafica tendono ad essere effettuate e ripetute più volte per diversi motivi, dall inesperienza dello sviluppatore ai gusti personali dello stesso o del cliente. Nonostante la realizzazione di Mockup dettagliati aiuti a mitigare questo effetto non è sufficiente ad eliminarlo completamente, soprattutto a causa della natura dei fogli di stile: essi, infatti, sono composti da delle regole che si occupano di formattare gli elementi della pagina, ma queste regole devono essere applicate in gran quantità, aumentando così la complessità generale e, di conseguenza, la leggibilità del documento. Personalmente trovo molto utile suddividere tutto il codice sul più fogli separati, ognuno con un compito specifico. Per il progetto in questione ho utilizzato i file elencati e descritti in Tabella 8.3.

96 82 CAPITOLO 8. SVILUPPO DEL TEMA GRAFICO Nome File Descrizione style.css Il foglio principale, fondamentale per il riconoscimento del tema WordPress (per maggiori dettagli si vedano la Sezione 8.2 e il Codice 8.1), che contiene l inclusione tramite di tutti gli altri fogli di stile. css/style.css Il foglio di stile generale dell intero tema css/table.css Il foglio di stile per la formattazione delle tabelle css/print.css Il foglio di stile per la formattazione della versione di stampa css/nggallery.css Il foglio di stile per la formattazione delle gallerie (fornito assieme al plugin NextGenGallery) css/home.css Poiché la Home Page ha una struttura ed una formattazione diverse da tutte le altre pagine ho deciso di riunire tutte le regole inerenti a questa pagina in questo foglio di stile separato css/slider.css Il foglio di stile utilizzato per formattare tutti gli elementi esclusivi dello slider Tabella 8.3: Elenco dei fogli di stile utilizzati e loro descrizione Media Queries e Breakpoint Le linee guida per l accessibilità[8, 9] indicano chiaramente che un sito, per essere accessibile, deve anche rispettare il principio di portabilità, ovvero dev essere visitabile da più di un dispositivo. Per fare questo, CSS offre uno strumento utilissimo, ovvero le Media Query. Tramite il è possibile specificare una porzione di regole da applicare solo a determinati tipi di media, siano essi schermi, screen-reader, stampe ecc. Il permette inoltre di specificare altre caratteristiche, ad esempio la dimensione minima dello schermo richiesta per applicare le regole specificate. Questa funzionalità in particolare ha incrementato la potenza del codice CSS permettendo di realizzarlo in maniera specifica per dimensioni differenti di display. Da questo nasce la necessità di individuare i cosiddetti Breakpoint, ovvero dei punti di interruzione sulla larghezza della pagina web, necessari per categorizzare i differenti layout (mobile, tablet, ecc). Per questo progetto ho dovuto pensare a tre principali breakpoint: Il primo per definire quando passare da layout mobile a tablet (631px). Il secondo per definire quando passare da layout tablet a desktop (1024px). Il terzo per definire quando passare da layout desktop a wide-desktop (1366px). È tuttavia opportuno specificare alcune considerazioni:

97 8.6. FOGLI DI STILE 83 Il passaggio da layout mobile a tablet avviene su una larghezza in pixel non standard, in quanto i display a basse risoluzioni hanno risoluzioni estremamente eterogenee. La maggior parte dei tablet ha una risoluzione orizzontale di 1024px, rientrando di conseguenza nella categoria desktop. Tuttavia questa caratteristica non è un problema, in quanto i tablet con dimensione orizzontale di 1024px hanno monitor con le medesime dimensioni (fisiche e in pixel) dei netbook da 10 (estremamente diffusi) La progettazione e lo sviluppo vengono fatte comunque in chiave di larghezza in pixel, non in base al dispositivo Quest ultima considerazione, tuttavia, merita un approfondimento. La grande varietà di dispositivi che permettono l acceso ad internet ha reso necessario realizzare siti che siano portabili. D altro canto l evoluzione tecnologica ha portato ad un notevole incremento della qualità dei display; uno dei fattori di valutazione della qualità di un display è la sua risoluzione in ppi (pixel per inch), ovvero il numero di pixel presenti in un pollice quadrato. Consideriamo un display molto grande in termini di dimensioni fisiche, ma piccolo in termini di dimensioni in pixel (come, ad esempio, i vecchi videoproiettori 800x600), quindi con risoluzione (ppi) estremamente ridotta: questa tipologia di dispositivi ricadrebbe in una visualizzazione tablet del sito, graficamente poco appropriata per display dalla grandi dimensioni (fisiche). Ora consideriamo il display di un cellulare di ultima generazione; questi dispositivi possono vantare risoluzioni elevatissime, superiori ai 300ppi (ad esempio, il famoso Display Retina di Apple conta 326ppi di risoluzione), ovvero pari alla risoluzione standard di stampa (300dpi, ovvero la risoluzione media per cui l occhio umano non riesce più a distinguere un singolo punto). Risoluzioni così elevate su display da 4-5 pollici portano facilmente a superare i 1024px (ad esempio, il Samsung Galaxy Note II ha un display da 1280x720 pixel), rientrando così nella visualizzazione per desktop. Queste considerazioni fanno capire che, nonostante il potente mezzo fornito dal linguaggio CSS, per ottenere ottimi risultati non è sufficiente realizzare un sito pensando esclusivamente alle dimensioni in pixel, analogamente a quanto accade per le dimensioni degli elementi della pagina. Le linee guida[8, 9] consigliano di utilizzare dimensioni relative (espresse cioè in em o percentuale) per definire dimensioni di box e altri elementi all interno delle pagine web. Questo principio può (e dovrebbe) quindi essere applicato anche per quanto riguarda i breakpoint; è molto più sensato valutare la larghezza di un dispositivo in em (ricordo che 1em equivale alla larghezza in pixel del carattere M [maiuscolo]) piuttosto che in pixel. È responsabilità dei produttori di dispositivi aumentare le dimensioni del testo di default in caso di display ad elevate risoluzioni Font e tipografia Il logo aziendale è stato realizzato utilizzando un vecchio Font tipografico chiamato Futura Condensed. Da sempre i Font sono stati il cuore della tipografia, ma su web hanno creato diversi problemi in quanto la progettazione di un sito non deve assolutamente seguire le regole di progettazione tipografica. Nonostante sia assolutamente consigliato utilizzare Font progettati esclusivamente per il web, il committente ha richiesto espressamente di utilizzare il Futura Condensed (che è stato

98 84 CAPITOLO 8. SVILUPPO DEL TEMA GRAFICO creato per la tipografia e non per il web). Questo Font è stato utilizzato in grandi dimensioni esclusivamente per formattare le voci in menù. Inoltre si tratta di un font sans-serif (senza grazie), quindi più indicato ad essere utilizzato su display rispetto a font graziati. Grazie all utilizzo del è possibile visualizzare dei Font specifici (in questo caso Futura Condensed) anche se questi non sono presenti nel dispositivo che accede al sito.

99 Capitolo 9 Accessibilità e qualità del software L Ingegneria del Software ha contribuito in gran misura a diffondere e, soprattutto, definire il concetto di qualità del software, in particolare grazie all introduzione di metodologie e attività atte a garantire una serie di caratteristiche indice della qualità stessa. Non è semplice riuscire a percepire, e ancor di più definire, quali parametri siano indici di qualità, e a questo proposito l Ingegneria del Software ha messo definito dei parametri[25] (suddivisi fra esterni ed interni) per la valutazione della qualità software (Figura 9.1)[11]. Figura 9.1: Parametri di valutazione della qualità del software Chiaramente, la sola definizione dei parametri non è sufficiente; è necessario effettuare delle misurazioni e definire delle metriche che permettano di realizzare e confrontare tali misurazioni su quei parametri. Questa metodologia di approccio nei confronti della qualità del software è senz altro efficace in generale, ma personalmente l ho trovata poco adatta rispetto al software web. Questa incompatibilità è probabilmente dovuta alla natura della programmazione web. Secondo il W3C un Web Service è un sistema software progettato per supportare l interoperabilità tra diversi elaboratori su di una medesima rete ovvero in un contesto distribuito. Questo fa capire come la realizzazione di un software web sia fondamentalmente differente da altro tipo di software in quanto si basa in gran parte sulla comunicazione e trasmissioni di dati, oltre ad essere differente da altri punti di vista quali linguaggi di programmazio- 85

100 86 CAPITOLO 9. ACCESSIBILITÀ E QUALITÀ DEL SOFTWARE ne (generalmente interpretati e non compilati, rendendo differente anche la metodologia di testing) e contesto applicativo. Tuttavia, con riferimento alla Figura 9.1, possiamo notare come molti parametri indici di qualità definiti dallo standard ISO ISO/IEC 9126:2001 coincidano con i princìpi di accessibilità definiti dal WCAG 2.0. Il rispetto dell accessibilità web, a differenza di quanto possa far pensare il nome, non comprende solo una serie di parametri per garantire un accesso il più possibile universale, ma permette di garantire anche un buon livello di qualità del software sia dal punto di vista della realizzazione (interno), sia dal punto di vista del risultato (esterno). Alla luce di queste considerazioni si può capire quanto fondamentale sia garantire e seguire i princìpi di accessibilità per lo sviluppo web. 9.1 Verifica dell accessibilità Come specificato nell analisi [R4.1] si è deciso di rispettare le linee guida WCAG 2.0 con almeno priorità 1 (A). Tuttavia il laureando ha cercato il più possibile di aderire alle linee guida di priorità 2 (AA) ed in alcuni casi anche di priorità 3 (AAA). Per una descrizione più dettagliata dei princìpi di accessibilità e loro priorità si rimanda a [8, 10, 9]. La verifica di tali princìpi non è sempre verificabile in modo automatico. Un esempio potrebbe riguardare l utilizzo dei colori, per i quali è opportuno fare attenzione ad utilizzare colori non troppo simili ed evitare confusione fra contenuto e presentazione. Tuttavia, molti dei princìpi seguiti possono essere verificati tramite analisi statica del codice. Per far questo ho utilizzato uno strumento online che si occupa di analizzare porzioni di codice e di definire quale livello si accessibilità si è riusciti a raggiungere. Il test in questione è stato effettuato grazie al servizio AChecker[26] su tutte le pagine del sito presenti al momento della redazione del presente documento. Come si può vedere in Figura 9.2, il risultato è stato più che positivo, dimostrando che il sito rispetta almeno i princìpi di priorità 2 (AA). Figura 9.2: Risultato del test di verifica statica sull accessibilità L esempio è relativo al test effettuato sulla Home Page 9.2 Validazione HTML5 e CSS3 Analogamente a quanto fatto per l accessibilità è possibile effettuare dei test statici sul codice HTML(5) e CSS. Per il test HTML5 è stato utilizzato il servizio W3C Markup Validation Service[27], il cui risultato (inerentemente alla home page) è visibile in Figura 9.3.

101 9.2. VALIDAZIONE HTML5 E CSS3 87 Figura 9.3: Risultato del test di verifica statica del codice di markup Per il test CSS è stato utilizzato il servizio W3C CSS Validation Service[bib] il cui risultato (inerentemente alla home page) è visibile in Figura 9.4.

102 88 CAPITOLO 9. ACCESSIBILITÀ E QUALITÀ DEL SOFTWARE Figura 9.4: Risultato del test di verifica statica del codice CSS Entrambi i test hanno portato a risultati accettabili. 9.3 Controllo Cross-Browser Gli utenti che navigano in Internet possono scegliere fra un gran numero di browser differenti. Fra i browser più comuni possiamo elencare Microsoft Internet Explorer, Mozilla Firefox, Safari, Google Chrome e Opera. Tuttavia, questi cinque browser si suddividono a loro volta in un gran numero di versioni. Alcuni, come Chrome, interpretano il codice in modo simile fra versioni molto distanti l una dall altra. Altri, quali Internet Explorer e Opera, avendo alle spalle diversi anni di attività sul mercato, hanno visto un notevole numero di cambiamenti. Il risultato è che oggi alcuni browser (come ad esempio Internet Explorer 6 e Internet Explorer 10) interpretano il codice in maniera assolutamente differente.