Il buon design web reattivo, per sua natura, passa inosservato a coloro che consumano contenuti online. Quindi, quando qualcuno chiede un nuovo sito web, è spesso inconsapevole del concetto, nonostante lo sperimenta quotidianamente. Eppure, la progettazione di siti Web reattivi è ora riconosciuta come pratica standard in tutto il settore.
Costruire siti Web reattivi ha alterato i nostri processi, dalla creazione di prototipi di pagine complete, alla creazione di librerie di componenti e layout riutilizzabili.
il layout è guidato dal contenuto e gli stili sono brand-driven
Recentemente siamo stati contattati da un cliente esistente per ridisegnare responsabilmente il loro sito web. In precedenza avevamo lavorato con loro usando un processo a cascata rigida. Passando a un flusso di lavoro agile, siamo stati in grado di abbracciare il cambiamento in qualsiasi momento del progetto.
Durante tutto il processo abbiamo aderito alla filosofia secondo cui il layout è guidato dal contenuto e gli stili sono basati sul brand.
I documenti delle specifiche funzionano perfettamente per elencare tutte le funzionalità che un sito deve avere. Ma è davvero ciò di cui ha bisogno il cliente? È molto difficile visualizzare queste funzionalità sul posto. Quindi il risultato è che i documenti delle specifiche spesso si trasformano in liste di desideri gonfiate. Ciò non aiuta il cliente, i progettisti o il sito web finale.
Invece di documenti di specifiche, abbiamo optato per l'uso di wireframe. Il primo passo del progetto consisteva nella creazione di wireframe per ogni pagina. Questo potrebbe sembrare eccessivo, ma i wireframe hanno portato a discussioni iniziali sul contenuto e le funzionalità per ogni pagina. Abbiamo scoperto che le funzionalità che non abbiamo mai considerato prima sono state aggiunte, mentre molte sono state rimosse.
I wireframe ci hanno fornito una rappresentazione chiara e visiva di come il contenuto e la funzionalità dovrebbero essere priorizzati in ogni pagina. Questi wireframe diventarono quindi un punto di riferimento, sostituendo un documento di specifiche.
Key takeaway: la produzione di wireframe al posto di documenti di specifiche mette a fuoco tutti sulle funzionalità principali e sull'importanza del contenuto.
Il controllo dei wireframe ci consente di formare un elenco di tutti i componenti comuni. In un singolo sito ci saranno decine di piccole sezioni su ogni pagina che sono molto simili. Questi componenti possono essere raccolti in un elenco esaustivo che verrà utilizzato in seguito.
Questa fase ha tre vantaggi principali:
Key takeaway: pianificare come affrontare lo sviluppo front-end di un progetto è importante per creare una base di codice snella e manutenibile.
Le librerie di modelli sono una raccolta di elementi comuni utilizzati su un sito web. Concentrando lo sviluppo front-end sulla creazione di componenti che non dipendono dalle pagine, possiamo ridurre il sovraccarico del codice e migliorare la coerenza.
Utilizzando l'elenco di componenti che abbiamo raccolto durante la fase di auditing, siamo in grado di strutturare il nostro Sass in una raccolta gestibile di file.
Abbiamo utilizzato librerie di pattern su alcuni progetti, ma abbiamo sempre faticato con le convenzioni di denominazione, in particolare la struttura delle cartelle: dove metti i tuoi stili per questo lettore musicale, in componenti o in partial?
Precedentemente, usavamo la terminologia come partial e componenti per organizzare i nostri file Sass. Mentre queste sembrano convenzioni di denominazione completamente legittime, sono aperte all'interpretazione. Quando ci sono più sviluppatori che lavorano su un progetto, lasciare l'organizzazione della base di codice aperta all'interpretazione porta a CSS non organizzati.
BEM (Block, Element, Modifier), ci fornisce una convenzione comune da seguire e crea una comprensione tra gli sviluppatori front-end. La vecchia via era lasciata ai singoli sviluppatori di inventare nomi di classe che fossero tutti di livello troppo alto per ricavarne un significato. Fortunatamente siamo stati fortunati a vedere Brad Frost parla della sua libreria di modelli al Conferenza anticipata a Manchester. Pattern Lab presta la terminologia dalla chimica per descrivere i componenti che compongono la libreria. L'uso di atomi, molecole e organismi per descrivere le differenze tra i componenti di una pagina aiuta a spiegare il concetto agli sviluppatori che non conoscono il progetto.
Il design atomico è per le interfacce utente: http://t.co/eEZSYeK5VF Puoi applicare design atomico a qualsiasi interfaccia utente, come Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10 luglio 2015
In natura, gli atomi sono la denominazione più piccola (a meno che non scendiamo in quark ed elettroni). Nello sviluppo web, gli atomi sono gli elementi base dell'HTML. A tutti gli effetti non fanno molto da soli. Questi includono intestazioni, paragrafi, input, pulsanti, elenchi ... Hai l'idea.
Questi sono il prossimo livello. In chimica, le molecole sono costituite da atomi e lo stesso vale per la struttura dei CSS. Le molecole sono componenti sul sito Web che utilizzano gli atomi per formarli.
Un buon esempio di una molecola è una casella di ricerca. Questo contiene 3 atomi: un'etichetta, un input e un pulsante. Lo strato molecolare inizia a formare alcuni degli elementi che possiamo usare sul sito web. È importante rendere tutte queste molecole scalabili. Dovrebbero essere progettati con l'idea che potrebbero essere utilizzati ovunque sul sito. Il nostro obiettivo finale è rendere il CSS flessibile e riutilizzabile il più possibile.
Come suggerisce il nome, gli organismi sono raggruppamenti di molecole. Alcuni esempi di questi includono un'intestazione, un piè di pagina o un elenco di prodotti.
Se prendiamo l'esempio di un'intestazione, ciò include un logo, una ricerca e una navigazione. Questi sono stati tutti creati come molecole e sono combinati per formare un organismo di testa.
È qui che finisce l'analogia biochimica. Come dice Brad, "entra nel linguaggio che ha più senso per i clienti e il risultato finale" . I modelli sono la colla di un sito web. Questi combinano tutti gli organismi che abbiamo creato in un layout che può essere applicato a una pagina sul sito web.
Un esempio potrebbe essere un elenco di blog. Questo modello include un'intestazione, un piè di pagina, un elenco di articoli del blog e una barra laterale. I modelli sono generalmente strutturali, contenenti solo il layout.
La sezione finale è pagine. Qui è dove puoi testare i modelli con dati reali. Le pagine sono istanze specifiche di un modello. Questa parte è importante perché ci permette di vedere quanto successo hanno avuto gli atomi, le molecole, gli organismi e i modelli.
È inevitabile che quando si costruisce il sito Web, alcuni scenari saranno persi. L'esempio classico è di titoli lunghi, o di catering per diverse valute e lingue.
Key takeaway: le convenzioni sulle denominazioni sono importanti. La stratificazione CSS crea una base di codice pulita per lavorare da quella che è la più piccola possibile.
Progettare modelli è difficile. Non è possibile progettare un modello isolato come una notizia e aspettarsi che si adatti al resto della pagina. Il modo in cui costruiamo i siti web e il modo in cui li progettiamo differiscono.
È probabile che i design cambino a prescindere dal fatto che si ottenga il sign-off ... La firma è diventata un passaggio irrilevante nel processo che ha solo messo pressione su entrambi i lati
Abbiamo utilizzato Photoshop per creare prototipi di wireframe con questi componenti in stile. Una volta soddisfatti dell'aspetto e della struttura dei disegni, ci siamo spostati sull'isolamento di ciascun componente. Questo ci ha permesso di garantire che ogni componente fosse abbastanza flessibile da funzionare ovunque sul sito web.
Eravamo molto consapevoli di non ottenere il consenso su alcun lavoro di progettazione. La firma del progetto crea una barriera in cui il progettista si sente pressato a creare qualcosa che sarà incastonato nella pietra. È probabile che i disegni cambino a prescindere dal fatto che ci sia o meno un accordo. Generalmente siamo lieti di accogliere eventuali modifiche in qualsiasi momento nella tempistica del progetto. La firma è diventata un passo irrilevante nel processo che ha solo messo sotto pressione le due parti a scapito della relazione.
Sapere quando spostarsi da Photoshop al codice è importante. Questo passaggio è molto prima di quanto eravamo abituati per due motivi:
Invece di dedicare più tempo a Photoshop, abbiamo deciso di investire il tempo in codice. Se dovessimo perfezionare qualcosa, dovrebbe essere il codice, il bit che verrà effettivamente utilizzato e visto da tutti gli utenti del sito web. Per noi, Photoshop era uno strumento per creare uno stile di progettazione che potesse essere utilizzato attraverso il sito web.
Il design è molto più sulla collaborazione tra tutti i membri del team. I prototipi erano ancora una parte molto importante del processo, aiutando il cliente a visualizzare come sarebbe il sito. Se fossimo tutti contenti della direzione generale del progetto, lo porteremmo al codice. Abbiamo raramente passato del tempo andando avanti e indietro a fare ammenda ai documenti di Photoshop.
Key takeaway: Photoshop è un ottimo strumento per creare concetti di design. Passare al codice il prima possibile è importante. Perfetto nel codice, non in Photoshop.
La bellezza di questo flusso di lavoro è che ci sono così tanti posti per rivedere e migliorare il sito web.
È importante notare che si tratta di passaggi lenti nel nostro processo di progetto. Se abbiamo bisogno di qualcosa di nuovo durante il progetto, generalmente lo tratteremo come componente autonomo e modulare che può essere inserito nel sito Web e adottare il tema di design del sito.
Ognuno di questi passaggi offre un punto in cui possiamo esaminare il nostro lavoro finora. Permette anche una nuova serie di occhi per vedere le cose da una prospettiva diversa.
Durante una di queste fasi potremmo scoprire che alcune parti non funzionano come previsto. Questo va bene. In effetti va bene. Cogliere l'usabilità precoce è la chiave per un sito web di successo. Tornando indietro e incorniciando queste parti del sito Web, il progetto migliorerà quando verrà pubblicato.
Key takeaway: non aver paura di tornare all'inizio se qualcosa deve migliorare. Coglierli presto renderà il progetto migliore quando andrà in diretta.
Abbiamo passato giorni a lavorare insieme per garantire che ogni parte del sito Web fosse finita con uno standard elevato. Abbiamo testato quanti più scenari possibili, assicurando che l'esperienza di navigazione fosse coerente.
Una volta che i dati sono nel sito Web, siamo in grado di testare completamente il sito web. Spesso è troppo facile impostare un progetto dal vivo senza eseguire test completi. Possiamo verificare la velocità, la facilità di navigazione e, soprattutto, il flusso di acquisto.
Tutti citano Apple per essere perfezionisti, ma sono sicuro che i loro primi tentativi erano tutt'altro che perfetti. Ci vuole tempo e dedizione per fare quei miglioramenti finali per darci i prodotti che amiamo oggi. Utilizzando il nostro laboratorio per dispositivi, che include la maggior parte dei dispositivi e delle piattaforme più diffuse, siamo stati in grado di garantire che l'esperienza fosse ottimizzata su quante più piattaforme e schermi possibili.
Imparare da ciascun progetto è importante per poter migliorare continuamente i processi che portano a siti Web migliori.
Questo progetto ha visto la nascita della nostra libreria di modelli interna che incoraggia la coerenza tra i progetti. Quando lavoriamo in un'agenzia, potremmo avere decine di progetti attualmente in fase di sviluppo contemporaneamente. La possibilità per chiunque di lavorare su qualsiasi progetto è importante.
Creare una base su cui tutti possiamo lavorare aiuterà a contribuire a questo obiettivo.
La performance del sito Web è stata considerata solo verso la fine del progetto. Un sito web responsive di successo deve essere snello e veloce. La vasta gamma di dispositivi e le loro funzionalità variano enormemente dai nuovi computer Mac ai vecchi smartphone. Quando si costruisce un sito Web ricco di contenuti multimediali può essere molto difficile gestire le prestazioni, specialmente quando si tenta di migliorarlo retroattivamente.
Alla conferenza di Upfront a Manchester, abbiamo visto Yesenia Perez Cruz parlare di considerare le prestazioni in ogni fase di un progetto, incluso il design. Con il senno di poi, questo è qualcosa che dovremmo avere implementato. Come team di più designer, sviluppatori e sviluppatori front-end, la gestione delle dimensioni e delle prestazioni complessive (in particolare le prestazioni percepite) avrebbe dovuto essere una priorità più grande.
Tutto in una pagina ha un costo per le prestazioni. La priorità di ciò che è importante garantisce che il sito Web non sia solo veloce, ma accessibile a più dispositivi. Su alcuni dispositivi meno recenti, abbiamo riscontrato che il sito Web non si arrestava solo nel browser, ma nell'intero dispositivo. Cercare di velocizzare il sito web in modo retroattivo significava che non avremmo potuto rendere il sito web quanto più veloce avrebbe potuto essere.
La prossima volta faremo in modo che le prestazioni siano radicate in ogni fase del processo, quindi non è un ripensamento.