Che significa pixel perfect? Nel gergo del design e dello sviluppo frontend viene chiamata pixel perfect una pagina web realizzata in maniera perfettamente identica (al pixel appunto) alla grafica fornita dal progettista.
Lo dico o non lo dico?
Beh, lo dico. Quest'espressione non mi ha mai convinto molto. "Ti farò un lavoro pixel perfect" o "voglio un risultato pixel perfect" o persino con delle percentuali: "pixel perfect all'80%". Di solito a queste richieste rispondo senza esitare: "Certo, avrà il suo 80% di pixel perfect. Sono 82%. Che faccio, lascio?".
Ma dato che siamo tra di noi lo posso dire senza timore: il pixel perfect è una cagata pazzesca.
E' finita l'era del tubo catodico
Oggi sia il designer che lo sviluppatore si trovano alle prese con una quantità di dispositivi fino a pochi anni fa inimmaginabile: diverse le dimensioni, diverse le risoluzioni, diverse le tecnologie supportate. Una pagina web non può essere identica su tutti dispositivi e nessun designer umano è in grado di produrre tanti psd quanti sono gli schermi esistenti. Anche se potesse, non potrebbe replicare tutte le interazioni possibili su ciascuno di questi schermi.
Un enorme spreco di tempo
Anche un orologio rotto due volte al giorno segna l'ora esatta. Poniamo che la nostra pagina sia identica alle due/tre risoluzioni per le quali è stata disegnata. Quanto tempo c'è voluto? Prima il grafico ha disegnato tutto il sito almeno per desktop, tablet e mobile. Se è una piattaforma complessa avrà disegnato tante pagine, come si può calcolare l'80% di pixel perfect se non c'è il psd della pagina di recupero password?
Ma non basta. Ogni psd contiene livelli differenti per stati differenti della pagina: carrello vuoto, carrello pieno, che succede quando il carrello è pieno ma ha molti oggetti? e quando ne ha pochi?. Un designer esperto può prevedere queste casistiche ma disegnarle tutte in modo da permettere l'agognato pixel perfect è oltremodo oneroso. Nella nostra storia poniamo di avere un grafico espertissimo con molto tempo libero che ha effettivamente prodotto 5G di psd. Bene, le grafiche sono passate allo sviluppatore che con molta pazienza si è messo a misurare tutti gli elementi, tutte le interlinee e infine, pagina per pagina, ha realizzato il nostro sito pixel perfect su tre dispositivi.
La risposta alla domanda quanto tempo c'è voluto la lascio a voi ricordandovi che il tempo ha un costo, un costo elevato.
Beh dai, il cliente sarà contento
Eh no, purtroppo nemmeno quello. Un psd non è una pagina web e quasi mai soddisfa al 100% le aspettative del committente. Non è colpa né del grafico né del cliente, ma state sicuri che nel momento in cui il disegno diventa realtà sopraggiungeranno un'infinità di nuove esigenze: i contenuti, le immagini, la SEO, le interazioni, i dispositivi fino a questo momento non considerati. E se l'utente stringe la finestra? che ne sarà di tutti quegli elementi incastrati tra di loro al pixel?
Insomma arrivati a questo punto ci vuole ancora altro tempo sia del grafico che dello sviluppatore, altro tempo significa altri soldi. Ehi! non avremo finito il budget vero?
Alternative?
Partiamo dal presupposto che la messa online della pagina stilata non è la fine del lavoro ma l'inizio, l'ideale sarebbe arrivare a pubblicare uno staging quando sia il grafico che lo sviluppatore hanno investito ancora poco tempo sul progetto.
Un buon modo potrebbe essere iniziare la parte di sviluppo quando è stata disegnata solo una style guide fatta di poche pagine e tutti gli elementi della GUI. A questo punto si potrebbe portare in staging un prototipo realizzato velocemente ma completo, su cui si possa già fare data entry e che sia il punto di partenza per una nuova fase di progettazione che veda coinvolti non solo il grafico ma anche il cliente, il SEO e chi si occupa del marketing.
Se non si ragiona su un psd ma su un'applicazione reale con contenuti reali su dispositivi reali, verranno fuori tutte le esigenze più concrete del progetto: posizionamento, usabilità, esigenze di navigazione.. altro che misurare al pixel un elemento che magari nella versione finale non ci sarà più o sarà completamente stravolto.
C'è da dire che un approccio del genere pone dei problemi in fase di preventivo. Come si può quantificare un lavoro se non si hanno dall'inizio tutte le informazioni? Beh su questo non ho risposte certe. Probabilmente anche il preventivo dovrà essere diviso in porzioni più piccole, una per ciascuna fase del lavoro.
Ops! senza volerlo ho parlato un pò di agile.
Commenta
Commenta con Facebook
