Le pagine di un sito dinamico che ha sia una forte componente di business logic, sia dei precisi requisiti estetici e comunicativi, devono necessariamente essere sviluppate da più persone, ognuna nel proprio ambito di competenza.
Lo sviluppo contemporaneo dei due aspetti, comunicativo e funzionale, è però problematico, indipendentemente da quale linguaggio usino i programmatori e da quale software di authoring usino i web designers.
I web designers devono poter scrivere (o far scrivere dal loro software preferito) il codice HTML ed il codice CSS e devono anche poterlo modificare all’occorrenza fino a raggiungere il risultato desiderato dal cliente. I programmatori devono, d’altro canto, modificare il codice HTML creato dai web designers, per aggiungere la caratteristica di generazione dinamica dei dati a tali pagine. Le modifiche apportate dai programmatori tipicamente non vengono interpretate nel modo corretto dal software utilizzato dai web designer, il quale smette di riconoscere e di renderizzare l’intera pagina modificata dal programmatore, oppure ignora le parti che non capisce, ma, in questo caso, non risalva le modifiche in modo corretto dopo che il designer ha cambiato qualcosa puramente estetico all’interno della pagina. Tutto ciò ovviamente supponendo che il web designer non usi solamente un semplice editor di testi, cosa piuttosto rara.
Molti framework e linguaggi di sviluppo software, inoltre, semplificano la vita al programmatore, permettendogli di spezzare la pagina HTML in files più piccoli e più facilmente gestibili, per poi ottenere la pagina finale attraverso una procedura automatica di ricomoposizione delle parti, che avviene al volo durante la generazione dinamica delle pagine stesse. Se da una parte questo semplifica la vita al programmatore, dall’altra la complica infinitamente al web designer, il quale ora si trova con tanti pezzetti di files HTML, apparentemente sparsi senza filo logico (il filo logico è scritto nel codice del linguaggio usato dal programmatore, ovvero in un modo incomprensibile al web designer).
A seconda dei casi specifici, dipendenti dai software e framework usati, dalla composizione del team e dalle competenze di ognuno, ci possono essere varie soluzioni più o meno efficaci a questi problemi, ma l’unica soluzione trasversale ed applicabile indipendentemente da tutti i fattori citati ci arriva dall’oriente: «Modo migliore di evitare pugno… è di non essere li». Tradotto, il modo migliore è evitare la sovrapposizione fra il lavoro dei web designers e quello degli sviluppatori software.
Per poterla evitare, è necessario che i web designers terminino il loro lavoro prima che gli sviluppatori inizino a lavorare sull’interfaccia utente. Per potersi permettere questo lusso, è necessario prevedere i due step di sviluppo, chiarire il problema al committente e chiedergli di approvare la grafica del sito prima che questo vada online, ovvero spiegargli che da quando lui approva la grafica a quando andrà online passerà un tempo maggiore di zero, durante il quale gli sviluppatori creeranno l’interfaccia utente e durante il quale nessuna modifica all’asspetto grafica sarà più possibile. Nella realtà dei fatti poi si cerca di non essere così rigidi, ma è importante far passare il messaggio a priori.
La metodologia di sviluppo del team deve tenere conto del fatto che lo sviluppo delle pagine HTML non deve sovrapporsi, in linea temporale, allo sviluppo dell’interfaccia utente dinamica, ma deve precederla.
I web designers sviluppano quindi prima la struttura HTML delle pagine, utilizzando dati statici e fittizi per le parti che saranno in futuro generate dinamicamente. Contemporaneamente, sul lato sviluppo software, gli sviluppatori partono dal backend (come fra l’altro è normale che sia) e solo in un secondo momento, quando l’aspetto estetico è ormai stabile e deciso, lo si congela e si procede allo sviluppo della parte software che si occuperà dell’interfaccia utente.
Dopo il congelamento dell’aspetto estetico, sarà ancora possibile, per i web designers, apportare qualsiasi modifica essi vogliano ai files CSS, ma non sarà più possibile per loro modificare autonomamente i files HTML. Qualsiasi modifica ai files HTML, dopo il congelamento, dovrà essere fatta dal team di sviluppo software su indicazione dei designers e, in caso di modifiche strutturali, potrebbe comportare il rifacimento di parte del lavoro di sviluppo software per l’interfaccia utente eventualmente già svolto.
Tutto questo deve essere tenuto in debita considerazione nel pianificare i lavori, nel prevedere le date di consegna, nell’anticipare al cliente gli step di produzione del sito ed in generale nel costruire un diagramma di Gantt il più possibile fedele al progetto che si sta facendo.
Va bene, direte voi, ma in che modo questa soluzione sarebbe migliore di altre? Beh, il meglio ed il peggio sono concetti soggettivi, ma a favore di questa soluzione c’è una minor dipendenza da variabili aleatorie che, per quanto aleatorie, giocano sempre a nostro sfavore, e fanno immancabilmente slittare in avanti la data di consegna. In pratica questa soluzione ha il grande vantaggio di permetterci di dire subito al cliente una data di consegna che più probabilmente riusciremo a rispettare. Cliente soddisfatto.