Plasmare il Web

Quali tappe deve percorrere un progetto web perché da idea si trasformi in prodotto finito e funzionante?

La road map

È in questo senso che nel libro di Roberto Polillo, Plasmare il Web, viene utilizzato il termine "road map": un percorso di massima che porti il progetto a destinazione.

Il volume, destinato a coloro che realizzano siti web, evidenzia subito che "un errore molto frequente è di impostare la grafica del sito prima di averne definito la struttura di navigazione e l'architettura informativa" (p. 16).

Qual è invece il giusto ordine?

1. Definizione dei requisiti
2. Avviamento del progetto e piano di lavoro
3. Web design
4. Visual design
5. Sviluppo del sito
6. Stesura e inserimento contenuti
7. Collaudo del sito, pubblicazione e pubblicizzazione

I modelli proposti andranno ovviamente adattati alle diverse situazioni. È sempre prevista, da Polillo, la figura del consulente esterno, una figura terza fra committente e fornitore, figura che però in progetti di medie e piccole dimensioni, per ovvie ragioni di budget, non esiste. Sarà il professionista coscienzioso, in questi casi, a occuparsi della prima fase di definizione dei requisiti, al posto del consulente.

Utile nel libro è il capitolo sulla definizione dei requisiti e delle specifiche funzionali di un sito; momento fondamentale nella costruzione del sito, ma spesso trascurato. Nell'appendice sono riportati struttura del documenti ed esempi utili.

Interessante quanto afferma l'autore a proposito del profilo professionale del web designer: "Il web designer deve avere una visione complessiva che gli permetta di mediare fra le varie esigenze e di concepire la soluzione più adatta. Deve avere competenze diverse: un buon web designer è un po' esperto di comunicazione, un po' informatico, un po' architetto dell'informazione" (p. 106).

Discutibile, invece, la parte sulla progettazione dei contenuti: come si fa a progettare l'architettura informativa di un sito senza che i contenuti siano già stati progettati? Attenzione: progettati, non redatti in versione definitiva. Anche perché è necessario considerare che i contenuti non sono solo i testi. In un sito di e-commerce, contenuti altrettanto fondamentali che i testi, sono le foto degli articoli in vendita. E progettare i contenuti (ovvero definire come fotografare i prodotti, o quali immagini pronte utilizzare, e come organizzare i vari campi di una scheda prodotto, per esempio) è un'operazione che va fatta prima, proprio nella fare di progettazione generale del sito.

Altra cosa che l'Autore non considera è che i contenuti, nella maggior parte dei casi, dipendono e discendono dal committente. Grande o piccolo che sia il sito e/o il team di sviluppo, una società esterna difficilmente potrà "inventarsi" dei contenuti su un'azienda e i suoi prodotti. Potrà aiutare il committente a renderli adatti al Web, nei casi più disperati scriverli a aprtire da materiale vario o interviste realizzate ad hoc (ma questa attività autorale generalmente sula dai compiti e dalle competenze di una web agency e ha dei costi che non molti committenti sono disposti a sostenere).

Infine, un'ultima critica riguarda il concetto di Accessibilità che percorre tutto il volume: ritengo fuorviante inserire sotto l'etichetta dell'accessibilità aspetti che riguardano l'usabilità e, addirittura, l'ottimizzazione per i motori di ricerca (SEO). Se usabilità e accessibilità sono cugine, pur occupandosi di aspetti diversi, la SEO è un'area professionale completamente separata, con competenze specifiche. Inoltre, è limitante parlare di accessibilità riferendosi solo ai disabili. Buona parte dell'accessibilità (anche nella normativa italiana) tiene conto della diversità della tecnologia hardware e software a disposizione dell'utente (abile o disabile che sia). Per non dire che certi siti "alla moda" hanno caratteri tanto piccoli che risultano di difficile lettura pure per chi ci vede bene.

Bisogna aggiungere che una serie di elementi previsti nel volume, come la guida di stile, la guida editoriale e i vari prototipi, seppure di indubbia utilità, non vengono, nella pratica, realizzati in progetti di dimensioni medio-piccole, non per cattiva volontà dei progettisti, ma per banali questioni di budget. Il documento dei requisiti, invece, anche in forma ridotta, è uno sforzo che permette di risparmiare discussioni e rifacimenti, quindi utilissimo anche in progetti a budget ridotto.