CBC – Conservazione Beni Culturali… Digitali

Imke Bähr
Introduzione
di Imke Bähr

Il Co-design Workshop come strumento di conoscenza

Imke Bähr
di Imke Bähr

Il Processo di Design: dalle Interviste all’Information Architecture

Imke Bähr
di Genni Piccirilli

Bedrock, la nostra salsa per WordPress

Imke Bähr
di Carlo Frinolli
di lettura
Introduzione
CBC – Conservazione Beni Culturali… Digitali

La bellissima esperienza con CBC ci ha consentito di pensare e costruire uno spazio per trasmettere davvero valori e professionalità, tramite approfondimenti sulle diverse attività di lavoro, studio e didattica, con informazioni sulle pubblicazioni e collegamenti con il mondo dell’arte.

La CBC Conservazione Beni Culturali è una cooperativa nata nel 1977, che ha affrontato opere di restauro veramente importanti, spaziando dal singolo capolavoro alla conservazione e manutenzione di intere collezioni museali. Tra le imprese maggiormente prestigiose si possono indicare, solo a titolo di esempio, la Fontana di Trevi e la Torre di Pisa, la Fornarina di Raffaello e il Narciso di Caravaggio.

A 40 anni dalla sua nascita ha intrapreso un percorso di profondo rinnovamento, per essere in condizione di ascoltare e recepire le nuove sfide del settore: nel farlo ha deciso di affidarsi a nois3 con un progetto di riorganizzazione particolarmente attento alla comunicazione digitale.

Il sito CBC – Conservazione Beni Culturali è online

Il risultato è la nuova piattaforma web www.cbccoop.it, frutto di un lungo e ricco percorso di design partecipato tra vecchio e nuovo CdA.

 

SaveSaveSaveSave

Capitolo 1
CBC – Conservazione Beni Culturali… Digitali

Il Co-design Workshop come strumento di conoscenza

Le fasi del Co-Design Discovery Workshop

Ogni cliente e progetto ha la sua storia, i suoi valori e le sue specificità. Ogni Discovery Workshop viene quindi strutturato in base alle esigenze progettuali. Il comune denominatore è la pratica di co-design o design collaborativo che è l’insieme delle strategie e delle azioni mirate a coinvolgere gli utenti finali e/o gli stakeholders nella fase di generazione di idee e di progettazione di un concept.

Nel workshop di co-design raccogliamo informazioni per integrare il brief e comprendere il flusso lavorativo del cliente. Include una fase di discovery per la Information Architecture del sito e la raccolta delle informazioni su utenti e stakeholder.

Le attività sono caratterizzate da momenti in cui chiediamo ai partecipanti di svolgere alcuni compiti facilitati dai nostri trainer che hanno lo scopo di sostituire e ampliare il concetto del kick-off meeting iniziale.
Generalmente strutturiamo questo workshop con un’attività di ice-breaking per conoscere meglio tutte le persone che vi partecipano, per poi proseguire con le attività che ci aiutano a capire la direzione che vuole prendere il cliente e le minacce che lo bloccano nel cammino. Infine cerchiamo di affrontare la Value Proposition del cliente per capirne sia tagli comunicativi che elementi caratterizzanti. Queste attività, per quanto possano sembrare spiazzanti, ci raccontano molto meglio il valore del servizio del Cliente che dobbiamo poi riflettere all’interno del progetto su cui ci coinvolge, sia esso un sito, un app o un servizio.

Da Ice-Breaking e Decision Making al prototipo, insieme.

Le attività che proponiamo sono strutturate in modo da poter mettere a dialogare tutti i partecipanti del workshop in modo da poterli trasformare da committenti a co-autoride tra loro  diverse tra ice-breaking, brainstorming, fasi divergenti, fasi convergenti, decision making e così via fino alla prototipazione.

Qui vi riportiamo alcuni esempi:

Opinion inventory

Aprite i microfoni e parlate di impressioni e idee.

La ricchezza di ogni progetto, brand o azienda sta nelle persone che lo rendono possibile. Ascoltare le loro idee, impressioni ed esperienze, o semplicemente sapere come si sentono all’inizio della giornata del workshop, è il primo passo per conoscere le basi del progetto, individuare opportunità ed immaginarsi il futuro possibile.

Cover Story

Immaginate un futuro glorioso, qual è la vostra idea di successo?

Un esercizio di visione, per cercare di capire cosa intende con successo il Cliente. Un’attività spesso divertente che mostra inequivocabilmente l’attitudine di proiettarsi nel proprio futuro e la capacità di visione sul proprio business.

Se fosse una persona? Brand Persona Map

Provate a immaginare il vostro Brand come fosse una persona, che tipo di persona sarebbe?

Efficace esercizio per provare a dare un volto, un tono di voce, un comportamento e delle caratteristiche antropomorfe al proprio Brand, così da poter capire molte cose: dal Look & Feel, al Tone Of Voice, fino al tipo di valori per cui può essere distinto il Cliente rispetto ai suoi competitor.

Co-Design Ghosts & Values

Un classico, ripreso da PAC-MAN in chiave SWOT.

In un momento di condivisione dei punti di forza e debolezza emergono spesso elementi delicati da cui partire per porre rimedio a debolezze più o meno strutturali o per esaltare caratteristiche vincenti. È per questo che abbiamo adottato la denominazione Fantasmi e Valori, come in Pac-Man.

The Airplane

Uno sguardo sinottico sul Cliente e sul suo progetto.

Spesso bisogna riordinare le idee e dare un contesto completo in questo tipo di Workshop. Per questo abbiamo adottato questo gioco: perché ci permette di riproporre alcuni temi, valori, fantasmi e caratteristiche, unitamente a quel che dà forza, quel che zavorra e agli obiettivi del Cliente stesso.

UX Personas’ Draft

Far emergere archetipi di utenti grazie alla discussione.

Solo conoscendo bene il proprio target, si possono sviluppare strumenti e strategie di comunicazione adeguati e funzionanti. Questa fase ci sarà utile per fare delle ipotesi sulle aspettative dei nostri utenti e stakeholder per strutturare le esigenze comunicative sotto forma di archetipi, importanti per poter validare le scelte progettuali ricordandoci che il target è fatto da persone, che saranno poi validate tramite interviste utente più avanti.

Use Cases, User Stories & Carpaccio

Dīvide et Īmpera.

Ogni task che compiamo può essere spezzettato in task più piccoli e significativi. In questa fase individueremo i macrotask (epici) che serviranno per sviluppare il sito web e li divideremo in unità più piccole e quindi più affrontabili nella progettazione di UX, quindi visiva e poi implementativa.

IA Analysis & Card Sorting

Riorganizzare il contenuto insieme.

Mischiare le carte, per distribuirle al meglio. Possiamo descrivere così questa fase progettuale: costruire insieme un momento in cui si prenda davvero in mano tutto il contenuto del progetto per poi cominciare a ristrutturarlo significativamente. L’attività di cardsorting rivede l’attuale struttura analizzandola e ristrutturandola in base alle nuove esigenze communicative e rispettando i standard per poter poi migliorare la SEO del sito.

Customer&User Journey Blueprint

Think outside the [device screen] box.

Spesso la cosa più difficile è capire cosa succede prima e dopo che un ipotetico utente del sito si metta davanti allo schermo per navigare o usufruire di un servizio digitale. E invece la quotidianità si è trasformata in ultimi anni in tal modo che capire se la persona ha bisogno di un’informazione in mezzo alla strada di una città con uno smartphone in mano, seduto in poltrona di casa con un tablet o in ufficio in sala riunioni diventa fondamentale per strutturare e indirizzare correttamente lo user flow in contesti diversi. Capire quali possono essere le barriere che possono costringere una persona ad abbandonare l’uso del nostro prodotto in determinate situazioni indipendenti dal digitale, come anche una banele assenza di connessione internet o le mani occupate durante la guida di un’auto, ci può aiutare a capire le giuste leve motivazionali e stimoli che possono essere in grado di convincere l’utente ad usarli con soddisfazione e piacere.

Brainstorming sulle strategie di marketing e comunicazione

Azioni mirate per lanciare il progetto.

Tramite pratiche di gamestorming e co-design esploreremo idee e soluzioni progettuali per realizzare una campagna di comunicazione e di promozione per lanciare il progetto.

I requisiti “tecnici” per un workshop di co-design

Quanto tempo richiede un co-design workshop

La durata di un workshop di co-design può variare in base alla complessità del progetto.

Nella maggioranza dei casi si parte con un co-design workshop di una giornata di 6-7 ore. A seguito di un report che viene consegnato al cliente si valuta sucessivamente una seconda sessione per approfondire o verificare gli insight raccolti, indagare meglio eventuali nuove esigenze o problematiche emerse.

Gli spazi e l’attrezzatura per co-progettare

In genere ci basta un’aula che può ospitare liberamente tutti i partecipanti dotata di sedie, scrivanie, almeno una parete libera dove possiamo attaccare i diversi schemi e post-it e uno schermo sufficientemente grande dove possiamo far vedere alcune presentazioni di istruzioni per svolgere gli esercizi oppure dove possiamo vedere insieme dei siti o altri materiali utili per stimolare la discussione creativa e propositiva.

Perché proponiamo co-design workshop ai nostri clienti

Siamo specializzati in Human Centered Design; al centro del nostro lavoro sono gli utenti visti come persone prima di tutto. Co-creiamo con loro la giusta esperienza utente (UX – User Experience) per poter realizzare interfacce (UI – User Interface) che siano funzionali, usabili ed engaging. Troviamo una strategia per trasformare i bisogni in soluzioni innovative che abbattono le barriere della vita reale attraverso gli strumenti e canali digitali.
Solo partendo dalla comprensione delle reali necessità del cliente e dei suoi utenti riusciamo a sviluppare progetti che soddisfano i bisogno di tutti i stakeholder e quindi vi consegneremo un progetto che incontra appieno le vostre esigenze.

Sei interessato ad un workshop di co-design? Contattaci!

Capitolo 2
CBC – Conservazione Beni Culturali… Digitali

Il Processo di Design: dalle Interviste all’Information Architecture

La nostra mission è progettare servizi e prodotti digitali efficaci, usabili e accessibili sulla base di un approccio HCD (Human-Centered Design) che pone al centro l’utente, le sue motivazioni, le esperienze cognitive, i suoi valori e soprattutto le sue emozioni. Partiamo sempre dal processo di Co-Design come metodo strategico per ascoltare, osservare, discutere e indagare tutti gli attori di un progetto e il contesto in cui agiscono perché è il valore creativo e partecipativo del workshop che ci permette di realizzare soluzioni non solo compatibili, ma anche soddisfacenti per gli utenti finali.

Con CBC Conservazione Beni Culturali abbiamo fatto questo percorso, costruendo uno spazio che ha fatto coincidere i bisogni reali dell’impresa con le aspettative dei suoi utenti.

Le Interviste

Prima del workshop abbiamo effettuato delle interviste, sia scritte che video registrate, per conoscere meglio tutti i soci e dare loro voce, per definire una base per il percorso di progettazione da intraprendere. Dopo aver raccolto molte indicazioni e feedback qualitativi, sono emersi molti elementi comuni, come la curiosità e le soddisfazioni continue per il loro lavoro e la loro volontà di rilanciarsi, riemergere e rinnovarsi all’interno del loro settore con grande entusiasmo.

Le attività del Discovery Co-Design Workshop

Facilitazione della comprensione del Brand

Siamo partiti dalla personificazione del Brand per arrivare all’idea di successo di CBC: una cooperativa consolidata, con quarant’anni di esperienza nel campo del restauro, i cui valori distintivi sono la metodologia, l’etica, la professionalità, la formazione e la collaborazione tra i soci.

Definire l’idea di successo

Attraverso il Cover Story Game abbiamo cercato di liberare la fantasia e tirare fuori la vision aziendale per dirigersi verso l’idea di successo. Lo scopo è riconoscere i sogni e le ambizioni che accomunano le persone all’interno dell’azienda ignorando i limiti e immaginando quello che potrebbe accadere: ne è emersa l’illustrazione di un albero in cui le radici rappresentano la CBC, il fusto il mondo dell’arte e le ramificazioni sono i luoghi e le persone che hanno raggiunto.
La CBC si presenta come cooperativa capace di lavorare per qualsiasi commessa perché ormai un gruppo consolidato e capace di affrontare qualsiasi sfida, considerati trasmettitori di conoscenza in grado di offrire diversi servizi come la formazione, l’educazione, la valorizzazione e conservazione del patrimonio culturale.

Capire i propri ostacoli

Speedboat è un gioco che ci ha aiutati ad individuare e tirare fuori gli ostacoli che possono impedire il successo della CBC che sono stati riscontrati nell’adottare una giusta strategia d’impresa e nel metodo di lavoro. Pianificare e misurare i risultati ma soprattutto attuare un ricambio generazionale potrà portare la cooperativa al superamento delle proprie difficoltà, al miglioramento e alla crescita aziendale.

Adottare alcune tecniche di facilitazione durante il Discovery Workshop, ha permesso alla CBC non solo di attuare un cambiamento al suo interno, ma di rilanciare la cooperativa al fine di essere più competitivi con il mercato attuale e continuare a promuovere l’attività e i valori di restauro in Italia e all’estero.

Al termine del co-design workshop, abbiamo prodotto dei documenti co-creati che descrivono visivamente e verbalmente il processo seguito e, successivamente, è iniziata la fase di benchmark che ci ha consentito di analizzare l’offerta presente sul mercato, raccogliere spunti e individuare delle best practice e insight per la progettazione.

Personas & User Story

Abbiamo creato degli archetipi di clienti, partner e stakeholder principali con i quali interagisce e comunica la cooperativa: le Personas. Rappresentare i bisogni, le aspirazioni e i comportamenti di un particolare segmento di utenti reali (che abbiamo individuato in: uno studente di restauro, un funzionario di un ente pubblico e privato, un giornalista di settore, una restauratrice) ci ha aiutato ad avvicinarci alle loro reali necessità, per la ricerca di soluzioni progettuali adeguate.

Per facilitare ulteriormente un progressivo e costante miglioramento del prodotto offerto, abbiamo ipotizzato delle User Story. Diversi contesti e scenari di utilizzo ed interazioni utente attraverso la formula:

– come (tipo di utente)

– vorrei (azioni che l’utente desidera compiere)

– così da (specificare motivazioni)

Il risultato è una proposizione come questa:

“Come studente di restauro, vorrei capire tutti i metodi e le tecniche utilizzate da CBC così da poter approfondire la mia conoscenza in materia e capire se fosse possibile fare un tirocinio”.

Information Architecture

Prima di passare al mood grafico, abbiamo attuato il processo di categorizzazione: aggregare i contenuti in gruppi sensati, per poi ritrovarli (o consentire agli altri di farlo) con facilità, usando logiche intuitive.
Attraverso l’architettura dell’informazione abbiamo cercato di individuare un modello unificato capace di racchiudere i diversi contesti dell’agire quotidiano dell’utente in cui la catalogazione e l’organizzazione delle informazioni appare subito chiara. Un sito, quello di CBC, fatto di correlazioni in cui l’utente, attraverso specifiche CTA (call to action) puo’ approfondire i diversi contenuti.

Capitolo 3
CBC – Conservazione Beni Culturali… Digitali

Bedrock, la nostra salsa per WordPress

È un software le cui linee guida di sviluppo sono piuttosto lasche e permette di fare “porcherie” facilmente. Ma poi…

Era metà del 2014.

All’ennesimo progetto aperto con WordPress in cui cercavo un modo furbo per non dover committare tutto il suo core dentro il repository Git e combattevo con la possibilità di deployare in maniera furba i nostri progetti, mi imbatto in questo sito. Giuro, appena visto quasi piango.

Il suo nome richiama alla famiglia Flintstones e la cosa mi garbava. Ma facciamo un passo indietro.

I problemi più comuni prima di Bedrock

Cominciare un nuovo progetto con WordPress vanilla aveva il difetto di dover ripetere molte volte lo stesso tipo di operazioni: ad esempio utilizzando serialmente plugin base comuni a molti progetti – sia benedetto Advanced Custom Field Pro, ma di questo parlerò un’altra volta – ci trovavamo sempre a copia-incollare centinaia di file. Non avevamo trovato (ancora) un modo furbo per gestire le dipendenze sui plugin.

Inoltre avere degli ambienti di sviluppo locale, staging e produzione implicava avere in .gitignore il file wp-config.php (ovvero quello in cui ci sono le configurazioni di connessione al db).
Infine l’aggiornamento di plugin e core avveniva sempre pericolosamente.

Visto che core e plugin risultavano sotto versionamento, la possibilità di incorrere in conflitti e altre gioie di Git era piuttosto alta, oltre ad avere spesso installazioni datate di plugin e WordPress stesso. Dal momento che WP è una delle piattaforme consumer più usate al mondo è anche una delle più prese di mira per tentare di bucarle, gli aggiornamenti sono un fattore cruciale per tutti.

I benefici più grandi per noi(s3)

Innanzitutto possiamo ora essere sicuri di alcune cose.

Abbiamo configurazioni separate per diversi ambienti di sviluppo e questo è ovviamente molto bene. Inoltre abbiamo guadagnato una gestione di variabili d’ambiente (quali ad esempio configurazioni di connessione al database) in un file .env e non dentro lo stesso file di configurazione wp-config.php. Implica che ognuno di noi può avere l’ambiente locale che preferisce – pur secondo certe best practice – ma non impedisce od ostacola gli altri.

Altra apparentemente piccola ma significativa differenza: le cartelle di configurazione di Bedrock non sono esposte al webserver.

La gestione delle dipendenze è gestita da Composer (uno standard de-facto per lo sviluppo PHP come packet manager) e permette anche l’uso di sorgenti private, quindi plugin sviluppati internamente oppure versioni premium ma conservate in un git repository privato. Quindi aggiorni una versione di un plugin, sistemi i file di compose dei progetti, fai girare lo script di update e tutti i siti sono aggiornati.

MAI. PIÙ. SENZA.

Qui di seguito riporto uno screenshot comparativo che i più nerd apprezzeranno.

Facciamolo (capi)strano.

Fin qui però non abbiamo ancora risolto l’annoso problema di portare i siti in staging, pre-produzione, produzione etc. senza addannarsi l’anima. In altre parole non avevamo ancora superato il problema del rapporto conflittuale con FTP. Rapporto particolarmente complicato tutte le volte che le modifiche sono massive o allo stesso modo puntuali.

  • Problema 1. Devo modificare una cosa in produzione, sono tentato di modificare il file direttamente lì e mi dimentico di riportare la modifica su Git. Pratica sporca, usata spesso, ma superabile. Avevamo trovato ad esempio git-ftp che risolve in parte il problema. Ma non era sufficiente.
  • Problema 2. Devo spostare velocemente il tutto da un ambiente di staging a quello di produzione con poco più di un comando, lo devo fare iterativamente perché devo testare le modifiche prima di rompere tutto.

Welcome (back) to Capistrano

Qualche anno prima, quando eravamo pazzi e usavamo solo Drupal, ci eravamo imbattuti nel lavoro degli allora Twinbit che avevano reso Drupal, assieme a Features e un po’ di altri moduli, compatibile con capistrano. Una libreria ruby on rails che permette di eseguire comandi remoti da locale come ad esempio deployare un sito ovvero di rollbackare  la versione quando questa non funziona, senza dover intervenire manualmente su ogni file modificato.

Esiste quindi un concetto di release che viene sparata su un server e che semplicemente viene riprodotta identica.

La stessa cosa, fortunatamente, usiamo da anni anche nel caso di Bedrock che, con l’estensione bedrock-capistrano, ci permette di portare in produzione una nuova release al costo del comando

cap production deploy

che certamente una svolta.

Perché?

Perché tutta la parte di core, di plugin pubblici e proprietari e di temi, viene buildata a partire dai sorgenti. Quindi per ogni release si riscarica il core pulito, i plugin puliti, il tema pushato sul repository e viene costruita una copia carbone del sito soltanto della ultima versione disponibile di tutto questo ben di Dio.

Immaginate lo scenario: cliente chiama perché hanno bucato sito. Può succedere, succederà.

Una volta fatta una verifica di integrità delle parti custom e sanitizzate le parti relative agli upload, basta lanciare una build per ripulire tutto e ricostruirlo.

Tempo stimato 30-80″ circa.

Gli upload, citavo. Ecco questi, assieme ai file di connessione al database e ad altri file che devono essere persistenti rispetto alle build, sono linkati simbolicamente (in nerdese symlinkati) così da evitare di perdersi storico.

Confesso, la prima versione di nois3.it era su WordPress vanilla, il passaggio a Bedrock l’ho fatto direttamente sotto al culo di WordPress e non si è accorto di nulla, fatto solo lo spostamento di tutti gli allegati ai post.

Ma ammettiamo per un secondo che abbiate sbagliato a deployare. Panico, vero? No.

cap production deploy:rollback

Il tempo di un deploy ed è tutto su, se prima funzionava. Caruccio.

I benefici più grandi per i nostri clienti.

La certezza di poter replicare le modifiche su produzione senza intralciare il lavoro. La praticamente totale assenza di down perché “stiamo mettendo online modifiche”. Una volta terminato il deploy, il sistema si preoccupa di linkare sempre la cartella current, quindi una volta aggiornato il webserver, punta automagicamente all’ultima versione della release.

Sicurezza, come scrivono nel loro sito.

Modularità.

Ordine e gestione delle dipendenze.

I treni passeranno in orario… no questo no, però insomma.

Alcuni limiti

Ci sono alcuni limiti, più all’approccio al progetto che altro. A volte sembrano passare per vendor lock-in ma non è affatto così.

In pratica la cosa che più pesa è un server diverso dagli hosting da pochi euro. Serve un accesso SSH, serve una configurazione particolare di Apache o Nginx, servono alcune accortezze che un sistemista medio sa fare senza problemi e che invece l’hosting non può.

Implica quindi un costo più alto e una curva di adozione più ripida.

Posso avere un FTP per lavorarci?

No.

Ma non perché siamo cattivi, ma perché oggettivamente FTP significa lavorare direttamente sul filesystem di produzione nella stragrande maggioranza dei casi e la risposta sarà semplicemente no.
Si può lavorare in più società, più soggetti, più fornitori. Ma si lavora secondo uno standard moderno e condiviso.

Posso avere un FTP per uploadare cose?

Certo, volendo. Ma sei sicuro che serva?

Cosa cambia per i backup?

Nulla quelli li devi fare lo stesso, o meglio tanto: è inutile backuppare tema e plugin. Sono sul composer.json che è committato su un repository. E poi ci sono i file e il database. Meglio, parecchio meglio.

Usate Bedrock? Ce lo fate sapere?

Please, rotate the screen
or view the website on other screen.