Bitbull è un’azienda distribuita fin dalla sua fondazione, 

lavoriamo infatti in smart working dal 2014

. Abbiamo avuto un ufficio fisico solo per un breve periodo ma il team ha lavorato sempre principalmente da remoto.

Visto che in questo periodo molti si sono trovati a lavorare in questo modo, abbiamo pensato di condividere alcuni spunti e metodologie, sperando che possano essere utili per qualcuno che sta iniziando ora, obbligato dalla situazione attuale, ma anche generare un confronto con chi, come noi, lavora in questo modo già da un po’.

Qualche informazione sul nostro contesto: in questo momento siamo una ventina di persone, sparse per una decina di città diverse, principalmente italiane, quindi nello stesso fuso orario.
In media ogni progetto si compone di un team  di 5/7 persone, oltre al cliente (o al team del cliente) ed eventuali fornitori e collaboratori esterni.
Ci sono quindi molte informazioni che devono passare tra molte persone diverse, e come in realtà capita anche per i team non remoti, una delle difficoltà che incontriamo, è la gestione della comunicazione in modo efficace.

Gli strumenti più conosciuti e immediati quando ci si trova a lavorare da remoto sono la mail, le chat e le call o video call. E’ importante però utilizzare questi strumenti in modo responsabile, in modo che solo i messaggi veramente urgenti interrompano il flusso di lavoro degli altri e che le informazioni cruciali possano essere reperite agilmente in ogni momento e non finiscano disperse tra le mail o in lunghissime chat.

Ecco gli strumenti che utilizziamo in base al tipo di messaggio:

Comunicazioni urgenti o che richiedono di essere in real time

se ci si trovasse nello stesso ufficio sarebbe comodo portare di persona al destinatario, raggiungendolo alla scrivania.


Per questo tipo di comunicazione utilizziamo 

. Abbiamo un canale per ogni progetto in modo che solo chi lavora su quel progetto riceva aggiornamenti. Con Slack è possibile anche fare video call e condividere lo schermo con la possibilità anche di disegnare/scrivere sullo schermo condiviso.
E ovviamente il caro vecchio telefono.

Comunicazione asincrona: pianificazione e documenti di progetto

Per tutte quelle informazioni che devono essere 

condivise e consultabili ma non è necessario che abbiano immediatamente l’attenzione

 dei destinatari.
Un esempio è la pianificazione del lavoro, quindi chi deve fare cosa ed entro quando. Per questo scopo utilizziamo 

, su cui registriamo anche il tempo speso sulle singole attività ( abbiamo sviluppato ad uso interno un’

app che consente di tracciare il tempo sui task

 Redmine, è una versione grezza ma fa il suo lavoro e stiamo lavorando ad un corposo aggiornamento ).
Un altro esempio è la documentazione di progetto e gli scambi con il cliente per questa necessità invece utilizziamo Basecamp. Grazie a Basecamp, tutto quello che riguarda il progetto è raccolto in un unico luogo, organizzato per argomenti e consultabile per chi ne ha la necessità. Cerchiamo di evitare il più possibile la mail, che al contrario è molto dispersiva e rischia di escludere chi non è in copia.

Tutte le informazioni che hanno un tempo di vita più lungo, a volte sono utili per più progetti. Un esempio sono gli articoli tecnici di troubleshooting per difficoltà comuni oppure informazioni generali sul singolo progetto (i contatti del cliente, come vengono gestiti i deploy) per questo tipo di informazioni usiamo 

.  Un altro esempio sono le password di utilità e dei progetti aziendali che condividiamo con 

Un’ultima esigenza che abbiamo affrontato è stata la necessità che 

tutti avessero un’idea di cosa succede intorno a loro

, sapere in modo informale su cosa stanno lavorando gli altri, se incontrano qualche problema o se sta filando tutto liscio. Quello che in un ufficio corrisponde alle chiacchiere alla macchinetta del caffè.
Per questo abbiamo utilizzato per qualche tempo gli 

, ovvero a fine giornata ognuno racconta in poche righe qualcosa dell’ultima giornata di lavoro. Da un po’ di tempo li abbiamo abbandonati, in favore di stand up meeting (15-20 minuti) a inizio giornata, in cui ci raccontiamo molto brevemente cosa abbiamo fatto il giorno prima, su cosa stiamo per lavorare e se stiamo incontrando qualche difficoltà.

Ovviamente tutte queste buone pratiche non sostituiscono la necessità di incontrarsi di persona,
un aspetto molto importante per creare un team affiatato e unito, per questo cerchiamo di incontrarci in occasione di eventi, a volte ci incontriamo a piccoli gruppi per lavorare nello stesso posto e una volta all’anno cerchiamo di incontrarci tutti, quest’anno abbiamo passato insieme un weekend prima delle vacanze di Natale.

In conclusione la nostra esperienza di lavoro in smart working è positiva, effettivamente consente alle persone di 

risparmiare tempi e costi degli spostamenti

 e investire in modo migliore i costi risparmiati dal mantenimento di un grande ufficio, ed è una scelta che ha un 

riscontro ecologico anche per l’ambiente

, per cui ci auguriamo che venga visto con meno diffidenza e adottato sempre da più realtà.

Tutti gli strumenti e i modi di utilizzarli citati sono oggetto di continue revisioni, siamo sempre attenti a come poter migliorare il flusso di lavoro e la comunicazione, questo articolo non ha lo scopo di indicare una soluzione definitiva ma semplicemente di condividere quello che finora abbiamo provato e di cui possiamo dare un riscontro positivo.

Questo articolo è una versione ridotta e aggiorna del mio talk "Remote working: la mia esperienza in un team distribuito" tenuto al 

Smart working: La nostra esperienza

Negli ultimi mesi ho avuto occasione di lavorare ad un tema Shopify:
l’ho trovato intuitivo e ordinato e, differentemente da quanto mi era sembrato di capire prima di metterci mano, anche abbastanza flessibile.

Liquid, il linguaggio di templating di Shopify

Liquid è un linguaggio di templating in Ruby creato da Shopify.

 consente di caricare i contenuti dinamici nelle pagine degli store.
L’ho trovato davvero bello e facile da leggere come vanta il readme su Github.
Ecco un esempio preso dalla pagina di prodotto:

<ul id="products">
  {% for product in products %}
    <li>
      <h2>{{ product.name | capitalize }}</h2>
      Only {{ product.price | price }}
      {{ product.description }}
    </li>
  {% endfor %}
</ul>

 è un oggetto con attributo.<br/>
{{ product.name | 

La struttura dei file si compone di poche cartelle con un nome abbastanza esplicativo di cosa contengono :

 si trova il theme.liquid che di default è il layout base per tutte le pagine, tutti i templates presenti nella cartella “templates” vengono renderizzati all’interno di theme.liquid.

Il template corrispondente alla pagina è individuabile in base alla url, ad esempio:

/search?q={search-term} → search.liquid <br>
/products/{product-handle} → product.liquid <br>

In caso di dubbi inserendo nel codice {{ template }} verrà stampato il nome del template senza l’estensione .liquid.

Oltre ai template già presenti è possibile creare 

 per tipologie di pagine, prodotti e categorie specifiche, applicabili poi semplicemente da admin come product.shoes.liquid, page.about.liquid.

 contiene porzioni di codice customizzabili che possono essere aggiunte staticamente ( cioè da codice, come l’header e il footer) oppure dinamicamente, cioè dal pannello di controllo di Shopify, da chi gestisce il tema tramite il theme editor.

Le sezioni sono uno strumento che ho apprezzato molto perché offrono grande libertà di personalizzazione del tema e sono anche molto user-friendly per chi gestisce i contenuti del sito.

Nell’immagine sopra vediamo ad esempio una section dal nome “immagine con testo” che offre la possibilità di inserire un’immagine a tutta larghezza con un testo sovrapposto.
Il codice della section conterrà una parte in cui vengono specificate le impostazioni a disposizione dell'utente nell’editor:

{% schema %}
    "name": “Immagine con testo”
  },
  "settings": [  
    "type": "image_picker",
    "id": "image",
    “label": "Immagine"
    },
    {
      "type": “text",
      "id": "heading",
      "label": "Heading",
      "default": “Immagine con testo"  
    }  
  ]
{% endschema %}

Ed una parte con il template in liquid che mostra i settings che verranno configurati:

<div class=“feature-image”>
    {{ section.settings.image | img_url: '600x600' }}
    {% if section.settings.title != blank %}
       <h2 class="h3">{{ section.settings.title | escape }}</h2>
    {% endif %}
</div>

Lo store owner potrà scegliere se aggiungere questa section ad una pagina ( una o più volte )e per ogni istanza specificare un testo ed un’immagine differente.

 contiene parti di codice più piccole che necessitano di essere ripetute nel tema, paragonabili a partials o includes di altri linguaggi.

Qui veniamo ad un punto per certi versi dolente.<br>
Con Shopify non è possibile creare un vero e proprio ambiente locale, non esiste proprio un package di file scaricabili per replicare sulla propria macchina un ecommerce Shopify. I file del template funzionano solo se renderizzati sui server di Shopify.

Le possibilità a disposizione sono: utilizzare direttamente il theme editor (e qui vi vedo sobbalzare sulla sedia) che offre una buona visualizzazione del codice, la ricerca interna e anche un sistema di “versioning” dei file che consente di tornare a versioni precedentemente salvate;

 un tool da terminale che consente di scaricare i files del tema e caricarli ogni volta che vengono modificati sui server Shopify.
In questo modo è possibile utilizzare il proprio editor e collegare i propri file locali ad un repository per il versioning (anche se ovviamente occorrerà tenere allineato il repo con i files sul server “manualmente”).
Non poter avere un ambiente in locale è un limite soprattutto nel momento in cui più persone lavorano allo stesso tema, che può essere solo in parte aggirato se si utilizzano theme kit e un sistema versioning.

Il templating di Shopify è abbastanza intuitivo e semplice da imparare, grazie anche ad 

 ed è uno strumento che mi è sembrato molto potente e flessibile per risolvere le necessità più comuni di molti store online.

Alcuni store italiani che hanno scelto Shopify: https://it.velasca.com/, https://www.rocketbaby.it/, https://shop.woolcrossing.it/

Perchè mi è piaciuto lavorare ad un tema Shopify

Scrivo questo articolo su un argomento che non è particolarmente appassionante, né complesso, né vasto eppure ci sono inciampata almeno due volte con grande frustrazione e so per certo che non è successo solo a me. Quindi scrivo qualche riga così di sicuro non me lo dimenticherò più.

L’argomento è la cache del footer di Magento 1, dal punto di vista di un frontend developer che crede di aver a che fare con una richiesta molto semplice e malauguratamente abbassa la guardia.

L’obiettivo è mostrare un footer diverso in pagine diverse dello stesso ecommerce Magento

Insomma una richiesta che non sembra essere nulla di preoccupante.

Ecco allora che il frontend developer non esita e inserisce a colpo sicuro qualcosa del genere:

<default>
  <reference name="footer">
    <block type="cms/block" name="footer-info">
      <action method="setBlockId">
      <block_id>footer-info</block_id>
      </action>
     </block>
   </reference>
</default>

<checkout_cart_index>
  <reference name="footer">
     <remove name=”footer-info”>
  </reference>
</checkout_cart_index>

 che si vedrà in tutte le pagine e poi le modifiche al footer che servono nell’handle specifica.

Se la cache di Magento è disabilitata nessun problema

. Vi verrano a disturbare appena qualcuno la abilita.

Se invece la cache è abilitata infatti l’utente vedrà il footer in tutto il sito nel modo in cui lo visualizza la prima volta

Rischio di essere scontata e aggiungo che quindi: sono cachati anche tutti i blocchi che aggiungerete dentro a 

 e non funzionano neanche eventuali elementi dinamici che potrebbe venirvi in mente di inserire in questo blocco tipo language switcher o riepiloghi del carrello.

, cosa che si può senz’altro fare ma non ci piace molto.

Se siete frontend come chi scrive, e quindi non è il vostro mestiere riscrivere le classi, potete anche cavarvela facilmente da xml con:

Come dicevo questa soluzione non ci piace perchè, anche se magari di poco, peggiora le perfomance e ce n’è una migliore:

<reference name="footer">
 <action method="setCacheKey">
     <key>your-own-unique-cache-key</key>
 </action>
</reference>

 è l’identificativo della cache di ogni blocco, 

al blocco footer di default è associata un’unica chiave

, per questo una volta “salvata” una versione del footer con quella chiave ve lo mostra sempre uguale.

Con il metodo setCacheKey potete però specificare una chiave cache specifica per ogni blocco footer diverso da quello standard, in questo modo le performance sono salve e il vostro footer cambia come richiesto!

È una soluzione che consente teoricamente di scalare all’infinito e quindi avere un footer diverso per ogni pagina del sito, anche se in qualche caso limite ( ad esempio un footer diverso per ogni categoria su un sito con moltissime categorie ) potrebbe essere necessario ricorrere ad un rewrite per evitare di specificare tantissime cache key manualmente, ma rimangono comunque buone possibilità di cavarsela senza disturbare nessun collega backend dev.

Il footer di Magento 1 è un blocco cachato

Responsive e adaptive web design sono due approcci diversi per raggiungere lo stesso risultato: realizzare un design che possa offrire all’utente un sito che si adatta nel migliore dei modi al dispositivo che sta utilizzando.

Ci viene spesso chiesto quale sia la differenza e quale sia la scelta migliore tra queste, nelle prossime righe proviamo a fare un po’ di chiarezza.

Partiamo con l’origine dei due termini.

“Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking.” Ethan Marcotte

Il termine è stato utilizzato per la prima volta da Ethan Marcotte nel 2010 in un articolo per 

A list Apart dal titolo Responsive Web Design

limiti del gestire la versione mobile di un sito come qualcosa di completamente separato dalla versione desktop

 e dell’affidarsi allo user agent per decidere quale versione del sito servire all’utente (nel 2010 erano più diffusi rispetto ad oggi gli m.site, siti mobile con diverso url e html ora meno diffusi forse perché <a>sfavoriti nell’indicizzazione da Google</a> e più complicati da mantenere).

media query introdotte dalla specifica CSS3

, che all’epoca risultava una tecnica innovativa per far adattare un design alle dimensioni del browser con un controllo esclusivamente client-side.

“Adaptive web design,” as I use it, is about creating interfaces that adapt to the user’s capabilities (in terms of both form and function). - Aaron Gustafson

Il termine Adaptive web design invece è stato usato per la prima volta da Aaron Gustafson nel 2011 nel suo libro, 

"Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement” (

la prima versione è disponibile gratuitamente online

Gustafson utilizza il termine adaptive per descrivere la capacità di un sito di adattarsi e sfruttare le caratteristiche del device da cui viene fruito. Non solo quindi un design che si adatta alla dimensione del browser, ma che arricchisce l’esperienza d’uso rilevando le possibilità a disposizione del dispositivo. 

La definizione di adaptive è per questo strettamente legata al concetto di progressive enhancement

Questi sono gli albori delle due definizioni, come abbiamo visto però sono passati un po’ di anni, nel web tutto cambia molto velocemente, non solo le tecnologie, ma a volte anche il modo di usare certi termini. Per questa ragione ci si può imbattere in diversi articoli in cui queste due tecniche vengono presentate diversamente.

I layout responsive sono comunemente identificati dalla capacità di adattarsi in modo fluido alle diverse dimensioni del browser, mentre i layout adaptive come disponibili in diverse opzioni che “saltano” da una versione all’altra a determinati breakpoint, vedere ad esempio "

9 gifs that explain responsive design brilliantly

The difference between responsive and adaptive design

" di css-tricks.com, nei commenti dell’articolo si trova un bel confronto (per non dire flame) tra sostenitori di opinioni diverse sull’argomento.

Può capitare anche di incontrare il termine adaptive design come sinonimo dell’utilizzo di tecniche di device detection, in associazione allo sviluppo di 

Non si tratta di definizioni scorrette ma parziali, legate forse alla necessità di voler delimitare con delle indicazioni pratiche i due concetti.

“Responsive design is one technique in an adaptive web design strategy.” - Brad Frost

Brad Frost ha tirato le somme ad un po’ di anni di distanza, nell’articolo "

". Questa è la definizione che ci convince di più: 

AWD ed RWD non sono in antitesi, il responsive design è una delle soluzioni che si possono adottare per fornire una un’esperienza d’uso che si adatti al dispositivo

Dal punto di vista tecnico le opzioni sono molte e possono essere utilizzate in combinazione: possiamo avere markup e stili diversi serviti con tecniche di device detection, ma nulla vieta che siano anche dei design fluidi, oppure un layout che si affida solo a media query con dimensioni fisse. Inoltre le tecniche di device detection possono essere sia server side che client-side e possono interagire in vario modo con il layout. Non esiste un nome per identificare ogni combinazione possibile di queste tecniche e la scelta migliore va valutata caso per caso.

Per concludere un’importante riflessione relativa al concetto di adaptive web design: via via che la tecnologia rende possibile farlo, 

oltre alla dimensione dello schermo e alle feature disponibili sul dispositivo, un design davvero adaptive dovrebbe adattarsi anche all’utente e al contesto, variabili che influenzano fortemente l’utilizzo di un sito web.

 Ad esempio il design potrebbe tenere conto se viene fruito da fermi, magari seduti comodamente sul divano, piuttosto che in movimento, traballanti in piedi sul tram, se in quel momento è notte o è giorno e si sta sfruttando quel servizio da una determinata posizione geografica (per approfondimenti, è interessante il corso "

Responsive o adaptive?

, primo evento dedicato all’architettura dell’informazione e alla user experience design a Genova.

Io e Lorena abbiamo approfittato del fatto che un evento su questi temi, completamente gratuito, si tenesse a poche ore di treno da casa e abbiamo partecipato. Nelle prossime righe vi raccontiamo com’è andata.

La mattinata si è aperta con il talk di presentazione della giornata di 

, organizzatore dell’evento. Ci ha dato il benvenuto facendo chiarezza sul significato di 

, termini che negli ultimi tempi hanno conosciuto molta diffusione ma spesso vengono utilizzati in modo improprio.

 e abbiamo ripassato la definizione di user experience secondo la normativa iso 9241-210 che la definisce come 

“le percezioni e le reazioni di un utente che derivano dall’uso o dall’aspettativa d’uso di un prodotto, sistema o servizio”

. Ha poi sottolineato come non esista la user experience design senza il coinvolgimento degli utenti tramite test, interviste e sondaggi; per citare le sue parole “

fare ux senza utenti è come fare il pesto con le noci”

Ha inoltre citato molte letture interessanti su entrambi i temi tra cui: 

Information Architecture: For the Web and Beyond

Architettura dell’informazione: Trovabilità: dagli oggetti quotidiani

The Elements of User Experience: User-Centered Design for the Web and Beyond

Durante la mattinata abbiamo ascoltato due talk dei ragazzi di Niew. Il primo a proposito del “processo UX” e il secondo sullo stesso argomento applicato ad un case history.

È stato interessante conoscere la loro esperienza di lavoro perché lavorano in un contesto molto diverso da quello a cui siamo abituati in Bitbull: 

 lavora principalmente ad interfacce per software industriali per la gestione delle linee di produzione, quindi GUI molto complesse e utilizzate in condizioni particolari, infatti le linee di produzione possono essere rumorose, gli operai possono indossare guanti o altre attrezzature limitanti, ecc ecc.

Sempre nella prima parte della giornata abbiamo ascoltato 

sono profili che descrivono gli “utenti tipo”

 di un servizio e sono uno strumento utile per 

 a tutti i livelli: copywriting, scelte estetiche, funzionalità.

Sono inoltre efficaci nel rendere più trasparenti gli obiettivi e facilitare le decisioni e la comunicazione tra le varie figure del team e con il cliente. È stato uno dei talk che abbiamo apprezzato di più perchè ricco di esempi e suggerimenti pratici.

Per la pausa pranzo gli organizzatori ci hanno indicato i locali vicini e si sono occupati delle prenotazioni così abbiamo comunque avuto modo di ritrovarci con gli altri partecipanti e alcuni speaker e approfittare della pausa per conoscerci e scambiare qualche parola.

 un metodo strutturato basato sul design thinking, sul metodo agile e sul game storming. È il metodo usato da Google per analizzare e validare nuove idee in cinque giorni, ma come ha detto Francesco, per essere più appetibile per i tempi e lo stile italiano, è “rateizzabile” con successo anche con la formula un giorno a settimana per cinque settimane. Francesco utilizza questo metodo da più di un anno per raggiungere il consenso di gruppo sulle specifiche del 

. Un google design sprint consiste idealmente di 5 step della durata di una giornata ciascuno: 

 comprendere cosa vuole il cliente, non solo chiedendoglielo perchè potrebbe non saperlo o avere delle convinzioni sbagliate, ma analizzando i suoi bisogni con tutti gli attori coinvolti nel processo  (come spiega la famosa citazione di Henry Ford che disse che se avesse chiesto ai suoi clienti cosa volevano avrebbero detto “cavalli più veloci”), 

 ovvero trovare tutte le idee possibili per risolvere quanto emerso dalla prima fase, 

 cioè decidere quali idee sono buone tra quelle emerse e quali no, 

 quindi creare wireframe o prototipi per testare le idee senza grossi investimenti e infine 

Dopo Francesco Casale è stato il turno di 

 con il talk “progettare esperienza per il peggior nemico del cliente” ( 

 ). È stato un talk molto godibile per il taglio umano, molto legato alla sua esperienza in prima persona nel contesto di una grande agenzia di comunicazione, che partecipa spesso a bandi che richiedono di approcciare un nuovo progetto producendo subito demo e materiali valutabili e quindi non ha sempre la possibilità di seguire un processo ux ben strutturato.

Ha anche evidenziato diverse difficoltà che si possono incontrare nel proporre alcune tecniche di progettazione ad alcuni clienti e ha anche fornito un’analisi divertente e viva di tutte figure coinvolte nel team di un’agenzia.

Tra i consigli che abbiamo portato a casa l’importanza di verificare 

nei processi ux, di stare coinvolgendo il c-level, la persona che effettivamente prende le decisioni, pena l’inefficacia

, in cui ha presentato consigli e approfondimenti di visual design su font, immagini e colori che possono essere utili su tutti i progetti.

In conclusione il bilancio della giornata è positivo, forse avremmo voluto un paio di pause caffè più lunghe per avere modo di conoscere meglio gli altri partecipanti e fare qualche domanda agli speaker, siamo contente di aver partecipato e speriamo che a questa prima edizione UX Genova possano seguirne altre!

UX Genova 2016

Giovedì e venerdì della settimana scorsa il reparto frontend di Bitbull si è allontanato dalle tastiere per partecipare al From the Front 2016, uno dei più importanti eventi nazionali dedicati al mondo del frontend development.

The frontend guide to life, the universe, and everything”

, ispirato al libro e film The Hitchhiker’s Guide to the Galaxy (non sono mancati maglietta e stickers a tema) e si è svolta nella splendida location degli anni precedenti, il teatro Duse di Bologna.

Si sono alternati sul palco alcuni tra i 

migliori frontend dev e ux designer a livello internazionale

 che, forse complici anche le luci, il palco e le poltrone rosse del teatro, sono riusciti a rendere emozionanti argomenti tecnici.

Gli argomenti trattati sono stati molti, alcuni più strettamente frontend, altri più vicini al design, ma costante tra tutti i talk è stato il taglio più improntato a 

 piuttosto che una soluzione tecnica preconfezionata.

Tra i talk più tecnici è stato sicuramente molto apprezzato quello di Mark Robbins, che ha lasciato tutti a bocca aperta con “Modern CSS and interactive email”, in cui ci ha mostrato come sviluppare email interattive: mini giochi, una scheda prodotto di un capo di abbigliamento con selezione di taglie e colori. Addirittura le stesse slide della presentazione erano state fatte con solo html e css, sfruttando principalmente 

! ;  Meno spettacolare ma non meno interessante il talk di Hugo Giraudel sui 

un sistema per rendere lo scope delle dichiarazioni css locali anziché globali, che insieme al talk di Varya Stepanova “Doing nothing for visual regression testing”  (quello che ci ha raccontato è 

 ) ci siamo promessi di studiare una volta tornati a casa.

 e ci hanno raccontato del loro passato e delle scelte che li hanno portati a diventare quello che sono: Marc Thiele organizzatore del 

  ha parlato del cambiamento, Lyza Danger Gardner con “Everyone Else is So Clever” di come non essere sopraffatti dagli alti e bassi che si possono incontrare nella vita lavorativa, e Beth Dean con “Emotional intelligence in design”, attraverso la sua esperienza personale, ci ha ricordato la responsabilità etica e politica dei designer.

Si è parlato anche di molto altro: dall’accessibilità, ai dettagli di http/2, alla 

 e di argomenti più vicini al mondo del design e alla user experience, tra cui, molto affascinante, l’intervento di Ben Sauer "

" sul futuro delle interfacce vocali e su come cambierà il ruolo dei designer con la loro diffusione.

A conti  fatti sono stati due giorni intensi ed è stato bello esserci non solo per gli spunti e gli approfondimenti, ma anche per l’energia positiva e l’entusiasmo che a volte si trovano in questi eventi e che aiutano a ricordare come mai ci piace questo lavoro, nonostante le difficoltà quotidiane.

Purtroppo gli organizzatori hanno concluso l’evento dichiarando che questa edizione del From the Front è stata l’ultima, non possiamo che augurarci che ci ripensino oppure che qualcuno raccolga il testimone!

From the Front 2016

Per scrolling infinito si intende la scelta di mostrare tutti gli elementi di una lista nella stessa pagina, senza paginazione, mano a mano che l’utente effettua lo scroll. Esempi famosi sono il feed delle notizie su Facebook e i risultati delle ricerche di Google images.

Molti clienti ci chiedono espressamente questa soluzione per le liste di prodotti nelle pagine di categoria, probabilmente proprio perché l’hanno notata su alcuni noti social network e l’hanno trovata una forma di navigazione intuitiva e piacevole.

 che è facile notare: in particolare la naturalità del gesto, lo scrolling rispetto al tap o al click non interrompe la lettura e la navigazione, far scorrere una lista è più veloce che cliccare un link e cambiare pagina, soprattutto sui dispositivi mobile.

A livello di user experience lo scrolling infinito pesta i piedi ad alcune importanti certezze a disposizione dell’utente: la 

scrollbar del browser smette di essere un indicatore dell’effettiva lunghezza della pagina

, l’utente può solo continuare a scorrere ma non ha un’idea precisa di quale percentuale della lista abbia visualizzato fino a quel punto; 

 dopo essere entrati nel dettaglio di un elemento non sempre riporta al punto esatto della lista da cui si è usciti; il footer della pagina, dove per gli ecommerce è diventata prassi collocare informazioni importanti come le pagine con i dettagli sulle condizioni di acquisto, informazioni sulle spedizioni e pagamenti e a volte i contatti, diventa irraggiungibile.

In molti casi lo scroll infinito non consente di avere un link specifico per i vari punti della lista, cosa che impedisce di inoltrare il link ad un amico, oppure di salvare il link per consultarlo in un secondo momento.

Per quanto riguarda le performance, lo scroll infinito potrebbe appesantire significativamente la pagina e rallentare il caricamento per i device mobili o per chi non ha connessioni veloci. Inoltre è necessario anche accertarsi di svilupparlo in modo che anche i 

motori di ricerca possano accedere a tutti gli elementi della lista

Questi aspetti possono essere ridotti o eliminati tenendone conto in fase di design e sviluppo, ad esempio il footer può diventare sticky e si può fare in modo che la lista, pur usando lo scroll infinito, aggiorni la url in modo che il link di un punto specifico possa essere salvato e condiviso; tali attività, però, aumentano i tempi e i costi di sviluppo.

o scroll infinito è un tipo di navigazione che facilità l’esplorazione

, se i contenuti sono molti e l’utente non sta cercando qualcosa di specifico, quindi è più indicato per consumare informazioni, come avviene appunto nei social network; 

 o vuole confrontare più elementi, come è più probabile che accada all’utente di un e-commerce, 

 avere a disposizione strumenti di navigazione che forniscono più informazioni e maggiore controllo come 

non è possibile individuare una ricetta adatta a tutte le casistiche

: oltre le indicazioni di massima prima elencate, influiscono sulla scelta altri parametri: come la natura dei prodotti e il target di riferimento. Ad esempio un ecommerce di abbigliamento probabilmente avrà una lista di prodotti che l’utente può scorrere più velocemente rispetto ad un ecommerce di prodotti tecnici; e come elencato prima, anche le specifiche con cui è stata implementata la soluzione scelta possono cambiare di molto il risultato.

Come nella maggior parte dei casi, l’unico modo per scoprire quale soluzione soddisfa di più i propri utenti è fare test e raccogliere dati; senza questi l’unica certezza è che lo scroll infinito non è un’implementazione semplice e non rappresenta una funzionalità che migliora necessariamente la consultazione delle liste di prodotti.

Alla luce delle considerazioni fatte un buon punto di partenza potrebbe esserere iniziare a testare modifiche più semplici da implementare sulla lista prodotti e che possono dare informazioni sul comportamento degli utenti, come ad esempio il numero degli elementi per pagina, il design della paginazione o i dettagli dei prodotti mostrati nell’elenco.

Scrolling infinito o paginazione per la lista prodotti?

Le animazioni CSS che appaiono al passaggio del mouse su immagini, link ed elementi della pagina sono ormai comuni. Se ben utilizzati rendono un design curato, 

 e sono relativamente facili da realizzare.

Non è altrettanto facile declinare al meglio queste interazioni sui device che non dispongono, o non dispongono soltanto, di un mouse.

non sono ancora disponibili soluzioni completamente affidabili,

 né javascript né CSS, per rilevare che tipo di puntatore utilizza il dispositivo corrente.

è fondamentale tenere conto di come si comporterà l’interfaccia nei dispositivi touch screen, sui quali lo status over non esiste

 e si stanno diffondendo sempre più dispositivi che sono

Bitbull

Federica Villata

Articoli scritti da Federica Villata